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

[burek]

[00:14] <ubitux> ok, tsan report is 131M
[00:14] <ubitux> but output completely useless..
[00:14] <ubitux> why is there no symbols..
[00:15] <ubitux> i guess i'll have to --enable-debug
[00:15] <ubitux> i thought it was the default
[00:15] <ubitux> 'forget disable-stripping
[00:16] <ubitux> i'm stupid
[00:16] <wm4> I think the common idiom is not stripping by default, and having an install-strip target
[00:17] <ubitux> we produce a _g not stripped binary
[00:17] <ubitux> so we have both by default, which is nice
[00:17] <wm4> and the libraries?
[00:17] <ubitux> though, through fate i forgot.
[00:17] <ubitux> well, !stripped by default
[00:17] <ubitux> afaik
[01:23] <ubitux> matthewjheaney_: i'll have a last look to you patch tomorrow, and will likely apply it
[01:23] <ubitux> sorry for the delay
[01:26] <matthewjheaney_> OK, no hurry.  I just wanted to make sure that it didn't fall into /dev/nul.
[02:09] <kierank> did webvtt ever get rollup captions
[09:38] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20130622012319&slot=x86_64-archlinux-clang-tsan
[09:38] <ubitux> a bit more useful output with debug :)
[09:39] <ubitux> BBB: btw, did you get a chance to look at the vp8 race? :P
[12:07] <cone-319> ffmpeg.git 03Hendrik Leppkes 07master:d76fff7df72d: smvjpeg: use refcounted frames to avoid mem leaks
[14:56] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:b6ce50a2d4ba: avutil/ripemd: adjust loop condition to silence CID1035716
[14:59] <Compn> michaelni : are you thinking about merging some of rockboxes' fixed point decoders? :)
[19:50] <nevcairiel> \o/ valgrind is green again
[19:51] <ubitux> hf with helgrind/drd/tsan now ;)
[19:51] <nevcairiel> no thanks
[19:51] <ubitux> :(
[19:51] <nevcairiel> opening the helgrind report crashes my chrome
[19:51] <ubitux> haha
[19:51] <nevcairiel> or rather, that tab of the browser
[19:52] <ubitux> that's because it tries to put 800M of text in memory maybe
[19:52] <ubitux> tsan is only 200M
[19:52] <ubitux> so it's ok
[19:52] <nevcairiel> anyhow debugging race conditions gives me headaches
[19:53] <nevcairiel> especially because many of those are probably false positives
[19:55] <ubitux> all the sanity threading tools may be using the same methods then
[19:56] <nevcairiel> similar concepts at least i would wager
[20:12] <ubitux> michaelni: any objection to the API changes (disposition addition) in "[PATCH] Use private option to specify WebVTT kind"?
[20:13] <ubitux> otherwise i'll likely apply soon
[20:38] <michaelni> ubitux, no objections but maybe should be a seperate commit
[20:38] <ubitux> ok
[20:38] <ubitux> matthewjheaney_: care to split the patch?
[21:09] <ubitux> saste: are you going to review the delogo patches?
[21:39] <Daemon404> wtf
[21:39] <Daemon404> ffmpeg fails to build (mingw) for me
[21:39] <Daemon404> undefined ref to av_buffersrc_add_ref
[21:40] <Daemon404> saste / ubitux -- known?
[21:40] <Daemon404> in buffersrc.c i nlavfi
[21:43] <ubitux> with lavfi disabled?
[21:43] <Daemon404> no
[21:43] <Daemon404> straight up plain ./configure
[21:43] <ubitux> no idea
[21:43] <Daemon404> :|
[21:45] <nevcairiel> works for me
[21:45] <Daemon404> dafuq
[21:46] <nevcairiel> obviously the mingw fate boxes also work
[21:46] <Daemon404> oh
[21:46] <Daemon404> i radd it wrong
[21:46] <Daemon404> udnefined ref to avfilter_copy_buf_props
[21:48] <nevcairiel> did you accidentally bump the version? :p
[21:48] <Daemon404> no
[21:49] <nevcairiel> or build without avcodec?
[21:49] <nevcairiel> :)
[21:49] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:8689ee0eefb6: sonic: simplify shift_down()
[21:49] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:12de2933da6e: sonic: Improve error codes
[21:49] <nevcairiel> only reason this function wouldnt exist
[21:50] <Daemon404> :|
[21:50] <Daemon404> man wtf
[22:03] <Daemon404> wut
[22:03] <Daemon404> cannot repro on linux with mingw
[22:03] <Daemon404> only native
[22:03] <Daemon404> dafuq is going on in here
[22:03] <nevcairiel> your toolchain is broken
[22:03] <Daemon404> its the same toolchain
[22:03] <Daemon404> :D
[22:04] <nevcairiel> cant run a windows .exe on linux!
[22:04] <Daemon404> well you can
[22:04] <nevcairiel> try mine if you want, runs fine http://files.1f0.de/mingw/
[22:04] <Daemon404> i think i might have mucked up my ffmpeg git dir
[22:04] <Daemon404> in unknown ways
[22:04] <Daemon404> $5 says a reclone will fix it
[22:05] <nevcairiel> also a possibility
[22:06] <ubitux> or just git clean -fdx
[22:06] <nevcairiel> i usually prefer that over make distclean, sometimes distclean is a bit silly when files get removed/added/renamed
[22:27] <Daemon404> nevcairiel / ubitux -- reclone fixed it
[22:27] <Daemon404> herp derp
[22:27] <Daemon404> magic.
[22:31] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:081a7f3ed065: sonic: replace some float by integers to improve platform independance
[22:31] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:37c7a8be19e2: sonic: replace literal numbers by sizeof()
[22:51] <cone-319> ffmpeg.git 03Derek Buitenhuis 07master:8bdbabfaa469: configure: Enable MinGW-w64's implementation of vsnprintf and pals
[22:51] <cone-319> ffmpeg.git 03Oka Motofumi 07master:81c5ceeda211: avisynth: Make sure the filename passed to Avisynth is in the right code page
[22:54] <ubitux> MAX_PATH * 4f
[22:54] <ubitux> fear
[22:55] <Daemon404> ?
[22:55] <ubitux> isn't this gonna be a bit large?
[22:55] <Daemon404> it is 260
[22:55] <ubitux> oh
[22:55] <Daemon404> always.
[22:55] <ubitux> ok haha
[22:55] <JEEB> yup
[22:55] <ubitux> i guess that's ok then :)
[22:55] <Daemon404> i just prefered to use it instead of a magic #
[22:56] <ubitux> i was worried because it's something like 4096 on linux
[22:56] <Daemon404> ah
[22:56] <Daemon404> nah its 260 on windows forever
[22:56] <Daemon404> because legacy
[22:56] <ubitux> and thus "wchar_t filename_wc[MAX_PATH * 4];" was starting to get a bit large :p
[22:56] <ubitux> (especially on the stack)
[22:56] <ubitux> yeah sure right ok :)
[22:56] <Daemon404> :P
[22:56] <ubitux> is 260 enough for absolute path then?
[22:56] <Daemon404> finally pushed that mingw fix too
[22:57] <Daemon404> [16:56] <@ubitux> is 260 enough for absolute path then? <-- it is windows own path limit
[22:57] <Daemon404> so yes
[22:57] <Daemon404> for ansi paths anyway
[22:57] <Daemon404> which is what avs takes
[22:57] <ubitux> dos compat, heh
[22:57] <Daemon404> :D
[22:58] <ubitux> let's add a freedos fate instance now
[22:58] <Daemon404> hey at least we dont need to use 8.1 filenames
[22:58] <JEEB> 8.3 you mean?
[22:58] <Daemon404> whatever it was
[22:58] <JEEB> EIGHTFAG.COM
[22:59] <JEEB> 8.3
[23:30] <BBB> ubitux: no... let me try now, it was test-vector-010 right?
[23:30] <ubitux> not only
[23:31] <ubitux> fate-vp8-sign-bias-emu-edge
[23:31] <ubitux> and fate-vp8-test-vector-010 yes
[23:31] <ubitux> and fate-vp8-test-vector-emu-edge-010
[23:40] <BBB> let me try to build current git and see how hard it is to reproduce
[23:40] <BBB> 2 threads right?
[23:40] <BBB> do you know how to debug this?
[23:40] <BBB> it's a useful skill to learn
[23:41] <matthewjheaney_> Which files go in which patch?  
[23:43] <BBB> hey matt, working on a weekend?
[23:43] <matthewjheaney_> Yup
[23:44] <ubitux> BBB: yes, 2 threads
[23:44] <ubitux> BBB: and no, i have absolutely no idea
[23:46] <BBB> hm, ok, so you start by running the test indefinitely until it fails
[23:47] <BBB> you try to get an idea of how often it fails
[23:47] <BBB> for me it fails after 500 runs
[23:47] <ubitux> that part is ok, i did it for the h264 race(s)
[23:47] <BBB> n=0; while true; do out=`./ffmpeg -nostats -cpuflags all -threads 2 -thread_type frame -i ~/Movies/fate-suite-ff/vp8-test-vectors-r1/vp80-00-comprehensive-010.ivf -f md5 -nostats -v 0 - | cut -d= -f2`; let n=n+1; echo "$n: $out"; if test $out != 61d05919a9883d9f215eb3f2db63eb13; then break; fi; done
[23:47] <BBB> 495: 61d05919a9883d9f215eb3f2db63eb13
[23:47] <BBB> 496: 61d05919a9883d9f215eb3f2db63eb13
[23:47] <BBB> 497: 1ef41b204e71b74f5ff7ea3b65dc4a6a
[23:47] <BBB> ok, then do that a couple of times to be sure it's always the same race
[23:48] <BBB> you don't want to study a variety of races
[23:48] <BBB> e.g. now I get a different one
[23:48] <BBB> 73: 61d05919a9883d9f215eb3f2db63eb13
[23:48] <BBB> 74: 22dd9d372aa487d2ab9978b0854058ea
[23:48] <BBB> (that could be uninitialized memory, but it's easier when you keep studying the same race, so I tend to focus on just one)
[23:49] <BBB> once you have one that is reproducible, extend the test and write the output yuv file to disk in addition to printing the md5
[23:49] <BBB> if all races have the same initial yuv file mismatch, it's fine
[23:50] <BBB> then look at the file of the yuv mismatch and see what goes wrong, in what macroblock
[23:50] <BBB> use printf debugging
[23:50] <BBB> and always do it in the loop where you break only if the mismatch occurred
[23:50] <BBB> so the line above is serves as a control
[23:52] <BBB> or just parse a good one to ref.yuv and the bad one to mismatch.yuv
[23:52] <BBB> a
[23:52] <BBB> nd
[23:52] <BBB>  
[23:52] <BBB> com
[23:52] <BBB> pa
[23:52] <BBB> re
[23:52] <BBB> oops, sorry, stupid chat client
[23:53] <ubitux> ok
[23:54] <ubitux> the main issue is that i haven't much clue how threading in ffmpeg actually works, but well yeah ok
[23:54] <BBB> printf debugging requires no prior knowledge
[23:54] <ubitux> sure :)
[00:00] --- Sun Jun 23 2013