<div dir="ltr"><div><div>My pipeline is as follows, reading an rtp stream<br><br></div>udpsrc -> rtpbin -> demux -> (video and audio)<br>  video -> queue -> (transcoding elements) -> rtpbin -> udpsink<br></div><div>  audio -> queue -> (transcoding elements) -> rtpbin -> udpsink<br><br></div><div>The latency at the sink elements is around 1100ms and the 2 queues initially contain around 1000-1500ms (41 buffers in the video queue, 57 in the audio queue)<br><br></div><div>I attach a graph of what happens to the size of the queues over the course of several days. They grow quite considerably to around 3700ms (94 buffers in the video queue, 146 in the audio queue)<br><br></div><div>This implies that the rtp data leaving the sink(s) is lagging further and further behind the source over time. <br></div><div><br></div><div>Why does the latency algorithm allow this? The latency at the sink is 1100ms but the packets are some 3700ms old at this point. Why don't the sinks pull the data through faster to maintain the correct latency?<br><br><br><br></div><div><br></div><br></div>