GNOME Bugzilla – Bug 613995
rtph264depay: weak decoders can error out in case data is provided them before SPS/PPS
Last modified: 2012-10-26 20:20:44 UTC
Created attachment 157147 [details] [review] patch In case a weak decoder is connected to the depayloader, it may give an error (or worst crash) in case depayloaded data is provided it before any NALU containing parameter sets is sent. Strictly speaking, the bug is in the decoder (and not in the depayloader) but the attached patch will improve overall robustness and should introduce no regressions (a normal H264 decoder cannot decode anything without having PSs). From 9866714aac7fed2974473854a43909be98fd68be Mon Sep 17 00:00:00 2001 From: Marco Ballesio <marco.ballesio@nokia.com> Date: Wed, 17 Mar 2010 09:49:00 +0200 Subject: [PATCH] rtph264depay: drop buffers until the first Parameter Set is received. This way a weak decoder will not error out if fed with data for which it has not been initialized. It will introduce no regressions as in theory no h264 decoder should be able to decode raw payload for which it didn't get parameters. --- gst/rtp/gstrtph264depay.c | 20 ++++++++++++++++++++ gst/rtp/gstrtph264depay.h | 2 ++ 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/gst/rtp/gstrtph264depay.c b/gst/rtp/gstrtph264depay.c index f801b98..fc671c0 100644 --- a/gst/rtp/gstrtph264depay.c +++ b/gst/rtp/gstrtph264depay.c @@ -435,6 +435,26 @@ gst_rtp_h264_depay_push_nal (GstRtpH264Depay * rtph264depay, GstBuffer * nal, rtph264depay->last_ts = timestamp; gst_adapter_push (rtph264depay->picture_adapter, nal); + /* Do not push anything if no parameter set has been received. + This adds robustness in case of weak decoders.*/ + if(outbuf != NULL){ + int type; + + if(rtph264depay->byte_stream) + type = GST_BUFFER_DATA(outbuf)[4] & 0x1f; + else + type = GST_BUFFER_DATA(outbuf)[0] & 0x1f; + + if(type == 7 || type == 8) + rtph264depay->ps_recv = TRUE; + + if (!rtph264depay->ps_recv){ + GST_DEBUG_OBJECT (rtph264depay, "got no ps, dropping buffer\n"); + gst_buffer_unref(outbuf); + outbuf = NULL; + } + } + return outbuf; } diff --git a/gst/rtp/gstrtph264depay.h b/gst/rtp/gstrtph264depay.h index 838dbd9..d17fbc0 100644 --- a/gst/rtp/gstrtph264depay.h +++ b/gst/rtp/gstrtph264depay.h @@ -54,6 +54,8 @@ struct _GstRtpH264Depay GstAdapter *picture_adapter; gboolean picture_start; gboolean picture_complete; + + gboolean ps_recv; GstClockTime last_ts; };
It's a tradeoff between handling buggy decoders and giving an early video image on robust decoders. Maybe we should negotiate this kind of information.
H.264 decoders that accept bytestream format should definitely be able to handle this, no? If output format is avc waiting for the PPS/SPS makes sense IMHO. (There's a bug about this for h264parse somewhere too, don't remember if it has been fixed or not, or maybe it was just a property that was added there and we discussed what it should default to).
(In reply to comment #1) > It's a tradeoff between handling buggy decoders and giving an early video image > on robust decoders. Maybe we should negotiate this kind of information. As long as no SPS/PPS are received, there's definitely no way an h264 decoder can show you a frame (unless there are some hacks to guess a proper PS).
The current depayloader seems to wait for SPS/PPS before outputting anything in AVC format, which is the important thing, so closing as OBSOLETE. Decoders accepting byte-stream data just need to deal (imagine an mpeg-ts demuxer just pushing data from a DVB receiver to a decoder), so WONTFIX in that respect imho. Please re-open with a patch against GStreamer 1.x if you think more needs to be done.