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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ajit Warrier
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

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

Olivier Crête-3
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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-- 
Olivier Crête [hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel