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 427990 - [rtph264depay] sprop-parameter-set erros
[rtph264depay] sprop-parameter-set erros
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 0.10.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-04-09 19:43 UTC by Holger Freyther
Modified: 2007-05-01 08:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Holger Freyther 2007-04-09 19:43:12 UTC
There are two errors regarding the sprop-parameter-set handling.

1.) the used sync bytes violate the h264 standard. Two null byte's are passed, according to the standard an additional "zero_byte" needs to be set for sps and pps.

2.) the created buffer is cleared and not pushed to the deocder. This is due
 if (GST_BUFFER_IS_DISCONT (buf)) { evaluating to TRUE in gst_rtp_h264_depay_process.

As a quick work around I added something to the lines of
-  if (GST_BUFFER_IS_DISCONT (buf)) {
+  if (!rtph264depay->wait_start && GST_BUFFER_IS_DISCONT (buf)) {

but I have not put much thought into it and don't know enough of the GStreamer core to judge this approach.
Comment 1 Wim Taymans 2007-04-10 10:19:55 UTC
1) ok, is this needed only for the config data in sprop-parameter-sets or also for each payload data? It seems to work both ways with ffmpeg decoders.

2) I think the code is correct. The DISCONT flag should only be set when there is a discontinuity in the buffers (missing packets), in which case, we clear the state of the depayloader and wait for a packet with the S bit set or for a non-fragmented payload. How exactly is this causing problems for you?
Comment 2 Holger Freyther 2007-04-12 14:01:22 UTC
1.) AFAIK the "zero_byte" is needed for each SPS and PPS. But the ffmpeg decoder is quite forgiving anyway.

2.) For DVB-H (probably others as well) sending the SPS and PPs Nalus inline (as part of the stream) violates the specification. So 2.) causes a problem if you have a conformant streaming server. The only way to set them is to use the sprops-parameter-sets but the manually queued nalus never reach the decoder, they are cleared on the first process. So my unverified, uneducated guess is that DISCONT is set for the first buffer/payload received.
I could send you the result of --gst-debug=XYZ:A if you are interested.
Comment 3 Wim Taymans 2007-04-12 14:23:14 UTC
OK, I think I fixed both problems in CVS now. The sprop parameters were usually discarded by the depayloader when it received the first packet (because DISCONT was set, as you suggested). For 1) I just use 0,0,0,1 as the 4 byte sync word now.
My streams seem to work fine still.

Can you retest?
Comment 4 Tim-Philipp Müller 2007-04-28 09:49:52 UTC
Holger: ping? Is this fixed now?
Comment 5 Holger Freyther 2007-04-28 10:05:29 UTC
Sorry for the delay, I will test it on monday. I have looked at the patch and it seemed to be fine.
Comment 6 Holger Freyther 2007-04-30 21:21:05 UTC
I can confirm that passing sprops-parameter-set out-of-line is working.
Comment 7 Tim-Philipp Müller 2007-05-01 08:00:53 UTC
Great, thanks for confirming.