How to debug this issue?

[David Jaggard]

I really hope someone can help me tackle this issue:

The <tl;dr> version: how can I tell if a queue is buffering too much data
and causing the video stream to lag the audio stream? Can I flush it to put
thing back in sync?

A live mpegts stream is demuxed into video and audio streams. The streams
are decoded and re-encoded before passed to rtpbin and then to multicast
udp sinks as 2 rtp sessions.

Initially when I connect VLC to these 2 streams they play in sync. If I
wait a few hours and then connect VLC the streams are still in sync.

If I leave it overnight and connect VLC again in the morning the audio is
now ahead of the video.

I guess there is some issue with the live stream overnight which causes
some audio data to be missed so the audio pipeline jumps ahead as soon as
it receives the next valid audio packet. Is this plausible?

I am running a test in parallel to prove this theory: I recorded a short
clip from the live mpeg ts stream and use a multifilesrc to play it on a
loop through the same pipeline as above. This has been running overnight
and the audio and video of this stream are still in sync when I connect VLC.

In order for the video to lag behind the audio one (or more) of the queues
I have in the video pipeline must be buffering extra data. How can I detect
this in code and maybe flush the buffer so the video and audio are back in
sync?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151204/27228085/attachment.html>