Clock / queue issue

[Sebastian Dröge]

On Mi, 2015-12-23 at 16:20 +0000, David Jaggard wrote:
> 
> 
> On 23 December 2015 at 15:44, Sebastian Dröge <sebastian at centricular.
> com> wrote:
> > Which demuxer is this? Are you transferring MPEG-TS over RTP? 
> Yes it's going in to rtpmp2tdepay and tsdemux.

I would recommend trying without MPEG-TS first. MPEG-TS adds another
layer of timestamping on top of RTP, which could cause problems here.

By not using MPEG-TS we could at least check if the problem is because
of MPEG-TS or a generic problem.

> > Does the same happen if you only
> > output the audio/video directly to a sink without transcoding and
> > also
> > without sending over the network again?
> I'll have to set those scenarios up separately and they will take a
> long time to run.

That would be good to know in any case. It would allow to isolate the
problem and will safe a lot of time for further debugging.

> >  
> > The clock-slaving algorithm implemented in rtpbin (rtpjitterbuffer
> > to be exact) should prevent such problems if caused by clock drift
> > between the sender and receiver clock.
> Forgive my ignorance on this but why would this pipeline need to care
> about clock drift? Should it not just take each frame as it arrives
> and process it as fast as possible such that the output frame rate
> would be identical?

No, because udpsink is going to sync the buffers to the clock before
sending them. This prevents in the normal case that buffers are sent
faster than real-time. For your case (where the input is only provided
in real-time anyway), you could also try setting sync=false on the
udpsinks but in general that's not recommended and it would be better
to find the underlying problem here.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151224/3c5eda51/attachment.sig>