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

[burek]

[00:14:58 CET] <cone-165> ffmpeg 03Andreas Cadhalpun 07master:564dd3f0f400: mpeg4videodec: silence ubsan warning
[01:05:52 CET] <cone-165> ffmpeg 03Michael Niedermayer 07master:d7c75a5db0cf: avcodec/motion_est: Attempt to fix "short data segment overflowed" on IA64
[01:29:00 CET] <tmm1> anyone know offhand where/how ffmpeg deals with timestamp resets in mpegts streams?
[01:36:30 CET] <Compn> i forgot to tell gajjanag that imo, maybe its better to work on things which  wm4 doesnt oppose as strongly...
[03:06:16 CET] <cone-165> ffmpeg 03Michael Niedermayer 07n2.5.10:HEAD: avcodec/motion_est: Attempt to fix "short data segment overflowed" on IA64
[09:35:46 CET] <wm4> Compn: don't
[09:39:26 CET] <durandal_1707> Compn: only talk if asked
[14:19:04 CET] <cone-256> ffmpeg 03Mats Peterson 07master:a51c8a68adbe: lavf/mov: Don't limit fourcc 0 -> raw/twos to version 0 sample descriptions
[14:19:05 CET] <cone-256> ffmpeg 03Mats Peterson 07master:535d09a51099: lavf/matroskadec: Get sample size from private data
[18:49:37 CET] <cone-256> ffmpeg 03Michael Niedermayer 07master:057549a9ccc9: avcodec/aacenc: Check both channels for finiteness
[19:30:18 CET] <philipl> BtbN: What state do you consider your vp8 change to be in. It looks like it's not setting curframe at all (or rather, the code that sets it is part of what's excluded in the hwaccel path, I think)
[19:34:34 CET] <philipl> Yeah, so you can't return immediately in decode_frame after calling the hwaccel hooks.
[19:35:35 CET] <BtbN> It's unfinished
[19:36:09 CET] <BtbN> I couldn't test it yet, so it's very likely there are some mistakes in it.
[19:37:12 CET] <philipl> To be sure. I was just trying to work out what the current state of the world is.
[19:37:25 CET] <philipl> I can now get it to crash in libva. progress!
[19:44:46 CET] <philipl> I'm impressed they could make vp8 more complicated than vp9
[19:45:22 CET] <BtbN> it's primarily those 3 strange bitstream parsing offset value it wants
[19:45:26 CET] <BtbN> no idea what it expects there
[19:46:15 CET] <wm4> philipl: why is that? is it an actual complication, or did VP9 just simplify something?
[19:48:45 CET] <philipl> BtbN: Yeah. I suspect it's segfaulting due to that. The other TODOs would be visual glitches at worst.
[19:48:59 CET] <philipl> wm4: There's some stupid bitstream parsing implementation detail that leaked
[19:49:17 CET] <philipl> which they handled more intelligently for vp9 (they being intel)
[19:49:46 CET] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/va_dec_vp8.h#n45
[19:49:52 CET] <BtbN> these 3 values, to be specific
[19:50:06 CET] <BtbN> They coinditentialy match exactly with how gst parses the VPx bitstream
[19:51:06 CET] <wm4> lol
[19:57:01 CET] <philipl> THe obvious solution is to bring the gstreamer parser into avcodec.
[19:57:17 CET] <wm4> no, everyone should just drop lavc and use gstreamer
[19:57:24 CET] <philipl> Good point.
[20:02:32 CET] <philipl> this shit is indecipherable.
[20:02:44 CET] <philipl> How can they need something so obtuse when there's no equivalent in avcodec
[20:04:58 CET] <BtbN> philipl, you are aware of the libva tracing features? So you can look at what values gst puts in those fields, and compare with some lavc ones?
[20:05:39 CET] <philipl> I'm vaguely aware. I'll do that if it comes down to it
[20:06:13 CET] <BtbN> LIBVA_TRACE=/pathto/tracelog LIBVA_TRACE_BUFDATA=1
[20:06:16 CET] <BtbN> or something like that
[20:11:10 CET] <philipl> I think I've found the identity of two of the fields in the avcodec range decoder
[20:25:18 CET] <philipl> Ok. So I've roughly, been able to map the funny values to those in the range decoder we use (the vp56 thing)
[20:25:44 CET] <philipl> It didn't crash on playback this time but it did freak the hardware out. Lots of warnings in dmesg and green frames, etc
[20:31:34 CET] <philipl> Time for lunch. So it doesn't crash but hardware is much unhappy. Long delay before playback starts (as a result) and then green frames.
[20:31:57 CET] <philipl> There's some differences in the internal state of the decoders. Probably time to bust out the tracing.
[20:32:03 CET] <philipl> But I'm off for lunch now.
[20:32:11 CET] <philipl> Thanks gstreamer and intel for the endless hours of fun.
[20:38:46 CET] <atomnuker> anyone knows how the bitstream writer works?
[20:39:00 CET] <atomnuker> do you have full reign over the memory you've asked to be allocated?
[20:40:34 CET] <atomnuker> or does it get written as soon as you've put some amount of data in?
[20:42:13 CET] <atomnuker> because the Dirac encoder I wrote does some nasty stuff yet gets away it with
[20:55:14 CET] <durandal_170> atomnuker: what nasty stuff?
[20:56:20 CET] <atomnuker> writes like a megabyte of data and goes back to the start to overwrite some previously written stuff
[20:57:41 CET] <durandal_170> if not sent to muxer I see no issue
[21:15:43 CET] <jamrial> and gcc 6 is now miscompiling svq1enc
[21:18:00 CET] Action: wm4 mumbles something about the importance of svq1enc
[21:18:12 CET] <wm4> does it break fate?
[21:19:18 CET] <jamrial> yeah
[21:20:20 CET] <jamrial> some change commited to gcc trunk in the last three days is at fault
[21:21:23 CET] <jamrial> compiling svq1enc.c with -O1 makes the fate test succeed, so it's some optimization enabled by -O2 and above
[21:21:25 CET] <durandal_170> report gcc 6 bug
[21:21:39 CET] <jamrial> i'll after i bisect to find the first bad commit
[21:22:09 CET] <Daemon404> jamrial, you should suggest they add FATE or something to gcc's tests
[21:22:16 CET] <Daemon404> didnt they add x264 already
[21:22:17 CET] <jamrial> and i hate this kind of bug. it's hard to reproduce and gcc devs hate reports that are "download an application, build it, run this test suit to reproduce the issue"
[21:22:19 CET] <Daemon404> or somethign akin to this
[21:22:31 CET] <Daemon404> ... they buidl a compiler
[21:22:34 CET] <jamrial> they want a tidy looking code snipped in the bug description
[21:22:34 CET] <Daemon404> it builds applications
[21:22:44 CET] <jamrial> snippet
[21:22:57 CET] <Daemon404> i would argue that it's not teh job of the bug reporter
[21:22:58 CET] <Daemon404> but thats me
[21:26:04 CET] <wm4> they probably get far too weird shit that's not debuggable this way
[21:26:13 CET] <wm4> and too much of it
[21:26:15 CET] <jamrial> last time i reported a miscompilation bug i explained how to reproduce it with instructions to compile ffmpeg and run the fate test (no need to download samples for that one)
[21:26:41 CET] <jamrial> their reaction was "we're waiting for a testcase"
[21:27:01 CET] <jamrial> because they prefer reports like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68990
[22:05:07 CET] <cone-603> ffmpeg 03Michael Niedermayer 07master:aa6aa2ef0918: avcodec/wmaenc: Check input for finiteness
[23:38:27 CET] <philipl> BtbN: So I've got the coder crap mostly correct. There's one edge case where the values come out wrong. Don't see the pattern yet.
[23:39:01 CET] <BtbN> strange stuff
[23:40:01 CET] <philipl> indeed. and I'm pretty sure it won't magically work when I fix it either :-)
[23:42:00 CET] <philipl> Yeah, so there's a few frames where the 'range' value in gst is shifted one bit to the left, the 'count' is one less and the 'value' is shifted one to the left with a '1' shifted in.
[23:42:14 CET] <philipl> The difference seems consistent in all cases. But as to why...
[00:00:00 CET] --- Sun Jan 17 2016