After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 693581 - rtph264depay ! avdec_h264 crash on NULL decoder pointer in gst_video_decoder_get_frame ()
rtph264depay ! avdec_h264 crash on NULL decoder pointer in gst_video_decoder_...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal critical
: 1.1.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-02-11 11:52 UTC by Nicola
Modified: 2013-07-23 12:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample capture (492.45 KB, application/octet-stream)
2013-02-11 11:56 UTC, Nicola
  Details
avviddec: Initialise opaque from the start (1.08 KB, patch)
2013-02-21 01:53 UTC, Olivier Crête
committed Details | Review
avdec: Don't crash if a frame is produced during the open (1.68 KB, patch)
2013-02-21 01:54 UTC, Olivier Crête
rejected Details | Review

Description Nicola 2013-02-11 11:52:32 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

Thread 140737112643328 (LWP 8186)

  • #0 g_static_rec_mutex_get_rec_mutex_impl
    at /build/buildd/glib2.0-2.32.3/./glib/deprecated/gthread-deprecated.c line 676
  • #1 g_static_rec_mutex_lock
    at /build/buildd/glib2.0-2.32.3/./glib/deprecated/gthread-deprecated.c line 711
  • #2 gst_video_decoder_get_frame
    at gstvideodecoder.c line 2675
  • #3 gst_ffmpegviddec_get_buffer
    at gstffmpegviddec.c line 630
  • #4 alloc_frame_buffer
    at libavcodec/mpegvideo.c line 262
  • #5 ff_alloc_picture
    at libavcodec/mpegvideo.c line 314
  • #6 MPV_frame_start
    at libavcodec/mpegvideo.c line 1221
  • #7 ff_h264_frame_start
    at libavcodec/h264.c line 1284
  • #8 decode_slice_header
    at libavcodec/h264.c line 2960
  • #9 decode_nal_units
    at libavcodec/h264.c line 3862
  • #10 ff_h264_decode_extradata
    at libavcodec/h264.c line 1070
  • #11 ff_h264_decode_init
    at libavcodec/h264.c line 1139
  • #12 avcodec_open2
    at libavcodec/utils.c line 816
  • #13 gst_ffmpeg_avcodec_open
    at gstffmpeg.c line 52
  • #14 gst_ffmpegviddec_open
    at gstffmpegviddec.c line 375
  • #15 gst_ffmpegviddec_set_format
    at gstffmpegviddec.c line 524
  • #16 gst_video_decoder_sink_setcaps
    at gstvideodecoder.c line 723
  • #17 gst_pad_set_caps
    at gstpad.c line 2730
  • #18 gst_pad_chain_data_unchecked
    at gstpad.c line 4252
  • #19 gst_pad_push_data
    at gstpad.c line 4511
  • #20 gst_pad_push
    at gstpad.c line 4735
  • #21 gst_base_parse_push_frame
    at gstbaseparse.c line 1967
  • #22 gst_base_parse_chain
  • #23 gst_h264_parse_chain
    at gsth264parse.c line 1948
  • #24 gst_pad_chain_data_unchecked
    at gstpad.c line 4276
  • #25 gst_pad_push_data
    at gstpad.c line 4511
  • #26 gst_pad_push
    at gstpad.c line 4735
  • #27 gst_base_transform_chain
    at gstbasetransform.c line 2687
  • #28 gst_pad_chain_data_unchecked
    at gstpad.c line 4276
  • #29 gst_pad_push_data
    at gstpad.c line 4511
  • #30 gst_pad_push
    at gstpad.c line 4735
  • #31 gst_base_rtp_depayload_push_ts
    at gstbasertpdepayload.c line 610
  • #32 gst_base_rtp_depayload_chain
  • #33 gst_pad_push
    at gstpad.c line 4715
  • #34 gst_pad_push
    at gstpad.c line 4715
  • #35 gst_pad_push
    at gstpad.c line 4715
  • #36 gst_pad_push
    at gstpad.c line 4715
  • #37 gst_rtp_jitter_buffer_loop
    at gstrtpjitterbuffer.c line 1916
  • #38 gst_task_func
    at gsttask.c line 328
  • #39 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.32.3/./glib/gthreadpool.c line 309
  • #40 g_thread_proxy
    at /build/buildd/glib2.0-2.32.3/./glib/gthread.c line 801
  • #41 start_thread
    at pthread_create.c line 308
  • #42 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #43 ??

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)
Comment 1 Nicola 2013-02-11 11:56:49 UTC
Created attachment 235693 [details]
sample capture
Comment 2 Nicola 2013-02-12 15:00:01 UTC
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
Comment 3 Tim-Philipp Müller 2013-02-13 19:20:03 UTC
h264parse has nothing to do with it, it crashes even if you remove that from the pipeline. Moving to gst-libav for now.
Comment 4 Nicola 2013-02-13 21:30:33 UTC
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
Comment 5 Tim-Philipp Müller 2013-02-13 21:43:34 UTC
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.
Comment 6 Nicola 2013-02-18 12:40:35 UTC
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
Comment 7 Olivier Crête 2013-02-21 01:11:40 UTC
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.
Comment 8 Olivier Crête 2013-02-21 01:20:08 UTC
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).
Comment 9 Olivier Crête 2013-02-21 01:21:40 UTC
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
Comment 10 Olivier Crête 2013-02-21 01:53:28 UTC
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
Comment 11 Olivier Crête 2013-02-21 01:54:00 UTC
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..
Comment 12 Tim-Philipp Müller 2013-03-01 21:36:57 UTC
I like the first patch, is there any reason not to do that? (Not that I know the code well)
Comment 13 Tim-Philipp Müller 2013-03-12 23:10:43 UTC
Olivier?
Comment 14 Edward Hervey 2013-07-23 12:05:45 UTC
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