Clock / queue issue

[David Jaggard]

My pipeline is as follows, reading an rtp stream

udpsrc -> rtpbin -> demux -> (video and audio)
  video -> queue -> (transcoding elements) -> rtpbin -> udpsink
  audio -> queue -> (transcoding elements) -> rtpbin -> udpsink

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)

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)

This implies that the rtp data leaving the sink(s) is lagging further and
further behind the source over time.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151223/4b6a63db/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Graph.png
Type: image/png
Size: 38990 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151223/4b6a63db/attachment-0001.png>