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

[burek]

[00:12] <cone-159> ffmpeg.git 03Nicolas George 07master:102cf964ddc9: ffmpeg: sub2video: set resample size.
[00:12] <cone-159> ffmpeg.git 03Nicolas George 07master:98ce9b84681b: fate: merge mapchan and options into ffmpeg.
[01:24] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:3a6b6f425ee3: lavf: move force_codec_ids() up
[01:24] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:341e40f1e1ee: lavf: Fix codec id forcing with probed codecs
[02:38] <cone-159> ffmpeg.git 03Janne Grunau 07master:e9fd51b0d6dc: h264: check SPS entries directly to detect pixel format changes
[02:43] <cone-159> ffmpeg.git 03Michael Niedermayer 07release/0.11:5502b073ec29: lavf: factor codec id forcing out
[02:43] <cone-159> ffmpeg.git 03Michael Niedermayer 07release/0.11:bf19d4c6fa12: lavf: Fix codec id forcing with probed codecs
[02:43] <cone-159> ffmpeg.git 03Michael Niedermayer 07release/1.0:bc1e72c38ead: lavf: move force_codec_ids() up
[02:43] <cone-159> ffmpeg.git 03Michael Niedermayer 07release/1.0:ff08767817c2: lavf: Fix codec id forcing with probed codecs
[04:03] <cone-159> ffmpeg.git 03Michael Niedermayer 07master:1e28fa21de23: rawdec: fix NV12
[04:07] <Compn> ubitux : ever talk to virtualdub, see if they are going to incorporate ffmpeg filters? :P
[09:34] <cone-140> ffmpeg.git 03Clément BSsch 07master:5a2f3f0bca5a: lavf/vobsub: do not count trailing NUL char in extradata.
[09:58] <ubitux> does anyone know if it is possible to be put in cc automatically in the trac when participating to a ticket?
[09:58] <ubitux> i sometimes forget to follow a ticket after asking or saying something
[10:34] <cone-140> ffmpeg.git 03Clément BSsch 07master:8bc74221f8ef: lavf: remove generic index flag from text subtitles.
[11:58] <ubitux> what is this incremental cluster parsing in matroska?
[11:58] <ubitux>     /* File has SSA subtitles which prevent incremental cluster parsing. */
[11:58] <ubitux>     int contains_ssa;
[11:58] <ubitux> any hint about this?
[12:06] <nevcairiel> ubitux: its a trick to reduce latency on parsing, where it doesnt parse the full cluster but only as much as it needs to for the next packet, but that has some issues with ass subs apparently
[12:07] <nevcairiel> it greatly complicates the whole parser for a minor latency gain on seeks, but oh well :)
[12:13] <ubitux> ok
[12:13] <ubitux> thx :p
[12:36] <burek> Happy New Year guys :)
[12:39] <ubitux> hey burek 
[12:39] <ubitux> burek: how is the new fate going on?
[12:40] <burek> well, i paused it since then, when i asked if anyone can help about those logs
[12:40] <burek> because im not quite familiar with git and stuff
[13:08] <michaelni> burek, what do you need from git ?
[13:10] <burek> well, to be more precise, I need directions on what the exact output should be for each link clicked on the fate
[13:11] <burek> for example, it's not helpful to say "see on old fate and just copy/paste" because some diffs I just don't understand why they were created at all
[13:12] <burek> so, it would be the best if someone could tell me (besides configure.log and compile.log) what the other outputs should look like and what is their purpose
[13:12] <burek> so I could optimize things properly
[13:17] <ubitux> you mean the compile diff?
[13:17] <ubitux> it's used to spot new warnings
[13:17] <burek> or, let me simplify this more.. given the configure.log, compile.log and tests.log (for each fate client upload), what are the outputs that developers need
[13:18] <ubitux> compile.log is the only one where we need a diff afaik (and that's the only one where it's done iirc)
[13:18] <burek> i mean, don't get me wrong, it might be obvious to you, but it's not that obvious for me..
[13:18] <ubitux> configure.log and tests.log are useful to debug, but no need to diff
[13:19] <ubitux> and the diff for compile.log, as i said, is just for spotting new warnings
[13:19] <ubitux> look in the current fate for details on the diff: if it's red, new warnings, if it's green, less warning, if it's blue, nothing changed
[13:20] <ubitux> i think there is also a "bold" attribute
[13:20] <ubitux> for cases like one less warning, and one more
[13:20] <ubitux> also note that diff can be relatively huge because of threading compilation
[13:20] <ubitux> (warnings don't appear in the same place)
[13:21] <nevcairiel> yeah the diffs are somewhat useless with threaded compilation
[13:21] <burek> yes, i noticed that
[13:21] <ubitux> |sort!
[13:21] <ubitux> sorted warnings
[13:21] <ubitux> (that is a joke, don't do that)
[13:21] <burek> :)
[13:22] <ubitux> (also note that a new line in the compile.log does not mean a warning, it can be a new file)
[13:23] <burek> you mean in a diff?
[13:23] <ubitux> yes
[13:24] <burek> i'm thinking, you might even be right about |sort :)
[13:24] <ubitux> no
[13:24] <ubitux> what you can do is filtering only the warnings from the compile.log
[13:25] <ubitux> and do a diff on that output
[13:25] <ubitux> (which you could sort, with great care about multiline warnings)
[13:25] <ubitux> (sort before diff of course)
[13:25] <ubitux> BUT
[13:26] <burek> well, yes, if the point is to spot new warnings, it might be enough to just sort / diff and later ctrl+F for that warning
[13:26] <ubitux> warnings output differs between compiler
[13:26] <ubitux> so you need a very smart parser :)
[13:27] <burek> btw, is there a way i could get a copy of the directory on current fate server (just the part with uploaded client stuff)
[13:27] <burek> so that I can have real data to test the outputs on
[13:35] <michaelni> burek, that directory is big 
[13:36] <burek> hm
[13:36] <burek> how big
[13:36] <michaelni> i started a "du -m" 
[13:38] <burek> oh yes, one more question, i've noticed that history for one fate client goes back to 15 and more days
[13:38] <burek> what is that used for?
[13:45] <ubitux> burek: useful for --enable-random, or the threading failing test for example
[13:45] <ubitux> or anything that "recently" (on a time scale of 15 days) failed
[13:58] <burek> > [mpegts @ 0x9e16580] first pts value must set
[13:59] <burek> is this spell checked
[14:00] <ubitux> yes, missing a "be"
[14:03] <burek> i'm not sure if this is a bug or not: http://pastebin.com/qjBu2BeQ
[14:03] <burek> but it looks like ffmpeg can't remux h264 into ts
[14:04] <michaelni> burek, 23gb
[14:04] <burek> nice :)
[14:04] <burek> is there a way i could get just one subdir (1 fate user)? :)
[14:05] <michaelni> probably
[14:05] <michaelni> any specific one you want ?
[14:05] <burek> no preferences really
[16:34] <cone-140> ffmpeg.git 03Stefano Sabatini 07master:fd44dfb29dc7: doc/muxers: fix typos in the segment chapter
[16:34] <cone-140> ffmpeg.git 03Stefano Sabatini 07master:8bbe9d90fa47: doc/muxers: add a dedicated section for segment examples
[16:34] <cone-140> ffmpeg.git 03Stefano Sabatini 07master:82deb0c42e5b: doc/muxers: adopt new -codec:SPEC syntax in segment example
[17:13] <cone-140> ffmpeg.git 03Nicolas George 07master:b99bef17b44c: lavfi/avfiltergraph: check pick_format return code.
[17:44] <cone-140> ffmpeg.git 03Nicolas George 07master:e4f14c32b95a: examples/muxing: improve error messages.
[18:03] <cone-140> ffmpeg.git 03Nicolas George 07master:b252d9e77763: fate: add sub2video test.
[19:35] <wm4> saste, ubitux: have there been any plans to multithread lavfi?
[19:42] <durandal11707> wtf is ipod muxer and how it relates to m4a/m4v
[19:44] <durandal11707> it is just different extensions
[19:45] <nevcairiel> its all mp4 files, apple just likes naming it differently sometimes for audio (m4a) and video (m4v)
[19:45] <durandal11707> so what is point in having ipod muxer?
[19:46] <michaelni> ubitux, saste sub2video test fails http://fate.ffmpeg.org/report.cgi?time=20130102174823&slot=x86-opensolaris-suncc5.10
[19:48] <nevcairiel> ipod only supports h264/aac or something? tell them to use a mp4 file with the mp4 muxer :P
[19:48] <michaelni> also http://fate.ffmpeg.org/report.cgi?time=20130101175054&slot=powerpc-linux-gnu-gcc-4.4.5
[19:48] <durandal11707> nevcairiel: he wants m4a/m4v
[19:48] <nevcairiel> but its the same format
[19:49] <nevcairiel> just a different name
[19:49] <durandal11707> i know that already
[19:51] <durandal11707> anyway adding ipod/ipad/crap muxers is brain dead idea
[19:51] <llogan> ask bcoudurier
[19:53] <durandal11707> hmm ipod muxer write different stuff to file
[19:53] <durandal11707> it is not plain extension thing
[19:54] <durandal11707> so i'm totally lost
[19:55] <llogan> "Write uuid atom: Needed to make file play in iPods running newest firmware"...although i've never had to use it to get video working on the few iDevices i've tested.
[19:56] <durandal11707> does ipod supports dts?
[19:59] <llogan> if you have a sample i can maybe test
[20:02] <durandal11707> you can create one with ffmpeg
[20:16] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:ccb7f203099e: fate: add missing bitexact flag to scale filter
[20:44] <durandal11707> http://www.vapoursynth.com/2012/12/positive-thinking-how-to-convince-yourself-that-you-can-code/ <<<< lol
[21:32] <nevcairiel> there is some failure here
[21:33] <ubitux> arg
[21:35] <ubitux> seems the bitexact flag wasn't enough
[21:40] <ubitux> maybe there is an automatic scale inserted
[21:43] <nevcairiel> shouldnt the log say that
[21:44] <ubitux> [auto-inserted scaler 0 @ 0x23f32a0] w:720 h:480 fmt:yuv420p sar:0/1 -> w:720 h:480 fmt:yuva420p sar:0/1 flags:0x2
[21:44] <ubitux> ow.
[21:46] <ubitux> so overlay only supports yuv420p  for main, but not for overlay
[21:47] <ubitux> ah right, the overlay needs a transparency layer all the time
[21:47] <ubitux> fun
[21:59] <ubitux> beastd: btw, what happened to the better resampling settings?
[21:59] <beastd> hi
[22:00] <beastd> happy new year
[22:00] <beastd> ubitux: about the resampling settings
[22:01] <beastd> i need to figure out fate before.  a lot of tests get changed. seems like some sample that is created is used in lots of other tests or something like that.
[22:01] <ubitux> sure
[22:01] <ubitux> make -k|patch -p1
[22:02] <ubitux> make -k fate|patch -p1
[22:02] <beastd> ubitux: nice trick. haven't thought of that
[22:03] <ubitux> doesn't come from me :p
[22:04] <michaelni> ubitux, theres also a inetger oveflow caused by subtitle.c
[22:04] <beastd> still i want to make sure that i understand why so many tests change. it is a bad idea to update regression test references carelessly; and i need to grep documentation too
[22:04] <michaelni> i do have a fix for the overflow already
[22:05] <michaelni> will push in a moment 
[22:05] <michaelni> unless you want to see/review ?
[22:05] <llogan> we'll fix it in post
[22:06] <ubitux> michaelni: i don't mind looking at it right now
[22:06] <ubitux> is it causing problems?
[22:06] <ubitux> or that's from coverity or something?
[22:08] <michaelni> ubitux, http://pastebin.com/FB57sadL
[22:08] <michaelni> ubitux, fate client failure
[22:09] <michaelni> this here was what found it: http://fate.ffmpeg.org/report.cgi?time=20130102195020&slot=x86_64-freebsd8.2-clang2.8-ftrapv
[22:09] <ubitux> oO
[22:10] <ubitux> illegal instruction? because of this?
[22:10] <michaelni> :)
[22:10] <ubitux> nit: please add a space after the if
[22:10] <beastd> that sounds bad (like control of instruction pointer)
[22:12] <ubitux> oh
[22:12] <ubitux> i guess that's because it's doing some magic in the av_rescale_rnd
[22:13] <ubitux> michaelni: av_rescale_rnd seems to be checking for INT64_MIN
[22:13] <ubitux> shouldn't such kind of test added to that function?
[22:13] <michaelni> what test ?
[22:14] <michaelni> what function and what should it do ?
[22:14] <ubitux> i see a "a != INT64_MIN"
[22:14] <michaelni> yes the code cant handle INT64_MIN
[22:14] <ubitux> might be completely unrelated though
[22:15] <ubitux> well, if there is a check already, that's where the check for INT64_MAX would belong
[22:15] <ubitux> no?
[22:16] <ubitux> i don't think the caller should do such sanity check (it's not like it's a div by zero or something)
[22:16] <ubitux> it's more like an implementation specific issue in that function
[22:16] <michaelni> no
[22:16] <ubitux> so IMO the check belongs there
[22:16] <ubitux> what am i missing?
[22:16] <michaelni> INT64_MIN * 90 / 50 gives what ?
[22:17] <nevcairiel> EOVERFLOW :P
[22:17] <ubitux> an overflow?
[22:17] <michaelni> yes
[22:18] <nevcairiel> * 50 / 90 would however work
[22:18] <michaelni> yes
[22:18] <michaelni> not with INT64_MIN and the current code though
[22:18] <michaelni> i could fix that but
[22:18] <ubitux> michaelni: which one is causing the illegal instruction?
[22:18] <michaelni> it wouldnt avoid the need for checks outside that way
[22:19] <michaelni> ubitux, clang 
[22:19] <ubitux> INT64_MIN or INT64_MAX?
[22:19] <michaelni> MIN
[22:19] <ubitux> then what is the INT64_MIN check for in the rescale function?
[22:19] <ubitux> if it's not to prevent such thing
[22:20] <michaelni> -INT64_MIN  == INT64_MIN
[22:20] <michaelni> the code handles negative by -a
[22:20] <michaelni> so it cant handle INT64_MIN taht way
[22:22] <ubitux> i'm still a bit concerned about adding such test in the caller
[22:23] <ubitux> it sounds like an issue which could be present in a lot of places
[22:24] <michaelni> we could add a ==INT64_MIN) return INT64_MIN
[22:25] <michaelni> but that would be "wrong" if someone really wanted to rescale that 
[22:28] <cbsrobot>  wow @ https://ffmpeg.org/trac/ffmpeg/ticket/2101
[22:28] <ubitux> right now, if we seek to INT64_MIN, it will fail the same way, no?
[22:28] <ubitux> cbsrobot: oh sounds fun.
[22:29] <michaelni> seeking to INT64_MIN will surely fail dunno how exactly
[22:31] <ubitux> i'm not sure where to put the check
[22:31] <michaelni> neither am i
[22:31] <michaelni> but i want to put it somewhere :)
[22:31] <michaelni> nowhere is bad
[22:31] <michaelni> either its in the callers or rescale passes MIN and MAX through
[22:32] <michaelni> if its in the callers then rescale can be made to rescale MIN correctly
[22:32] <michaelni> if its in rescale then things may be simpler but rescale cant rescale MIN/MAX
[22:33] <michaelni> maybe we can make rescale scale down correctly and limit on upscale
[22:33] <michaelni> but still this wont fix all callers
[22:33] <michaelni> AV_NOPTS_VALUE must not be scaled
[22:34] <michaelni> so either check outside or passthrough inside rescale
[22:35] <ubitux> the AV_NOPTS_VALUE could be check in the seek caller
[22:36] <ubitux> in the av seek function, before the callback
[22:38] <ubitux> also, since the if stream_index==-1 case looks like a code that could be common to a lot of demuxer seeking callback
[22:38] <ubitux> i'd better make some kind of lavf utils helper and use it appropriatly
[22:38] <ubitux> then you could put whatever sanity check you want in
[22:39] <ubitux> basically everything related to overflows, div/0, AV_NOPTS, ..
[22:40] <ubitux> but well, afaict currently
[22:40] <ubitux> only SGB demuxer and all the text subtitles are using the seek v2 api
[22:41] <ubitux> but i'm pretty sure the option will rise for others
[22:41] <ubitux> assuming someone would use it at some point
[22:50] <michaelni> ubitux, the stream==-1 code hardcodes stream 0 so
[22:50] <michaelni> its wrong if theres more than 1 stream
[22:51] <cone-140> ffmpeg.git 03Clément BSsch 07master:fc86f863536b: fate/sub2video: move sws flags globally in the filtergraph.
[22:52] <ubitux> i meant a function taking a timebase, and min_ts/ts/max_ts
[22:52] <ubitux> i know that can't be done currently in the caller
[22:53] <ubitux> also, i don't know enough about the different seeking callbacks to be able to tell what kind of helper would be welcome
[22:53] <michaelni> if tehres just 1 stream theres no sense in passing stream=-1 on
[22:53] <michaelni> so no code would need to handle it
[22:53] <ubitux> that's currently the case at least :p
[22:53] <michaelni> i can fix that i think
[23:00] <michaelni> ubitux, patch sent
[23:03] <ubitux> michaelni: i'm fine with adding any sanity check at that level now :p
[23:03] <ubitux> of course if it can be done in the rescale function that's even better, but if you say that's not possible&
[23:06] <cone-140> ffmpeg.git 03Michael Niedermayer 07master:aa86d2d88461: lavf: move stream==-1 handling from ff_subtitles_queue_seek() to avformat_seek_file()
[23:24] <cone-140> ffmpeg.git 03Clément BSsch 07master:49a78e6b8cbd: lavu/eval: handle div by zero in mod().
[23:31] <ubitux> we need a mac os ffmpeg developer :p
[23:31] <ubitux> i have no idea where to look for #2100
[23:34] <beastd> ubitux: i would like to buy and install the os but it seems they want me to buy their hw for getting at the os...
[23:35] <michaelni> ubitux, patches to fix the overflow posted
[23:36] <saste> ubitux, would it help if you get a mac for testing purposes?
[23:37] <ubitux> saste: no, because i have no idea what to test
[23:37] <ubitux> i never actually used a mac, i don't know how it works
[23:38] <saste> ubitux, it's not like you need to be a genius to use one
[23:38] <saste> but i know i prefer not to have one since that would mean more work for me ;-)
[23:39] <ubitux> you want to buy me an iPad?
[23:39] <saste> uh.. for testing compilation it's not a big idea
[23:39] <ubitux> then 2 iPad?
[23:40] <saste> then you can use one as a keyboard?
[23:40] <ubitux> compilation cluster
[23:41] <ubitux> well anyway, no i don't think i would make use of a mac if i had one
[23:41] <ubitux> if i haven't one currently, that's not because of the money :p
[23:41] <saste> then we need a mac geek
[23:41] <ubitux> exactly my point :)
[23:41] <saste> and while at it, a windows nerd
[23:41] <saste> or a mac nerd and a windows geek
[23:42] <ubitux> michaelni: not afraid about libav adding a rescale flag?
[23:42] <ubitux> (with the value=8)
[23:42] <ubitux> we have at least one windows guy :)
[23:42] Action: ubitux look at nevcairiel 
[23:42] <ubitux> the other rage quitted
[23:42] <ubitux> +one
[23:42] <ubitux> (d404)
[23:43] <michaelni> ubitux, ill change it to some other less likely value than 8
[23:43] <saste> where is llogan and his start_number patch?
[23:44] <ubitux> saste: no idea
[23:45] <ubitux> michaelni: so how sane are the rescaled min/max ts after the function call now?
[23:46] <michaelni> min/max will stay min/max with the flag
[23:47] <michaelni> its like rescaling infinity
[23:47] <saste> it was already oked
[23:47] <saste> i'm going to push it
[23:49] <saste> michaelni, you ok with the yadif patches?
[23:52] <michaelni> saste, should be ok
[23:53] <saste> i'm just not sure about the name of the "enable" option
[23:55] <cone-140> ffmpeg.git 03Stefano Sabatini 07master:69d75dc4dd10: lavu/base64: extend/clarify doxy for the base64 API
[23:55] <cone-140> ffmpeg.git 03Lou Logan 07master:091ce6bcb21e: doc/faq: add -start_number example
[23:56] <michaelni> saste, i think calling it auto is better than enable
[23:56] <michaelni> liek auto=1 -> automatic enabling
[23:56] <saste> michaelni, i plan to add named constants
[23:57] <ubitux> enabled=yes/no/auto?
[23:57] <saste> so that would be enable=always|interlaced
[23:58] <ubitux> what about deinterlace=all|interlaced ?
[23:59] <ubitux> deinterlace=all|marked maybe
[23:59] <michaelni> saste, auto=1/0 or yes/no
[23:59] <ubitux> or just "deint"
[23:59] <michaelni> ubitux, enabled=no makes no sense :)
[00:00] --- Thu Jan  3 2013