[Bug 654850] rtph264depay adds one frame of latency in access-unit aggregation mode

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Jul 25 11:17:18 PDT 2011


https://bugzilla.gnome.org/show_bug.cgi?id=654850
  GStreamer | gst-plugins-good | git

--- Comment #10 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2011-07-25 18:17:14 UTC ---
Created an attachment (id=192627)
 View: https://bugzilla.gnome.org/attachment.cgi?id=192627
 Review: https://bugzilla.gnome.org/review?bug=654850&attachment=192627

rtph264depay: Make output in AVC stream format work even without complete
sprop-parameter-set

This allows outputting streams in AVC format even if the SPS/PPS are sent
inside
the RTP stream.

With the current patches, it works great with gst-dsp, because it doesn't try
to do AU aggregation, but gst-ffmpeg will re-introduce the frame of latency,
because it will wait for the start of the next AU before starting to decode the
current one. So, sending it in AVC format fixes that, except that AVC only
works if the SPS/PPS are in the caps, so we have to parse them out of the RTP
stream and delay setting the SPS/PPS have arrived.

There is one problem with that, the GstBaseRTPDepayload base class doesn't
allow us to return the not-negotiated error back if the setcap fails, so we
just ignore it.. But I guess it will get an error on the push, so it shouldn't
be too bad, I guess.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list