GNOME Bugzilla – Bug 670735
Crash when decoding H.264 stream
Last modified: 2012-12-14 00:42:45 UTC
gstreamer-ffmpeg 0.10.13 using the built-in libav. I've also raised this at http://bugzilla.libav.org/show_bug.cgi?id=230 being unsure where the bug actually lies. The stream is coming out a hardware encoder which puts it on the network (UDP multicast) as a MPEG TS with H.264 video and AAC audio. Regularly, maybe once per hour or so, the decoder crashes. For example: [118325.648389] multiqueue0:src[4260]: segfault at e508f ip 00007f657763c38c sp 00007f65627f9788 error 4 in libgstffmpeg.so[7f657721c000+7ea000] Traceback looks like this:
+ Trace 229738
Smallest stream which triggers the crash is 1.9Mb and as such I can't attach it here. You can get it from the libav.org bugzilla.
And if I replace internal libav with ffmpeg 0.7.11 or 0.9.1 crash is gone. Upgrading to libav 0.7.4 and crash still happens.
However just decoding the stream with ffmpeg command line and I don't see the crash. (ffmpeg -i <file> -f null -)
> However just decoding the stream with ffmpeg command line and I don't see the > crash. (ffmpeg -i <file> -f null -) You should probably close the libav bug then, for now at least.
This does not crash any more with libav 0.9 and gst-libav in git master (but also not with the 1.0.x branch). There's an audible gap in the audio, and some visual artefacts and libav warnings though: $ gst-launch-1.0 playbin uri=file:///home/tpm/samples/misc/670735-colossus-crash2.ts Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock 0:00:01.898384296 5552 0x1f12800 ERROR libav :0:: left block unavailable for requested intra mode at 0 15 0:00:01.898449877 5552 0x1f12800 ERROR libav :0:: error while decoding MB 0 14, bytestream (93) 0:00:01.953423908 5552 0x1f12800 ERROR libav :0:: get_buffer() failed (-1 2 (nil)) 0:00:01.953503527 5552 0x1f12800 ERROR libav :0:: decode_slice_header error Got EOS from element "playbin0". Execution ended after 0:00:03.727817834 but it plays exactly like in VLC, so let's close this. Please re-open if you still have issues with 1.x, thanks for the bug report and sample!