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 613995 - rtph264depay: weak decoders can error out in case data is provided them before SPS/PPS
rtph264depay: weak decoders can error out in case data is provided them befor...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-03-26 10:06 UTC by Marco Ballesio
Modified: 2012-10-26 20:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (1.87 KB, patch)
2010-03-26 10:06 UTC, Marco Ballesio
none Details | Review

Description Marco Ballesio 2010-03-26 10:06:23 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;
 };
Comment 1 Wim Taymans 2011-05-24 09:07:33 UTC
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.
Comment 2 Tim-Philipp Müller 2011-05-24 09:19:39 UTC
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).
Comment 3 Marco Ballesio 2011-05-24 09:28:59 UTC
(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).
Comment 4 Tim-Philipp Müller 2012-10-26 20:20:20 UTC
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.