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

[burek]

[00:13:06 CET] <JEEB> kierank: sounds like funkiness wrt merging of side data
[03:25:56 CEST] <cone-982> ffmpeg 03James Almer 07master:2f05d18ee2c7: ffmpeg: stop using deprecated codec flags
[03:25:57 CEST] <cone-982> ffmpeg 03James Almer 07master:f5c8d004c28d: avcodec: stop using deprecated codec flags
[03:25:58 CEST] <cone-982> ffmpeg 03James Almer 07master:963cd953fbf6: avfilter: stop using deprecated codec flags
[03:25:59 CEST] <cone-982> ffmpeg 03James Almer 07master:d054069c1540: avformat/mov: stop using deprecated codec flags
[03:39:43 CEST] <cone-982> ffmpeg 03James Almer 07master:ec996163c8db: avcodec/extract_extradata_bsf: use the parsing code from mpegvideo_split()
[03:39:44 CEST] <cone-982> ffmpeg 03James Almer 07master:173fdc4dea13: avcodec/extract_extradata_bsf: use the parsing code from vc1_split()
[03:39:45 CEST] <cone-982> ffmpeg 03James Almer 07master:b53ac2a5283d: avcodec/extract_extradata_bsf: use the parsing code from mpeg4video_split()
[03:43:42 CEST] <cone-982> ffmpeg 03James Almer 07master:a044f8df6aff: ffprobe: support skip_samples packet side data information
[11:03:40 CEST] <ubitux> http://sprunge.us/RBAh is this legit?
[11:04:12 CEST] <nevcairiel> didnt someone post a patch for that
[11:04:16 CEST] <nevcairiel> not sure if it was ever applied
[11:04:58 CEST] <nevcairiel> it was applied
[11:05:10 CEST] <nevcairiel> although they used tsan, not hellgrind
[11:11:17 CEST] <ubitux> tsan still broken for me yet :(
[11:11:25 CEST] <ubitux> -yet
[11:11:36 CEST] <ubitux> where is that patch you're talking about?
[11:12:44 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=fed50c4304eecb352e29ce789cdb96ea84d6162f
[11:14:19 CEST] <ubitux> thanks
[11:17:21 CEST] <ubitux> yeah well it seems valgrind doesn't really care about atomics
[12:00:00 CEST] <wm4> kierank: nice
[12:00:33 CEST] <wm4> nevcairiel: it was, but some insisted the packet corruption was part pf abi
[12:01:16 CEST] <wm4> so it'll stop doing that only once abi is bumped
[12:45:19 CEST] <durandal_1707> stop  the fight
[13:10:12 CEST] <ubitux> http://valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use wth...
[13:10:34 CEST] <ubitux> tldr: so actually helgrind can't figure out shit
[13:11:02 CEST] <ubitux> "Avoid memory recycling."
[13:11:09 CEST] <ubitux> "Avoid POSIX condition variables."
[13:11:18 CEST] <ubitux> does that mean "avoid threading"?
[13:13:51 CEST] <nevcairiel> seems a bit pointless
[13:17:23 CEST] <BBB> hehehe
[13:19:14 CEST] <flux> "The result of Helgrind missing some inter-thread synchronisation events is to cause it to report false positives." so you just need look deeper into them.
[13:19:37 CEST] <wm4> analysis tools that generate too many false positives are useless
[13:19:52 CEST] <flux> well, that is certainly true and helgrind produces a lot of diagnostics from x264 ;)
[13:19:57 CEST] <ubitux> i was wondering if i could use these ANNOTATE_ macros
[13:19:59 CEST] <wm4> because the time it takes to analyze those false positives manually outweights the bugs you'd find
[13:20:10 CEST] <ubitux> but helgrind doesn't seem to even recognize stdatomics
[13:20:18 CEST] <flux> it seemed to produce less false positives on a project I've worked on while finding actual problems.
[13:20:44 CEST] <flux> as trying out helgrind is easy one could just try and see what it says.
[13:21:23 CEST] <BBB> wm4: thats why I created my own runtime threading debugger for reproducing actual bugs ;)
[13:21:31 CEST] <BBB> (printf")
[13:22:01 CEST] <flux> works for many bugs but not for heisenbugs ;)
[13:22:10 CEST] <wm4> yeah, amazes me how printf is still the most useful debugging tool
[13:22:22 CEST] <BBB> flux: not true - https://blogs.gnome.org/rbultje/2014/01/12/brute-force-thread-debugging/
[13:23:19 CEST] <flux> I tried recently lttng, seems like a nice tracing framework if a bit tedious to start using. but I believe that should be low-overhead enough to remove the delay-effect of printf.
[13:23:30 CEST] <flux> (well realistically almost anything is a lot faster than printf ;-))
[13:24:03 CEST] <ubitux> i only use printf for debugging, too
[13:24:18 CEST] <ubitux> for threading, you often need... more
[13:24:24 CEST] <ubitux> which doesn't seem to exist
[13:25:24 CEST] <ubitux> the only time i use a debugger is when writing simd
[13:25:35 CEST] <ubitux> and it reminds me everytime how much gdb sucks and why i never use it
[13:25:55 CEST] <nevcairiel> gdb is way too l ow level
[13:26:02 CEST] <nevcairiel> GUIs on top of  gdb can be useful
[13:27:51 CEST] <flux> is there a good GUI/TUI for GDB, though? I just use cgdb (almost daily).
[13:28:28 CEST] <flux> mozilla has this tool that can replay executions under GDB. I think that might be a tool for solving heisenbugs.
[13:28:58 CEST] <BBB> that sounds useful
[13:29:03 CEST] <BBB> in fact, it sounds like chess ;)
[13:29:12 CEST] <BBB> Ive always wished for a tool like that
[13:29:31 CEST] <flux> http://rr-project.org/
[13:29:46 CEST] <ubitux> michaelni: is it possible to add mediacodec to your android builds?
[13:29:50 CEST] <wm4> is there something that can go backwards yet?
[13:30:03 CEST] <flux> gdb has recording as well and bandwards debugging, but it's much slower and latest ubuntu apparently broke it :(
[13:30:04 CEST] <wm4> actually what I'd want is a tool that simplifies printf debugging
[13:30:17 CEST] <ubitux> gdb supports backward debugging since a while
[13:30:28 CEST] <flux> gdb's backwards debugging was nice if you are able to isolate the area where you need it.
[13:30:40 CEST] <wm4> like, being able to set a breakpoint, that printfs an interesting set of variables if the line is executed, and only breaks if specific expressions evaluate true
[13:30:54 CEST] <ubitux> also supported
[13:30:55 CEST] <flux> wm4, well, conditional breaakpoints + breakpoint commands..
[13:31:06 CEST] <wm4> could never figure these out / get them working
[13:31:30 CEST] <flux> I would like to be able to actally inject new C (or C++) code when running the debugger
[13:31:41 CEST] <wm4> I even I still sometimes end up using glibc's backtrace function
[13:32:08 CEST] <BBB> rr sounds sweet, Ill try that one day
[13:32:55 CEST] <flux> the problem with gdb conditional breakpoints/commands is that they are super slow
[13:41:18 CEST] <flux> on one project we had a separate tracing ring buffer for individual subsystems in memory. if (..when..) the program crashed the core dumps were delivered to us, and then there was a gdb python script that would combine and pretty print the traces. that was pretty nice and low overhead.
[14:09:42 CEST] <michaelni> ubitux, added, iam not sure it will build/work though
[14:19:09 CEST] <mateo`> michaelni: it should work (with gcc and clang), the code is used in production
[18:25:40 CEST] <durandal_1707> anybody wants to debug dnxhdenc patch of mine?
[18:47:06 CEST] <durandal_1707> anyone?
[18:47:36 CEST] <atomnuker> durandal_1707: encoder? sure
[18:47:51 CEST] <wm4> why debug
[18:47:55 CEST] <wm4> did you mean review
[18:48:43 CEST] <durandal_1707> atomnuker: dnxhd branch on github
[18:50:50 CEST] <durandal_1707> wm4: its not working, somehow calculates too low number of bits
[18:58:44 CEST] <atomnuker> durandal_1707: shouldn't you be setting ctx->bit_depth based on ctx->cid_table->bit_depth?
[18:59:09 CEST] <atomnuker> why did you make the change to use ctx->bit_depth anyway?
[18:59:19 CEST] <durandal_1707> no, as its 0 for 444 table
[18:59:41 CEST] <durandal_1707> variable, can be 10 or 12
[18:59:54 CEST] <durandal_1707> cid 1270
[19:00:07 CEST] <atomnuker> why is it 0 for 444?
[19:00:30 CEST] <durandal_1707> because its 10 or 12 for cid 1270
[19:01:13 CEST] <atomnuker> I see, DNXHD_VARIABLE
[19:02:07 CEST] <durandal_1707> i dont get always same assert
[19:02:43 CEST] <durandal_1707> seems its undefined behaviour introduced somewhere
[19:03:33 CEST] <atomnuker> uninitialized vars?
[19:04:04 CEST] <durandal_1707> no, out of array reads maybe
[19:04:20 CEST] <atomnuker> valgrind?
[19:04:22 CEST] <durandal_1707> valgrind is useless for me
[19:04:40 CEST] <durandal_1707> at least with this case
[19:24:23 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:9dd1573423ca: doc/bitstream_filters: Fix project name after merge
[19:24:23 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:73fb40dc8795: avcodec/x86/idctdsp: Remove duplicate include
[19:24:23 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:0ba22831e1fc: avcodec/h264idct_template: Fix multiple runtime error: signed integer overflow
[19:32:09 CEST] <ubitux> http://sprunge.us/hJFO
[19:32:11 CEST] <ubitux> so
[19:32:13 CEST] <ubitux> how do i fix that? :(
[19:37:59 CEST] <ubitux> maybe i should just patch MAX_OFILE_ALIGNMENT in the gcc sources for djgpp
[19:58:18 CEST] <ubitux> tsan instance is back btw: http://fate.ffmpeg.org/report.cgi?time=20170326174538&slot=x86_64-archlinux-gcc-tsan
[19:58:30 CEST] <ubitux> and much less noisy than helgrind afaict!
[19:59:25 CEST] <ubitux> wm4: funny, it's only complaining on that async_mutex thing for the first test
[19:59:45 CEST] <wm4> complaining about what?
[20:00:29 CEST] <ubitux> lock-order-inversion
[20:00:45 CEST] <ubitux> ThreadSanitizer: lock-order-inversion (potential deadlock) src/libavcodec/pthread_frame.c:747 in ff_frame_thread_init
[20:01:47 CEST] <ubitux> it's wrt the global lock it seems
[20:02:05 CEST] <wm4> ah I've been potentially worried about that too
[20:02:10 CEST] <ubitux> Cycle in lock order graph: M1324 (0x7d100000dec0) => M1329 (0x7d280000ea20) => M1324
[20:02:16 CEST] <wm4> lock order doesn't seem to be defined at all for this
[20:02:19 CEST] <ubitux> M1329 is the async lock
[20:02:24 CEST] <ubitux> and M1324 is the global lock
[20:02:35 CEST] <wm4> anyway, with the new patch the lock is a "logical" lock
[20:03:26 CEST] <ubitux> heh tsan sounds pretty cool compared to helgrind
[20:03:37 CEST] <ubitux> i guess i'll drop those useless helgrind and drd instances for now
[20:03:44 CEST] <ubitux> they're useless
[20:07:10 CEST] <ubitux> it seems tsan is mostly reporting about the global avcodec lock in all the tests
[20:07:28 CEST] <ubitux> if that one gets fixed, it should silence all the noise
[20:07:39 CEST] <ubitux> and we could potentially spot real races
[20:07:45 CEST] <ubitux> (assuming that one isn't)
[20:08:01 CEST] <wm4> the lock magaer one?
[20:08:03 CEST] <wm4> *manager
[20:11:54 CEST] <ubitux> the async_mutex vs the global avcodec one
[20:11:58 CEST] <ubitux> the thing we just talked about
[20:12:13 CEST] <ubitux> if you look at the entries in tsan, that's mostly about that
[20:12:29 CEST] <ubitux> i'm curious what's remaining after it's fixed
[20:16:59 CEST] <jamrial> ubitux: why do you need freedos for this merge?
[20:17:55 CEST] <ubitux> jamrial: because that's how the warnings were spotted
[20:17:55 CEST] <jamrial> also, last time i tried to add PRI specifiers lower than 32 i was told to not bother and keep it as %d/u
[20:18:29 CEST] <jamrial> i see
[20:20:03 CEST] <jamrial> ubitux: https://fate.libav.org/x86_32-freedos-gcc/20170326041147/compile
[20:20:11 CEST] <ubitux> yep
[20:20:12 CEST] <jamrial> "warning: alignment of 'sbr_qmf_window_ds' is greater than maximum object file alignment.  Using 16 [enabled by default]"
[20:20:18 CEST] <jamrial> instead of error like you got
[20:20:32 CEST] <wbs> ubitux: you don't need freedos per se (only for running it), you can cross compile with djgpp from any modern/sane unix - you only need freedos/dosbox if you'd want to try to run it
[20:20:32 CEST] <ubitux> yes, but that's because i'm using a more recent one i believe
[20:20:41 CEST] <ubitux> s/one/gcc/
[20:20:57 CEST] <ubitux> wbs: yeah, i know, but i'm still at the compilation step :D
[20:21:29 CEST] <ubitux> jamrial: it's curious btw, because it's forcing an align of 16 and doesn't seem to cause any problem at runtime
[20:21:51 CEST] <ubitux> i suppose there is no 32-align compatible simd in use
[20:22:51 CEST] <jamrial> 32-align is needed for avx instructions. i doubt freedos can run those :p
[20:25:48 CEST] <ubitux> apparently it's not using the djgpp header with the max align, so instead i'll try to make that thing not fatal
[20:26:03 CEST] <ubitux> let's hope s/error/warning/ restores properly the old behaviour
[20:28:55 CEST] <ubitux> ahah it works
[20:29:07 CEST] <ubitux> let's try to compile again taht stuff :)
[20:30:00 CEST] <ubitux> http://b.pkh.me/max-ofile-align-warning.patch saved the day
[20:35:29 CEST] <ubitux> with 3 small patches, compilation is restored for freedos
[21:04:56 CEST] <ubitux> http://sprunge.us/QMWK let's go.
[21:09:19 CEST] <jamrial> many of those should be reported by any compiler, like %d used for unsigned variables
[21:09:33 CEST] <ubitux> i'm fixing all of them
[21:09:41 CEST] <ubitux> so we can move on with the merges
[21:11:33 CEST] <jamrial> i know, what i mean is that some should have been reported by other compilers but weren't
[21:12:37 CEST] <jamrial> "warning: format %c expects argument of type int"
[21:12:40 CEST] <jamrial> i thought %c was for char
[21:13:42 CEST] <atomnuker> ubitux: I think its better to remove all instances of pow2 and instead just multiply
[21:14:01 CEST] <atomnuker> we shouldn't invent functions with similar names to functions libc has
[21:14:32 CEST] <atomnuker> let alone a function which directly maps to an operator (*)
[21:16:02 CEST] <jkqxz> jamrial:  It is.  Integer promotion applies, though, so as a vararg function it takes an int.
[21:17:21 CEST] <BBB> jamrial: %c has an int argument but only the lower 8 bits are interpreted for the serialization
[21:17:46 CEST] <BBB> in the same way that %u and %d both take a 32bit argument but the serialization is not the same for a value like 0xFFFFFFFF
[21:18:50 CEST] <cone-752> ffmpeg 03Michael Niedermayer 07master:eaf6f10f1b5c: avfilter/vf_signature: Replace uncommon spelling of seperate
[21:39:22 CEST] <kierank> atomnuker: it had significant speed increases
[21:39:31 CEST] <kierank> why not just define pow2() on platforms that don't have it
[21:43:23 CEST] <kierank> oh i see
[21:58:03 CEST] <ubitux> maybe i could check for pow2 and create a HAVE_POW2, but doing that only for djgpp sounds overkill (even though they actually have an asm optimized version of it)
[22:01:17 CEST] <durandal_1707> so instead it should be deoptimized?
[22:31:41 CEST] <cone-752> ffmpeg 03Mark Thompson 07master:a94972b2b2e6: ffmpeg: Remove hw_device_ctx output filter reinit hack
[23:14:59 CEST] <ubitux> durandal_1707: it only affects djgpp, so who cares
[23:15:16 CEST] <ubitux> i would do it if it was available on other platforms
[23:15:21 CEST] <ubitux> but that doesn't seem to be the case
[23:15:34 CEST] <ubitux> (otherwise we would have expected that compilation error already)
[23:47:46 CEST] <ubitux> we need to make a macro like av_ts2str() with av_get_codec_tag_string()&
[23:47:54 CEST] <ubitux> that will simplify a lot of the warning fixes
[23:48:01 CEST] <ubitux> i guess i'll send a patch tmr
[00:00:00 CEST] --- Mon Mar 27 2017