Choppy audio when using playbin to play DVB TS

[Chris Tapp]

On 1 Jan 2015, at 06:17, Duncan Palmer <dpalmer at digisoft.tv> wrote:

> On 31 December 2014 at 19:29, Chris Tapp <opensource at keylevel.com> wrote:
> 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.
> 
> 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.
> 
> I see the pipeline you've sent me uses a fakesink for video - do you still get the audio problems with this pipeline? 

Sorry, should have sent a graph with xvimagesink for the video path. My app uses a fakesink and the problem is the same.

What seems strange to me is the video is good when the audio is breaking up, which makes me think this isn't a simple buffering problem. 

> 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?

The default clock does come from the audiosink. I've tried using the GstSystemClock, but that didn't make the glitches go away. I'm not sure if there's an easy way to get at the buffering information, but I'll have a look.

> 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?

I'm not sure. Also worth a look I think.

> That's all a little bit vague, but hopefully of some help.

--

Chris Tapp
opensource at keylevel.com
www.keylevel.com

----
You can tell you're getting older when your car insurance gets real cheap!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150101/0ff7e24e/attachment-0001.html>