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 606689 - Re-send codec data on GstForceKeyUnit
Re-send codec data on GstForceKeyUnit
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 0.10.23
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-01-12 00:31 UTC by Olivier Crête
Modified: 2010-05-10 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Design docs update for resending codec key data (1.58 KB, patch)
2010-01-12 00:31 UTC, Olivier Crête
none Details | Review
x264enc: Re-send the received upstream event as-is downstream (2.92 KB, patch)
2010-01-12 00:31 UTC, Olivier Crête
committed Details | Review
rtph264pay: Re-send SPS/PPS when requested (3.77 KB, patch)
2010-01-12 00:33 UTC, Olivier Crête
none Details | Review
rtph264pay: Re-send SPS/PPS when requested (3.74 KB, patch)
2010-01-19 19:56 UTC, Olivier Crête
committed Details | Review

Description Olivier Crête 2010-01-12 00:31:29 UTC
Created attachment 151206 [details] [review]
Design docs update for resending codec key data

It seems that in some cases, we want to resend the codec data (like the SPS/PPS in H.264 or the Theora header) on GstForceKeyUnit, but in somes cases we don't (RTCP XR FIR vs RTCP XR PLI).

So I think it should be stated in the event, either positively or negatively. I'm entirely undecided on which to choose, my demo implementation has a "send-codecdata" boolean, but I don't like the name much. Ideally, the previously intended behavior should be kept, but I'm not sure what that behavior was.

Also, for this to work, the downstream event needs to preserve the properties of the upstream one. I added some code that copies the event, changes the type and sends it back downstream to theoraenc and rtph264enc. Maybe there is a better way to do it.

Third interrogation is who should be resending these things. I implemented it in rtph264pay, but maybe it should be the encoder. Otherwise, muxers that react to this event will also have to keep it.
Comment 1 Olivier Crête 2010-01-12 00:31:56 UTC
Created attachment 151207 [details] [review]
x264enc: Re-send the received upstream event as-is downstream
Comment 2 Olivier Crête 2010-01-12 00:33:10 UTC
Created attachment 151208 [details] [review]
rtph264pay: Re-send SPS/PPS when requested
Comment 3 Wim Taymans 2010-01-13 12:01:05 UTC
send-codecdata is not a good name. In vorbis/theora, the headers are not in the codec_data but need to be sent too.

I was thinking about something simple like: 'all-headers' which would default to FALSE. When TRUE, all headers that are in the caps (codec_data or otherwise) and that can also be included in the data stream should be resent.
Comment 4 Olivier Crête 2010-01-13 19:54:25 UTC
Or maybe "no-headers" in the (imho rare) case where we don't want the full headers ? Also, do you think the muxers should store them (if they implement GstForceKeyUnit) or should the encoder re-send it?
Comment 5 Olivier Crête 2010-01-19 19:56:51 UTC
Created attachment 151783 [details] [review]
rtph264pay: Re-send SPS/PPS when requested
Comment 6 Mark Nauwelaerts 2010-05-10 13:13:28 UTC
commit 7f685c4a2133e4762bcc82f080a95a43967aa28d
Author: Olivier Crête <olivier.crete@collabora.co.uk>
Date:   Fri Jan 8 20:51:56 2010 -0500

    x264enc: Re-send the received upstream event as-is downstream

    https://bugzilla.gnome.org/show_bug.cgi?id=606689


commit 34d0d591422f8d1c2285ecfd3e7ba9edf3acd892
Author: Olivier Crête <olivier.crete@collabora.co.uk>
Date:   Fri Jan 8 22:13:59 2010 -0500

    rtph264pay: Re-send SPS/PPS when requested

    https://bugzilla.gnome.org/show_bug.cgi?id=606689