[Ffmpeg-devel-irc] ffmpeg-devel.log.20130103

[burek]

[00:00] <michaelni> its like i want filter foo but it should not be enabled
[00:00] <ubitux> yeah sure
[00:00] <ubitux> what about deint=all or deint=marked?
[00:00] <saste> mp=kerndeint has such an option
[00:01] <saste> it allows to "dynamically" disable the filter
[00:01] <saste> i like deint=all|marked
[00:01] <saste> since auto=1|0 is not very descriptive
[00:03] <michaelni> deint=all|interlaced
[00:04] <ubitux> :)
[00:05] <ubitux> you may want to add a ref to the setfield filter btw
[00:07] <saste> what about printing "CONSULT YOUR LOCALLY INSTALLED DOCUMENTATION FOR OLDER VERSIONS!!!" in red, bold, blinking, bleeding, 300% sized characters in documentation.html?
[00:08] <ubitux> you forgot "moving" with the help of <banner>
[00:08] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:740e74089555: av_rescale: support passing MIN/MAX through
[00:08] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:98db90589651: avformat_seek_file: Dont attempt to rescale INT64_MIN/MAX
[00:09] <beastd> saste: it would be better if we could archive the versions for the recent releases and make the accessible or similar
[00:10] <saste> beastd, similar to what we did with doxygen?
[00:10] <saste> yes that may be a good idea
[00:12] <beastd> how is it done for the doxygen?
[00:12] <cone-140> ffmpeg.git 03Clément BSsch 07master:f263426eedd3: lavu/math: fix than/then typo, and add a comma.
[00:13] <beastd> i am running out of time for today. see you tomorrow
[00:13] <beastd> bye...
[00:13] <ubitux> cya
[00:17] <cone-140> ffmpeg.git 03Clément BSsch 07master:43adc62e7022: lavf/mpegtsenc: fix missing word in error message.
[00:28] <ubitux> saste: you should have said the faq will get updated in the next hours
[00:28] <ubitux> otherwise the guy is going to rage and re-open the ticket saying it's not in the online doc
[00:28] <ubitux> :D
[00:28] <saste> let it be, let's have some fun
[00:35] <saste> the it would be nice to have an ffmpeg-faq manual
[00:35] <ubitux> wm4: i started looking at making the matroska demuxer output "ass" packet instead of "ssa", so introducing a new codec id
[00:36] <ubitux> it's not really a problem, except that the whole demux/decode/encode/mux chain needs some little updates
[00:36] <wm4> ok
[00:36] <ubitux> also, the decoded subtitles will still be in "ssa" format (in the ass field of the rects)
[00:37] <ubitux> that's the next step, but AFAIK all the mplayer forks just care about the demux for that, right?
[00:37] <ubitux> saste: i'm not against
[00:38] <saste> ubitux, problem is that faq references html pages
[00:38] <saste> so we definitively need indexing
[00:39] <saste> i plan to dive into haskell and possibly contribute to pandoc and add a texinfo reader and indexing
[00:39] <saste> but that may take time
[00:39] <ubitux> wm4: so basically, what will change for you is that you should be able to get rid of the various hacks for muxed subtitles, but if you're doing some subtitles decoding at some point (like you should do if you're planning to support the standalone subtitles files), it will still be using the ssa format
[00:39] <ubitux> pandoc is in haskell? :)
[00:39] <saste> (haskell is paradise for a computer scientist ;-))
[00:40] <wm4> does ssa not have the same issues?
[00:40] <ubitux> by ssa i mean the current form
[00:41] <ubitux> basically timings, clrf after each line, no read order, ..
[00:42] <ubitux> so if you're demuxing and decoding a standalone file (.srt, .ass or anything else), the markup in the sub->rects[i].ass will still be in that format
[00:42] <ubitux> i'm still unsure about what to do with the ass demuxer (wheither it should output ASS like in matroska, or still keep the lines so in SSA format)
[00:43] <ubitux> but it should change anything for you in the end
[00:43] <ubitux> since all external subtitles (.ass or no) should be handled exactly the same
[00:43] <ubitux> (and you'll need a decode step)
[00:44] <ubitux> wm4: and btw, if you plan to *decode* the (even new) ass packets from the matroska demuxer, you'll also end up with "ssa lines" in sub->rects[i].ass
[00:45] <wm4> ubitux: so, why not proper ASS? does matroska actually use this ssa form?
[00:45] <ubitux> what i'm doing right now is just add the non altered packets with ASS codec, mainly for the mkv demuxer
[00:45] <ubitux> wm4: that's the next step, but that's a bit tricky from a retro compat PoV
[00:45] <iive> \o/
[00:46] <ubitux> wm4: and no, it's not using the ssa form at all
[00:46] <ubitux> it's just that the decoding process of subtitles, whatever the codec of the packet, leads to a common markup
[00:46] <ubitux> with is currently ssa, stored in the ass field of the rects
[00:46] <ubitux> currently, for ass decoding, it's just copied in the field
[00:47] <ubitux> what will happen now is that like every other codecs, it will be "encoded" into these kind of ssa lines
[00:48] <ubitux> wm4: do you expect ass markup from other containers?
[00:49] <wm4> ubitux: what other containers?
[00:49] <ubitux> AFAIK, only MKV, ASS and NUT demuxers can output these packets
[00:49] <ubitux> mkv will now output proper ass packets with the new codec id
[00:49] <wm4> and ASS?
[00:49] <ubitux> ass, i'm still uncertain but it shouldn't affect you
[00:50] <ubitux> and nut, i need to check what's going on here, but i'm pretty sure it will need various other work to be sane
[00:51] <ubitux> wm4: as i said, the thing with the ass demuxer (i'm talking about when you demux a .ass file), is that you likely need exactly the same processing chain as the other subtitles
[00:51] <ubitux> .srt, .sub, .aqt, etc
[00:51] <ubitux> so you will NEED a decode step, filling the rects->ass fields with the "broken" markup
[00:51] <ubitux> that is currently the only way to get a consistent output between all these formats
[00:52] <wm4> I don't see much of a point in having two packet formats for the same thing... so ASS should definitely output the proper format
[00:52] <wm4> the "decoded" rects are not packets, though
[00:52] <ubitux> and you're supposed to decode everything at startup, and feed it to libass, and then don't care about
[00:52] <ubitux> (just like vf subtitles)
[00:52] <ubitux> you're not supposed to use the "chunked" mode with a .ass file
[00:52] <ubitux> like you do with matroska
[00:53] <ubitux> or well the "normal" mode i would say, sorry
[00:53] <ubitux> wm4: well, that's just another packet
[00:53] <wm4> that entirely depends how you feed it to libass, but the way vf_ass does it seems sort-of fine
[00:54] <ubitux> not with .ass file
[00:54] <ubitux> you're not really supposed to do that
[00:54] <ubitux> just handle the .ass files just like every other standalone subtitles files
[00:54] <wm4> also I don't see the point of the decoder interface here
[00:55] <wm4> can't it just read and output full files?
[00:55] <ubitux> consistent markup between all the subtitles
[00:55] <ubitux> the demuxer subtitles split the the markup from the timing level
[00:55] <ubitux> the subtitles decoders "encode" the markup in the ass field of the rects
[00:57] <ubitux> note that this will change (basically we will make the decoders output a common abstract style sub instead of a ssa line markup, and provide helpers to get a ass markup to be piped to libass)
[00:57] <wm4> the way vf_subtitles is written obviously won't really work with demuxed subtitles of other types, unless you do the silly reset-on-seek thing
[00:57] <ubitux> it will
[00:57] <ubitux> since you preload the whole file
[00:58] <wm4> I mean with files that interleave video and subs
[00:58] <ubitux> yes, vf subtitles is for standalone files
[00:58] <ubitux> standalone subtitles files
[00:58] <ubitux> .srt, .ass, .sub, .aqt, ...
[00:59] <ubitux> it can work with video+sub though
[00:59] <ubitux> (it will just demux the whole thing first)
[00:59] <wm4> nit acceptable for a video player
[00:59] <wm4> *not
[00:59] <ubitux> yes, but i was not asking you to do that :)
[01:00] <ubitux> as i said, you're only interested in clean ASS packets out of matroska, right?
[01:00] <ubitux> since that's the only case where you pipe directly the packets to libass
[01:00] <ubitux> wm4: i'm proposing to do like vf subtitles for the standalone subtitles, where it is perfectly appropriate
[01:01] <ubitux> (and that's exactly what mplayer does manually with subreader)
[01:01] <ubitux> of course, you'd better wait for the charset and utf16 thing before implementing it
[01:02] <ubitux> i need to rush this stuff in the next days
[01:18] <ubitux> https://bugs.gentoo.org/show_bug.cgi?id=447838  is this something we need to fix?
[01:19] <ubitux> or it looks like a problem that affect both projects?
[01:23] <cone-140> ffmpeg.git 03Clément BSsch 07master:491ca0e89ff9: Replace references to "que" with the appropriate word.
[01:24] <ubitux> saste: did you look at the ffprobe & xface issues?
[01:24] <ubitux> for ffprobe, i'm really surprised about the logic behind the code
[01:25] <saste> ubitux, no my gcc is not complaining
[01:25] <ubitux> althought the warning is likely to be fixed with a consistent usage of int & enum
[01:25] <ubitux> saste: what about the logic of the code? (for both)
[01:26] <saste> ubitux: i have to find you pastebin
[01:26] <saste> it's not like it looks high priority since it worked fine so far...
[01:27] <ubitux> yeah sure but&
[01:27] <ubitux> the code really looks fishy to me
[01:28] <durandal_1707> ubitux: release 2.0
[01:28] <ubitux> oh i think i understand&
[01:28] <ubitux> durandal_1707: yes?
[01:30] <ubitux> saste: well, it might not be that important then :)
[01:30] <ubitux> the ffprobe aliasing warnings are present in arm boxes, and the xface with gcc 4.7
[01:31] <saste> ubitux, did you understand what is it complaining about?
[01:40] <ubitux> saste: i believe that's because children_ids is not of type enum SectionID
[01:41] <saste> ubitux, ok
[03:57] <ubitux> wtf
[03:57] <ubitux> #2102  "The input line is too long.
[03:57] <ubitux> :"
[03:57] <ubitux> what is the guy smoking
[04:01] <Compn> ubitux : oh i got a great idea for a filter
[04:02] <Compn> epilepsy filter, removes bright light flashes from video
[04:09] <Compn> it will replace the bright flash frame with the previous frame before the bright light. so it will make the video stutter a little
[04:13] <ubitux> Compn: good idea, now you can implement it
[04:40] <cone-842> ffmpeg.git 03Michael Niedermayer 07master:52334f5be2ef: tiff: print error for old style LZW
[07:30] <cone-842> ffmpeg.git 03Clément BSsch 07master:3fa642d60f42: subviewer: sanitize packets.
[07:48] <cone-842> ffmpeg.git 03Clément BSsch 07master:dc8b36746a9d: lavf/webvtt: use ff_subtitles_read_chunk().
[08:06] <ubitux> why is my subtitles todo list still huuuge? :(
[08:07] <ubitux> ass codec, charset, utf16, stylesubtitles, teletext, blending api, subtitles in lavfi, &
[08:07] <ubitux> :(
[08:33] <ubitux> mmh
[08:35] <ubitux> wtf
[08:39] <ubitux> it's like if the sources were updated, but the code still old
[08:39] <ubitux> i guess i'll wait for the next run
[09:33] <ubitux> saste: sorry, by macro i meant the enum
[09:33] <ubitux> like checking for YADIF_PARITY_TFF instead of 0
[09:33] <ubitux> in the code
[09:33] <saste> ubitux, uhm not for the moment
[09:34] <saste> for merging reasons and also because i wanted to keep the patch short
[09:34] <ubitux> okay
[10:23] <saste> ^ the start_number saga continues...
[10:35] <wm4> "Ubuntu does not provide ffmpeg from the FFmpeg project, but a fake version from a third-party fork which we can not support here."
[10:35] <wm4> awesome
[10:37] <JEEB> wm4, just like mplayer2 provides/provided a "fake mplayer binary" ^q^
[10:38] Action: wm4 waits for the 3rd ffmpeg fork
[10:38] <wm4> or 2nd, depending on how you count
[11:43] <kierank> ubitux: you're going to implement teletext in ffmpeg
[11:43] <kierank> wow you're nuts :)
[11:43] <ubitux> not now, as you can see there are several other entries in the TODO list
[11:43] <kierank> doesn't change the fact that you're nuts :)
[11:43] <ubitux> and by teletext i mean decoding from the sane packets
[11:43] <ubitux> not from the vbi
[11:43] <kierank> oh
[11:43] <kierank> still
[11:44] <kierank> teletext rendering is a total pita
[11:44] <kierank> ask j-b 
[11:44] <ubitux> i'll start with decoding as normal text, and i'll see later
[11:44] <ubitux> i guess you're talking about the black background etc?
[11:45] <kierank> it's just a lot of work in general
[11:45] <kierank> cf libzvbi
[11:45] <ubitux> there is a guy working on this
[11:45] <ubitux> he sent a draft patch a few days ago
[11:45] <j-b> teletext is impossible to do right
[11:45] <ubitux> i'm more focused on something else right now :)
[11:46] <ubitux> j-b: yeah but being able to decode it to put it back as srt/ass/whatever is important for users when they transmux/transcode
[11:46] <ubitux> and i think that's something relatively easy to do
[11:46] <ubitux> especially when we'll be done with the StyleSubtitles API :)
[11:47] <kierank> ubitux: what's the subject of the patch
[11:47] <ubitux> mmh it was in an unrelated thread, just a min
[11:49] <ubitux> kierank: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-December/136677.html
[11:49] <kierank> oh i remember that actually
[11:49] <kierank> he used libzvbi thankfully
[11:49] <ubitux> yup
[11:51] <ubitux> anyway, there are other priorities right now
[11:51] <ubitux> i think we're going to get something really nice with subtitles
[11:51] <ubitux> we already have an almost sane working chain
[11:55] <pross-au> ubitux: is this also going to be able to carry eia-608 closed captions?
[11:56] <ubitux> i'd like to
[11:56] <ubitux> it should be flexible enough
[11:56] <ubitux> ideally, someone should write a decoder
[11:57] <ubitux> so i get an idea about what's necessary ;)
[11:57] <ubitux> basically we can extend the styles, and the chunk "types" (we can insert timing chunks for karaoke etc)
[11:57] <ubitux> and we can basically store any kind of information
[11:58] <pross-au> decoder is on my todo list. last time i looked at subtitles, FFmpeg didn't have a good 'internal format'. We were had the choice of 'bitmaps' or 'ass' text string.
[11:59] <ubitux> yes
[11:59] <ubitux> eia-608 is text only, right?
[12:00] <ubitux> just with a particular encoding
[12:00] <ubitux> iirc the character drawing is free
[12:00] <ubitux> pross-au: ass is used for the style
[12:00] <ubitux> you can ignore it at first
[12:01] <ubitux> and just create text packets for codec id text
[12:01] <ubitux> basically you would just write a demuxer
[12:01] <pross-au> IIRC, there are colors
[12:01] <ubitux> but mmh it's already demuxed
[12:01] <ubitux> well then just write a decoder like the text dec :p
[12:02] <ubitux> pross-au: currently you have to print ass tags
[12:02] <ubitux> that's what i'm going to change with the stylesubtitles api
[12:02] <ubitux> but it would be really nice to have a basic decoder ;)
[12:03] <ubitux> so we can do some eia-608 to srt
[12:03] <ubitux> or to ass
[12:03] <pross-au> i have the beginnings of one (it worked with the .wtv bastardised variant of eia-608).
[12:04] <ubitux> beginning of a decoder?
[12:04] <pross-au> yes, it works with a subset of eia-608 that .wtv uses
[12:04] <ubitux> awesome
[12:05] <ubitux> :)
[12:05] <ubitux> michaelni: did you see that: http://fate.ffmpeg.org/log.cgi?time=20130103073615&log=compile/20130102224902&slot=x86_32-linux-gnu-icc-2011.4.191 ?
[12:05] <pross-au> (kinda long story, but Windows Media Centre extracts the eia-608 from the ts, strips some stuff, and 're-encodes' it into a separate .wtv stream)
[12:05] <ubitux> :/
[12:35] <kierank> pross-au: it drops 708?
[12:44] <pross-au> kierank: i forget, there was a bug tracker entry on it.
[12:45] <kierank> 608/708 is annoying - there are so many ways of storing it
[12:47] <pross-au> https://ffmpeg.org/trac/ffmpeg/ticket/1482
[12:47] <pross-au> Yes
[12:48] <pross-au> well there is the big problem of 608/708/TELETEXT packets embedded inside AV_MEDIA_TYPE_VIDEO streams. I don't think that one has been solved yet.
[12:48] <kierank> not teletext
[12:48] <kierank> 608/708 yes
[12:49] <kierank> elenril said his buffer ref stuff will fix that
[12:49] <pross-au> Okay. Cool.
[12:50] <kierank> well it won't fix
[12:50] <kierank> it'll just export
[12:52] <pross-au> ubitux: is there a description of your sytlesubtitles system somewhere? i am a bit unclear on how its going to work
[13:03] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-November/134607.html
[13:04] <ubitux> pross-au: also, related: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/130474.html
[13:07] <pross-au> this is really good :)
[13:07] <ubitux> it's yet to be completed
[13:08] <ubitux> i've still some pending stuff 
[13:09] <pross-au> i'll dig out the cea-608 stuff i was working on. also have a lrc (music lyrics) decoder somewhere too. might help to shake down the required chunks.
[13:10] <michaelni> ubitux, didnt see the warning but well icc complaining about doing calcuilations with enums is a bit limited
[13:10] <michaelni> adding casts wont make the code better
[13:10] <ubitux> michaelni: i'm not saying that's justified, i just happened to see that :p
[13:11] <michaelni> maybe that warning should be disabled
[13:11] <ubitux> pross-au: there are now quite a bunch of subtitles demuxers and decoders
[13:11] <ubitux> which you can use as base
[13:59] <Compn> some video game drivers and other things have anti-epilepsy features
[14:36] <divVerent> there are filters for that? How do they even work
[14:37] <Compn> brightness / flicker detection
[14:37] <divVerent> and that works?
[14:37] <divVerent> https://www.youtube.com/watch?v=hNRhvHIk5C8 - what would they do here? ;)
[14:38] <divVerent> black screen? ;)
[14:39] <Compn> more curious about this video https://www.youtube.com/watch?v=1m8bBP1l1_c
[14:39] <divVerent> the filter would have to change the volume to zero ;)+
[14:40] <Compn> lol
[14:42] <Compn> http://forum.doom9.org/archive/index.php/t-132264.html
[14:42] <Compn> dark_shikari , that name sounds familiar
[15:20] <cone-971> ffmpeg.git 03Reinhard Tartler 07master:60e60d99ad86: forgotten changelogs for 9_beta2
[15:20] <cone-971> ffmpeg.git 03Janne Grunau 07master:9ac44ad9d06f: h264: check SPS entries directly to detect pixel format changes
[15:20] <cone-971> ffmpeg.git 03Johan Andersson 07master:7768a635c4ea: cmdutils: update copyright year to 2013
[15:20] <cone-971> ffmpeg.git 03Michael Niedermayer 07master:1894302a44f3: Merge remote-tracking branch 'qatar/master'
[15:24] <DEgITx> Question about AVSEEK_FLAG_BYTE. Is it seeking method really working, and is it need some recalculation of keyframes? Because after i have tryed it on h264 video i was getting such errors when decoding frame:
[15:24] <DEgITx> [h264 @ 090c0060] Missing reference picture
[15:24] <DEgITx> [h264 @ 090c0060] decode_slice_header error
[15:24] <DEgITx> ...
[15:24] <DEgITx> Even packet position didn't change =\ What i'm doing wrong?))
[16:35] <cone-971> ffmpeg.git 03Nicolas George 07master:be01d1a24ddc: fate: disable globbing when calling shell functions.
[17:05] <saste> michaelni, do you want to comment on yadif named constants/options patches?
[17:33] <saste> can someone confirm that the equivalent of tinterlace=4,format=yuyv422,mp=kerndeint,format=yuyv422
[17:33] <saste> doesn't work in mplayer?
[17:33] <saste> also what if i drop support for yuyv422p?
[17:35] <divVerent> doesn't work? as in, kerndeint does not support yuyv422 format?
[17:35] <saste> divVerent, as in: the output is borken
[17:36] <divVerent> hehe, I always found kerndeint's output broken ;)
[17:36] <divVerent> and mpv even removed the filter
[17:36] <divVerent> so, can't check
[17:37] <saste> divVerent, no I mean that you get only the left side of the image actually written
[17:37] <saste> i don't know how to force the format with mplayer
[17:37] <divVerent> haha
[17:37] <divVerent> scale,format=yuyv422,kerndeint,scale
[17:37] <divVerent> if the format name is right in mplayer
[17:39] <teratorn> divVerent: yuvv422? what is that ?
[17:39] <teratorn> oh yuyv
[17:39] <saste> well it ain't broken in mplayer
[17:40] <saste> better not to know why
[17:40] <divVerent> m-    {IMGFMT_YUY2,  PIX_FMT_YUYV422},
[17:40] <divVerent> -    {IMGFMT_YUY2,  PIX_FMT_YUYV422},
[17:40] Last message repeated 1 time(s).
[17:40] <divVerent> sorry
[17:40] <divVerent> scale,format=yuy2,kerndeint,scale
[17:40] <divVerent> is this broken?
[17:41] <saste> oh wait it is even in mplayer
[17:41] <divVerent> apparently yuy2 is mplayer's format name for this
[17:41] <saste> i mean, it is *broken* even in mplayer
[17:43] <divVerent> from reading the code in the last version before mpv removed the filter: kerndeint IS broken for that format
[17:43] <divVerent> #it assumes 8bpp on each plane
[17:43] <divVerent> but it also doesn't claim support for YUY2 in that version
[17:44] <saste> fixing it should be easy, but also it is worth it?
[17:44] <divVerent> wait, it once did
[17:44] <divVerent> given the filter sucks anyway
[17:44] <divVerent> just remove its YUY2 support
[17:44] <saste> michaelni, ^ ?
[17:45] <saste> divVerent, in what sense does it suck?
[17:45] <divVerent> it looks bad
[17:45] <saste> divVerent, compared to what? yadif?
[17:45] <divVerent> for example, yes
[17:45] <divVerent> in my opinion it even looks worse than pp=lb
[17:46] <divVerent> it's the one that looked like a weird sharpener
[17:46] <divVerent> and the image shivers all the time
[17:47] <divVerent> still, fixing it shouldn't be too hard
[17:59] <michaelni> saste, ?
[18:00] <saste> michaelni, don't bother, i already fixed yuyv422
[18:00] <michaelni> ok
[18:00] <saste> still waiting for yadif patches
[18:00] <michaelni> iam looking at them right now :)
[18:00] <michaelni> well 1 patch that is
[18:49] <saste> what's the mplayer equivalent name for "yuv420p"?
[18:50] <saste> well without the ending "p"
[18:52] <saste> -vf scale,format=argb,kerndeint,scale
[18:52] <saste> this doesn't want to work
[19:19] <durandal_1707> can i swap frame.data[x] pointers?
[19:32] <michaelni> durandal_1707, in principle yes, you might have to also swap extended_data pointers though and there of course might be code ive forgotten that assumes things it shouldnt assume
[19:49] <Compnn> the great format wars
[19:49] <Compnn> pirates chose mkv. apple, sony, microsoft, adobe, android and others chose mp4.
[19:53] <durandal_1707> pirates choose rar
[19:53] <Prottey> DRM is money, money is everything
[19:53] <durandal_1707> and nothing
[19:54] <Prottey> yet Android (Google that is) chose WebM as well
[19:54] <Prottey> and everybody forgot Dirac :P
[19:55] <Prottey> except maybe FGPA nerds who do h/w accels
[19:55] <michaelni> Tjoppen, can you look at ticket/1916 it seems a regression since a commit from you
[19:57] <Tjoppen> right, forgot about that one
[19:58] <Tjoppen> there's a bit of a start-of-the-year lull at work, so I should have time to look at it
[19:58] <durandal_1707> no full time ffmpeg dev?
[20:00] Action: durandal_1707 ^ becoming boring
[20:14] <cone-971> ffmpeg.git 03Michael Niedermayer 07master:bbb11f383ee8: lavf: add return to silence compiler warning
[20:17] <kierank> Compnn: rather strange thread
[20:18] <kierank> "Not only is Linux the most widely used operating system on the planet"
[20:18] <kierank> interesting assertion
[20:18] <kierank> i guess if you include embedded
[20:18] <Compnn> well, lots of droid phones :P
[20:18] <Compnn> microwaves, etc
[20:18] <Compnn> yeh
[20:18] <Compnn> dvd players
[20:19] <kierank> strange rant though
[20:19] <kierank> especially the secret ffmpeg
[20:19] <Compnn> :D
[20:20] <Compnn> lol more comments
[20:21] <kierank> mp3 is definitely allowed in mp4
[20:21] <durandal_1707> it is about m4v m4a
[20:22] <Compnn> is there really a diff between m4v and mp4 ?
[20:22] <Compnn> i thought it was all the same damn thing
[20:22] <durandal_1707> and m4v/m4a are only used with ipod muxer
[20:22] <Compnn> mj2 mov mp4 m4v m4a m4p etc
[20:22] <kierank> m4v/m4a is renamed apple crap
[20:22] <durandal_1707> ipod muxer write some extra shit
[20:22] <Compnn> ah
[20:23] <Yuvi> it's about the same as the difference between mp4 and 3gp
[20:23] <Yuvi> different allowed codecs and atoms
[20:23] <kierank> oh
[20:23] <durandal_1707> the guy thinks that mp4 does not allow multiple a/v streams
[20:24] <Compnn> he means ipod wont play multilple stream
[20:24] <Compnn> or something similar...
[20:24] <kierank> i don't see why the patch supporting dts in mp4 can't be committed
[20:24] <durandal_1707> nope, he wants to mux dts-ma+ac3 and play that on ipod
[20:24] <kierank> it's standards compliant
[20:24] <Compnn> Yuvi : yeah thats what i was thinking. webm vs mkv :P
[20:25] <durandal_1707> kierank: dts is already supported in mp4
[20:25] <Compnn> the patch is for muxer only ?
[20:25] <durandal_1707> i dunno what apple m4a/m4v crap supports
[20:25] <kierank> he's getting confused like me then
[20:25] <kierank> between mp4 and m4v
[20:27] <kierank> durandal_1707: why is he saying dts isn't allowed by ffmpeg in mp4
[20:27] <kierank> i am confused by this guy
[20:28] <durandal_1707> he is confused too, but he is not interested in mp4 at all
[20:28] <durandal_1707> only in m4a/m4v
[20:29] <ubitux> speaking about mp4, does anyone have in mind the website with the list of all what is allowed in it
[20:29] <ubitux> with the different fourcc etc
[20:29] <ubitux> ?
[20:29] <kierank> ubitux: it's in the ticket
[20:29] <kierank> http://www.mp4ra.org/specs.html#MLP
[20:29] <ubitux> oh, thx
[20:29] <ubitux> exactly what i was looking for
[20:30] <durandal_1707> and you know correct fourcc?
[20:30] <durandal_1707> and all extra info?
[20:30] <durandal_1707> if there is mlp in mp4 sample in wild, would we already know about it?
[20:31] <kierank> since we're not going to get the mlp standard any time soon we will have to wait
[20:36] <cone-971> ffmpeg.git 03Paul B Mahol 07master:0c8943939eb0: gifdec: use log level that have more common sense
[20:38] <cone-971> ffmpeg.git 03Paul B Mahol 07master:48340bbb366a: aiffenc: metadata support
[20:43] <llogan> nicholas' tee psuedo-muxer looks interesting. users ask for something like this on occasion.
[20:43] <llogan> is he ever in this channel?
[20:44] <Compnn> nicolas george ?
[20:46] <Compnn> dnt think so
[20:47] <llogan> trac has become the new ffmpeg-devel IRC channel.
[20:48] <durandal_1707> lock that ticked
[20:50] <Compnn> we finally got it out that his files work on google tv
[20:50] <Compnn> now we're asking for a sample of the working file :P
[20:50] <Compnn> so close to solving the ridddddle
[20:50] <Compnn> why does he have to fake out an ac3 track however?
[20:52] <durandal_1707> wtf, he use ipod "preset" so that he do not need to use faststart
[20:52] <durandal_1707> but he is probably not aware of -movflags faststart
[20:57] <Compnn> yes! more comments!
[21:00] <durandal_1707> ^no because it cant work always
[21:01] <Compnn> orly
[21:01] <durandal_1707> if seeking is not possible
[21:02] <Compnn> someone broke it
[21:02] <Compnn> fate i mean :P
[21:02] <durandal_1707> what fails?
[21:03] <durandal_1707> shit stupid moronic seek test
[21:07] <cone-971> ffmpeg.git 03Paul B Mahol 07master:28d75441ec2e: fate: update seek-lavf-aiff after previous commit
[21:08] <durandal_1707> it is pointless because there is bunch of demuxers that use same function for seeking
[21:11] <Compnn> durandal_1707 : are you working on evrc? 
[21:11] <llogan> durandal_1707: did you make that ffmpeg logo for the g+ page?
[21:12] <durandal_1707> Compnn: was, i'm on 1787 written lines
[21:13] <durandal_1707> still ~200 - ~600 to write
[21:13] <Compn> wow :)
[21:14] <durandal_1707> llogan: i googled it
[21:14] <durandal_1707> file was named ffmpeg so used it
[21:16] <Compn> without knowing the copyright!? :P
[21:16] <durandal_1707> it is public domain
[21:49] <cone-971> ffmpeg.git 03Reimar Döffinger 07master:def01739c136: mxfdec: Set AV_FIELD_PROGRESSIVE, needed for AVC-intra
[21:49] <cone-971> ffmpeg.git 03Reimar Döffinger 07master:c5142a95a513: Support more AVC-Intra files
[23:27] <saste> ubitux: is there a way to add an offset to a subtitle stream?
[23:28] <saste> would it make sense to add an offset option to the subtitles filter? would that be possible at all?
[23:48] <cone-971> ffmpeg.git 03Michael Niedermayer 07master:9e36d9e4ed2a: pngdec: fix decoding of right column for 2/4bpp
[00:00] --- Fri Jan  4 2013