GNOME Bugzilla – Bug 693581
rtph264depay ! avdec_h264 crash on NULL decoder pointer in gst_video_decoder_get_frame ()
Last modified: 2013-07-23 12:10:39 UTC
this pipeline segfault: gst-launch -e -v -m -t rtspsrc location=rtsp://... ! rtph264depay ! video/x-h264,stream-format=avc,alignment=au ! h264parse ! ffdec_h264 ! xvimagesink sync=false here is the trace for 0.10
+ Trace 231504
Thread 140737112643328 (LWP 8186)
while this one works fine: gst-launch -e -v -m -t rtspsrc location=rtsp://... ! rtph264depay ! video/x-h264,stream-format=byte-stream,alignment=nal ! h264parse ! ffdec_h264 ! xvimagesink sync=false the attached file is captured using this pipeline: gst-launch -e -v -m -t rtspsrc location=rtsp://admin:4321@192.168.2.149:4524/5/ ! gdppay ! filesink location=/tmp/capture.gdp you can reproduce the segfault with gst-launch filesrc location=/tmp/capture.gdp ! gdpdepay ! rtph264depay ! video/x-h264,stream-format=avc,alignment=au ! h264parse ! ffdec_h264 ! xvimagesink the segfault is reproducible in both 0.10 and 1.0 (changing ffdec_h264 with avdec_h264)
Created attachment 235693 [details] sample capture
please note that this is a regression, the camera and the provided sample works fine with good 0.10.31 and bad 0.10.22
h264parse has nothing to do with it, it crashes even if you remove that from the pipeline. Moving to gst-libav for now.
no the problem is in rtph264depay, works fine reverting this commit http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?h=0.10&id=053f33adc8bd1325c01ef373469dc116ec624346
Well, it crashes inside the decoder, so my working hypothesis is that there is a problem in the decoder. It should ever crash. It may well be that there is also a problem with that commit, but it could also be that the change just triggers a bug in the decoder. In any case, thanks for the pointer.
yes, maybe there is something in the decoder too, however: - reverting the above rtph264depay commit: gst-launch filesrc location=capture.gdp ! gdpdepay ! rtph264depay ! h264parse ! matroskamux ! filesink location=test.mkv the produced mkv file is playable by any player (mplayer, vlc ecc..) - without reverting the rtph264depay commit: gst-launch filesrc location=capture.gdp ! gdpdepay ! rtph264depay ! h264parse ! matroskamux ! filesink location=test.mkv the produced mkv file does not play in vlc, mplayer show only grey frames and print this errors: [h264 @ 0x7fd7878cc380]Missing reference picture [h264 @ 0x7fd7878cc380]decode_slice_header error [h264 @ 0x7fd7878cc380]concealing 396 DC, 396 AC, 396 MV errors
The problem is two-fold.. First, the stream is broken, the first two packet contain what it claims to be a 2247 bytes SPS. I suspect that this is not true. The patch you identified actually reads that SPS from the data stream and puts it in the caps overriding the one in the sprop-parameters-set. Second, it seems that our libav plugin crashes if you give it an invalid SPS. That said, fixing this crash will not allow you to read that stream.
The invalidity of the RTP stream is that you have two concatenated NAL units in there, which you can only do inside a special aggregation packet. But there is no such packet, instead they're being split into two packets because it's too big using a Fragmentation unit (ie, the ooposite of a aggregation packet).
You can work around the problem using a pipeline like this one, which will concatenate all of the NAL unit, then let the parser split them: rtph264depay ! video/x-h264, stream-format=byte-stream ! h264parse ! avdec_h264
Created attachment 237004 [details] [review] avviddec: Initialise opaque from the start The crash is caused by opaque not being initialised because the caps actually secretely contain a buffer. So the buffer goes out on the setcaps, before the opaque pointer has been set. So one option is fix the crash, it to set the opaque pointer earlier
Created attachment 237005 [details] [review] avdec: Don't crash if a frame is produced during the open Alternatively, one can just let ffmpeg initialise the buffer and stuff..
I like the first patch, is there any reason not to do that? (Not that I know the code well)
Olivier?
Committed the first variant. Thanks ! commit 2556cb325a1bf973ba2cd4e66749c5e58c99d866 Author: Olivier Crête <olivier.crete@collabora.com> Date: Wed Feb 20 20:50:15 2013 -0500 avviddec: Initialise opaque from the start https://bugzilla.gnome.org/show_bug.cgi?id=693581