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 705108 - rtpgstpay: Add a config-interval property
rtpgstpay: Add a config-interval property
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal enhancement
: 1.1.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-29 22:42 UTC by Youness Alaoui
Modified: 2013-08-21 07:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Youness Alaoui 2013-07-29 22:42:17 UTC
When we use rtpgstpay/rtpgstdepay, sometimes the inlined caps will be lost (lost packet or new client joining mid-stream, for example), so there is a need to retransmit the caps as well as the tags at a regular interval.
I've added a config-interval property (similar to rtph264pay) to rtpgstpay that will retransmit the caps and tags to the client at a regular interval. By default, the interval is set to 0 (disabled) so there is no change in behavior.
Some small refactoring was needed for this implementation, and also, rtpgstpay will now merged the tags it receives (similar to what audiobasedecoder will do) in order to resend the full tags.
The GST_EVENT_STREAM_START is now also being payloaded as it is needed to detect when tags need to be flushed on the receiver end, in case we switch sources mid stream.
You will find the patches that implement this feature here : http://cgit.collabora.com/git/user/kakaroto/gst-plugins-good.git/log/?h=rtppay
Please review/merge.
Comment 1 Sebastian Dröge (slomo) 2013-07-30 07:39:10 UTC
You probably want to resend all sticky events periodically here. Also the depayloader should drop everything before it gets caps.
Comment 2 Youness Alaoui 2013-07-30 21:31:08 UTC
There aren't any other events that rtpgstpay sends.. it only sends the GST_EVENT_TAG, GST_EVENT_CUSTOM_DOWNSTREAM and GST_EVENT_CUSTOM_BOTH, and I don't think the custom events should be resent. That's why I'm only resending the tags and caps events.

Good point about dropping everything in the depayloader from stream-start to caps, but the depayloader doesn't receive a caps event, it only receives rtp packets with the header containing the caps index to use.. so the first packet will contain the caps already.. and if it doesn't, then the depayloader will drop the packets anyways since it doesn't know what caps they have.

Anyways, I was told that the stream-start can be sent as an 'update' without the need for a new-segment or caps event, and it doesn't seem to affect the sink either since it receives the stream-start without new-segment/caps, and it works fine.

(FYI: the header contains a 3 bit field containing the caps index, each packet will have this field telling what the caps of the data is, if the caps are new, the index is incremented and the next data packet will contain inlined-caps (as a string) preceding the data and a 1 bit flag will be enabled in the header to say that this packet contains inlined flags. The depayloader will drop any packets that has a caps index which it has not already cached.)
Comment 3 Sebastian Dröge (slomo) 2013-08-12 11:00:27 UTC
Ok, in that case this change sounds good to me.
Comment 4 Wim Taymans 2013-08-21 07:44:29 UTC
merged now