Confused about gstreamer rtpjitterbuffer behavior w.r.t "latency" parameter

Olivier CrĂȘte olivier.crete at collabora.com
Thu Nov 16 20:37:35 UTC 2017


Hi,
The basic behaviour of the jitterbuffer related to latency is that it
will release packets that arrive in order immediately, but will wait
until the latency is expired to release a buffer packet if there was a
gap. That is, if a packet has been lost, the next one will wait up to
"latency" in case it was not lost, but just re-ordered. The first
packet is a bit special as nothing in RTP lets us know that the first
packet is really the first packet, so as a work around, the
jitterbuffer always waits up to "latency" time before releasing it.  So
after a stop and restart, the sequence numbers are continuous.. But if
you want long enough, you may trigger one of the "reset" mechanisms of
the jitterbuffer, so it does as if it was a new packet.
That said, the playback behaviour should always be the same (playback 5
seconds later) if you correctly set the sink's "sync" property to true.
Olivier
On Fri, 2017-11-10 at 22:36 +0000, Ajit Warrier wrote:
> I am trying to fully understand how the rtp jitterbuffer works. I
> have a simple pipeline getting rtp audio packets from a udpsrc which
> is then processed by an rtpbin element and sent to the alsa sink.
> 
> I set the "latency" parameter of the rtpbin to 5s. I understand it
> maps to the enclosed rtpjitterbuffer element. Now when the stream
> first starts, there is a 5 second delay before the audio starts
> playing.
> 
> Now I stop the udp sender for a few seconds, and then start it again.
> At this time, there is no delay, and the pipeline starts playing
> immediately. However, if I stop the udp sender now, there is a 5
> second silence  after the sender has stopped. This behaviour remains
> for any subsequent start/stop of the sender.
> 
> Can anybody explain both of these behaviours ?
> 
> Thanks,
> Ajit.
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-- 
Olivier CrĂȘte
olivier.crete at collabora.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20171116/53c8984b/attachment.html>


More information about the gstreamer-devel mailing list