<div dir="ltr"><div><div><div><div><div>I really hope someone can help me tackle this issue:<br></div><div><br></div><div>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?<br></div><div><br>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.<br><br></div>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. <br><br></div>If I leave it overnight and connect VLC again in the morning the audio is now ahead of the video.<br><br></div>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? <br><br></div>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.<br><br></div>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?<br></div>