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

[burek]

[02:08:07 CET] <cone-661> ffmpeg 03Michael Niedermayer 07master:3f28caf72083: avcodec/mpeg12dec: Provide debug level log on skiped P/B frames
[02:08:07 CET] <cone-661> ffmpeg 03Michael Niedermayer 07master:3206ea4ba31e: avformat/utils: Also fill dts==RELATIVE_TS_BASE packets in update_initial_durations()
[12:56:03 CET] <jnmbk> Hi, I'm trying to understand how ffpeg detects an mpeg file and its packet size. My main goal is to split a file by given miliseconds by making the least possible disk reads. So is there any documentation you guys can recommend for me?
[13:22:38 CET] <JEEB> wbs: after adding these two tests (https://github.com/jeeb/ffmpeg/commit/b704031b58df876fc54b42e852d63fd48c460193) to FFmpeg and checking the files with boxdumper, it seems like the first one actually gets an elst for both tracks even though the comment says the video track shouldn't have it. the second one indeed lacks any edit list.
[13:43:02 CET] <JEEB> although that could be because the FFmpeg movenc writes edit lists much more liberally
[13:45:13 CET] <JEEB> as this was pretty much unapplicable https://github.com/mstorsjo/libav/commit/468f14ea8f4b9b9f4956215ac7aced3a2dacec6a
[16:01:35 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:2ac6eedac5e5: avcodec/pngdec: Store metadata directly into AVFrame
[16:01:35 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:e8d4eacc07c6: Factor CHECKED out of DEBUG so it can be set seperatly
[16:01:35 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:3e1028c625e1: avcodec/flac: Fix several integer overflows
[16:01:35 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:12eebb845a7f: avcodec/wavpacl: Fix runtime error: left shift of negative value -1
[16:28:24 CET] <cone-039> ffmpeg 03James Almer 07master:21d25da18025: avcodec/huffyuvdsp: use an actual unsigned long constant
[16:28:25 CET] <cone-039> ffmpeg 03James Almer 07master:b921b3b42b61: avcodec/huffyuvencdsp: use an actual unsigned long constant
[16:54:57 CET] <cone-039> ffmpeg 03Marton Balint 07master:8985e4af2bba: avformat/fifo: assert on disallowed message type and state combinations
[16:54:58 CET] <cone-039> ffmpeg 03Marton Balint 07master:4556dad2b737: avdevice/iec61883: free packet on buffer allocation error
[16:54:59 CET] <cone-039> ffmpeg 03Marton Balint 07master:a9f3e4b138fc: avfilter/f_setcmd: fix null pointer dereference on using dash as interval
[18:50:47 CET] <wm4> jkqxz: isn't there some code duplication between vaapi scaler and deint?
[19:03:31 CET] <jkqxz> wm4:  Yes, quite a bit.  I don't think it's worth factorising now, but would be if a third were added.  (The possible vaapi_otherstuff filter, which gives you the denoise/sharpen/whatever single-frame things: I might get around to looking at it again at some point, though it's so limited that for anything you might actually want to do the OpenCL mapping is more useful.)
[19:49:48 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:706757d26dd5: avcodec/mpeg12dec: Fix runtime error: left shift of negative value
[19:49:49 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:4279613a2652: avcodec/pngdec: Check bit depth for validity
[20:13:21 CET] <cone-039> ffmpeg 03Rostislav Pehlivanov 07master:67fa02ed794f: opus_pvq: fix PVQ search for K < 5 and low Ns
[21:34:55 CET] <wbs> JEEB: ok, good to hear that the patchset seems to work fine for you. and indeed, if you can't pick that patch you surely won't get the exact behaviour described in the test
[21:35:26 CET] <JEEB> yea
[21:35:52 CET] <JEEB> but as long as that weird "sanity check" is disabled the output looking at boxdumper seems a'OK
[21:36:20 CET] <wbs> JEEB: I'll have a look at rebasing that patchset and submitting it to libav then, and you can do whatever you prefer for getting it usable in ffmpeg
[21:36:27 CET] <JEEB> coolio
[21:51:09 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:067485b673f6: avcodec/eac3dec: Fix runtime error: left shift of negative value
[21:51:10 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:c91bdd452481: avcodec/mjpegdec: Fix runtime error: left shift of negative value -507
[21:51:11 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:aa2b75263e17: avcodec/mpeg4videodec: Fix runtime error: shift exponent -2 is negative
[21:55:01 CET] <RiCON> atomnuker: https://i.fsbn.eu/qMNY.txt
[22:19:37 CET] <atomnuker> RiCON: https://0x0.st/4G4.diff
[22:20:09 CET] <atomnuker> apply this to git master and if it still crashes in the vector->indexing call bill gates
[22:20:19 CET] <JEEB> :D
[22:20:26 CET] <RiCON> heh
[22:34:08 CET] <RiCON> atomnuker: hey, it's a different error now!
[22:34:21 CET] <RiCON> i think bill was paying attention
[22:34:34 CET] <atomnuker> is the assert triggered?
[22:34:46 CET] <RiCON> Assertion sum == K failed at C:/builds/ab/build/ffmpeg-git/libavcodec/opus_pvq.c:445
[22:35:32 CET] <atomnuker> k, can you do a full bt again (maybe its different)?
[22:35:48 CET] <RiCON> it didn't crash now, so no bt(?)
[22:35:58 CET] <atomnuker> I need to know K, N and the entire X
[22:36:06 CET] <atomnuker> ok, maybe its the same then
[22:36:08 CET] <JEEB> you can make a  breakpoint before the assert
[22:37:13 CET] <RiCON> JEEB: how's that?
[22:37:38 CET] <JEEB> http://www.unknownroad.com/rtfm/gdbtut/gdbbreak.html#BLINE
[22:37:55 CET] <JEEB> break file.c:linenr etc
[22:38:34 CET] <atomnuker> the old backtrace doesn't show X, I can't debug without it
[22:39:08 CET] <RiCON> if i set the break in the same line as the assert does it break before or on it?
[22:39:35 CET] <JEEB> also you can break way before and step 's' from there
[22:40:26 CET] <RiCON> seems it's before
[22:40:34 CET] <RiCON> atomnuker: bt full: https://i.fsbn.eu/MxI9.txt
[22:41:08 CET] <atomnuker> RiCON: can you print X?
[22:43:45 CET] <RiCON> just "print X" exactly? says there's no symbol in context
[22:47:05 CET] <atomnuker> RiCON: k, apply this diff (git reset --hard the old one): https://0x0.st/4Gg.diff
[22:47:27 CET] <atomnuker> it'll print the X, K and N and abort, no need for a backtrace
[22:58:24 CET] <iive> RiCON: if you are in gdb, it breaks inside the libc assert, so you have to move 1 frame up. the command is "up"
[22:59:13 CET] <iive> oh, you had breakpoint before that.
[23:01:38 CET] <RiCON> atomnuker: https://i.fsbn.eu/v1ek.txt should i call bill gates after all?
[23:05:21 CET] <RiCON> tried another sample, worked; another one, same values of X/K/N
[23:05:43 CET] <JEEB> and the failure only happens on mingw-w64?
[23:06:39 CET] <atomnuker> RiCON: god damn it now I need y[] as well
[23:06:42 CET] <RiCON> should try 32-bit too
[23:06:45 CET] <atomnuker> unless its the same
[23:06:49 CET] <atomnuker> which makes no sense at all
[23:07:08 CET] <atomnuker> I'm getting y[0] = 128, and y[1] = 0, which sums up to 128 so its correct
[23:07:25 CET] <atomnuker> the y values from the backtrace don't look valid at all
[23:07:33 CET] <atomnuker> hold on, I'll send you another diff
[23:08:34 CET] <atomnuker> RiCON: k, apply this  https://0x0.st/4GU.diff after resetting the old one
[23:12:39 CET] <RiCON> atomnuker: y[0] = 2147483520; y[1] = -2147483648
[23:13:15 CET] <nevcairiel> int_max and int_min, eh
[23:15:18 CET] <atomnuker> RiCON: a yet another diff which just zeroes out y: https://0x0.st/4GG.diff
[23:16:01 CET] <atomnuker> I think the pvq search function is getting miscompiled
[23:16:42 CET] <atomnuker> (its very simple, how does msvc screw up?)
[23:17:05 CET] <RiCON> this is gcc though
[23:18:50 CET] <atomnuker> even weirder then because fate passes on a 14 year old gcc version
[23:19:06 CET] <RiCON> same y values, btw
[23:19:38 CET] <atomnuker> dunno then, what gcc version are you on?
[23:19:54 CET] <RiCON> 6.3.0
[23:20:11 CET] <RiCON> not nevcairiel's, msys2's
[23:23:23 CET] <atomnuker> RiCON: compile this c file https://0x0.st/4G5.c using gcc <file> -lm and run it
[23:24:16 CET] <iive> is vectorizations still disabled by configure?
[23:24:41 CET] <atomnuker> it'll fuzz the pvq search algorithm until it fails
[23:25:29 CET] <atomnuker> if it doesn't print an error within a few minutes it won't ever
[23:30:22 CET] <RiCON> atomnuker: you miss adding stdint.h?
[23:30:35 CET] <RiCON> or was it supposed to find int64_t with just those?
[23:31:08 CET] <JEEB> stdint is needed
[23:31:48 CET] <iive> hum, configure have --disable-optimizations. that should be using -O1 so no vectorization 
[23:32:39 CET] <atomnuker> RiCON: seems so, add it and see if it crashes
[23:33:59 CET] <RiCON> is is supposed to crash eventually?
[23:37:32 CET] <atomnuker> nope, its not
[23:37:45 CET] <atomnuker> if it crashes, it means the pvq search is broken
[23:38:50 CET] <atomnuker> if it doesn't crash I guess gcc miscompiles it when inlining and compiling opus_pvq.c
[23:40:35 CET] <atomnuker> RiCON: try this diff: https://0x0.st/4DN.diff
[23:40:44 CET] <atomnuker> it replaces the pvq search with the libopus pvq search
[23:41:25 CET] <atomnuker> if it still crashes then I can finally rule out the PVQ search
[23:43:11 CET] <RiCON> i'll also compile with both 32 and 64-bits this time
[00:00:00 CET] --- Mon Feb 20 2017