GNOME Bugzilla – Bug 769536
rtpjitterbuffer: new faststart-min-packets property
Last modified: 2017-06-28 15:52:37 UTC
It is used to control the amount of time before the first buffer is pushed. If it gets pushed and a subsequent buffer is missing, there will be a pause in playback. By default, it is -1, which means the start delay is equal to the latency. If a buffer is missed, this will cause a gap equal to the latency minus the start delay, but a client prefers this, so it may be something that's of wider interest.
Created attachment 332769 [details] [review] new start-delay property
The use-case for this is you have a pipeline like "udpsrc ! rtpbin ! decoder ! encode ! rtpbin ! udpsink sync=false", you only use the jitterbuffer to re-order buffers, not really to remove jitter. So the jb size is very big, because having a mis-ordered packet means a really ugly gitch, but we want to send out the first buffer really early. The final receiver has a fully functional jitterbuffer that will remove the jitter that this may introduce. I wonder if we could include a bit of this documentation in the property description so that others who try to implement this kind of pipeline would be interested.
Comment on attachment 332769 [details] [review] new start-delay property This is a new feature, so lets punt to 1.11 and it will give time for other people to comment.
Can you help me understand how this is different from a statically configured latency on the pipeline? I don't think this start delay could be used to synchronize multiple endpoints, correct?
Review of attachment 332769 [details] [review]: ::: gst/rtpmanager/gstrtpjitterbuffer.c @@ +1958,3 @@ + full latency. */ + if (priv->start_delay_ms >= 0 && !priv->buffer_missed) + test_timeout += priv->start_delay_ms * 1000000; Can we use GST_MSECOND here instead of a giant number?
The start-delay does not interfere with the latency. It's just that currently, if packets are received in ordre, the jitterbuffer will push them out immediately, it only waits up to "latency" if there is a gap. But there is one exception to that: it's the first buffer, where it always waits up to latency! This property reduces the delay that the jitterbuffer waits before pushing the first buffer tto "start-delay" instead of "latency".
Created attachment 339478 [details] [review] new start-delay property
Review of attachment 339478 [details] [review]: A delay is a bit arbitrary. The goals in waiting here is to make sure that we don't endup dropping packets due to reordering (specially initially, since you want your keyframe with certain codec). Maybe instead we could implement a fast start that rely on something we can trust. I think a good metric would be to start if we have received 3 packets with consecutive seqnum.
(In reply to Nicolas Dufresne (stormer) from comment #8) > Maybe instead we could > implement a fast start that rely on something we can trust. I think a good > metric would be to start if we have received 3 packets with consecutive > seqnum. That already exists in rtpsource.
(In reply to Sebastian Dröge (slomo) from comment #9) > (In reply to Nicolas Dufresne (stormer) from comment #8) > > Maybe instead we could > > implement a fast start that rely on something we can trust. I think a good > > metric would be to start if we have received 3 packets with consecutive > > seqnum. > > That already exists in rtpsource. I think it totally makes sense to use the same heuristic in rtpjitterbuffer to avoid filling all the queues at start and giving the decoder a little more leeway.
Why two layers of the same thing? :)
Because we want the jitterbuffer to accumulate some packets? And also I think there are othe conditions where the rtpsource can validate a source?
rtpjitterbuffer already accumulates packets until "latency" before it outputs anything
Yeah, the goal is to accumulate less than the full latency, just enough to be reasonably sure we didn't miss the first one.
Created attachment 354263 [details] [review] rtpjitterbuffer: Add a fast-start-delay property This delay allow the jitter buffer to start delivering packets as soon as N most recent packets have consecutive seqnum. A fast-start-delay or zero disables this feature. This heuristic is also used in rtpsource base on RTP Spec recommendation. The recommended delay is 3 packets.
I just remembered that this is called probation in rtpsource, maybe I could name the property in relation to that, could be "start-probation", does it sound better/worst ?
Created attachment 354533 [details] [review] rtpjitterbuffer: Add a fast-start-delay property v2: Don't override head boolean, just raise it to TRUE if timer was updated v2: Didn't do any renaming yet, any opinion on the naming ? This delay allow the jitter buffer to start delivering packets as soon as N most recent packets have consecutive seqnum. A fast-start-delay or zero disables this feature. This heuristic is also used in rtpsource base on RTP Spec recommendation. The recommended delay is 3 packets.
Created attachment 354582 [details] [review] rtpjitterbuffer: Add a faststart-min-packets property v3: Renamed the property and update some doc When set this property will allow the jitterbuffer to start delivering packets as soon as N most recent packets have consecutive seqnum. A faststart-min-packets of zero disables this feature. This heuristic is also used in rtpsource which implements the probation mechanism and a similar heuristic is used to handle long gaps.
Created attachment 354629 [details] [review] rtpjitterbuffer: Add a faststart-min-packets property v4: Added doc comment block with a Since marker When set this property will allow the jitterbuffer to start delivering packets as soon as N most recent packets have consecutive seqnum. A faststart-min-packets of zero disables this feature. This heuristic is also used in rtpsource which implements the probation mechanism and a similar heuristic is used to handle long gaps.
Attachment 354629 [details] pushed as bbe0053 - rtpjitterbuffer: Add a faststart-min-packets property