<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 31 December 2014 at 19:29, Chris Tapp <span dir="ltr"><<a href="mailto:opensource@keylevel.com" target="_blank">opensource@keylevel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""></span><div>If I leave the buffer settings at their defaults, then the whole stream breaks up and it keeps pausing to buffer every few seconds. If it makes any difference, the DVB TS is a live source.</div></div></div></blockquote><div><br></div><div>With your settings, I see that the multiqueue has been configured by the decodebin to allow plenty of buffering, so that's fine. I guess its however uridecodebin configures queue2 that causes you grief with the default buffer settings.<br><br></div><div>I see the pipeline you've sent me uses a fakesink for video - do you still get the audio problems with this pipeline? <br></div><div><br>It sounds like your pipeline is being starved - can you see how much data is buffered in the queue elements? I've never used gstreamer for DVB playback, but have plenty of experience with other DVB stacks. These stacks often use an 'stc offset' to block data at the equivalent of the synchronizer element for a few hundred ms (time equal to the stc offset), forcing upstream buffering. Too much jitter, or too small an stc offset is a common cause of pipeline startup problems in these stacks. In your case, the pipeline is (I think) being clocked by the audio sink, and the tsdemux will modify the PTS/DTS values in the transport stream to account for clock drift between the audio clock and headend. I'm not sure how buffering is forced - perhaps this is your problem?<br><br>There will be an variable offset of up to 2 seconds between audio and video PTS in your stream. So, audio will arrive at the synchronizer element much earlier than video. I'm not sure how the synchronizer element deals with this - does it send the audio on it's way, or wait for the first video to arrive?<br><br></div><div>That's all a little bit vague, but hopefully of some help.<br></div><div><br><br></div></div></div></div>