[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=fed50c4304eecb352e29ce7... [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