Buffer PTS drifts into the future

[Sebastian Dröge]

On Thu, 2016-10-20 at 14:30 +0100, Martin Beynon wrote:
> Hi All,
> 
> I have a very simple Gstreamer (using version 1.6.0 at present)
> pipeline running on an Embedded ARM system:
> [...]

You should try with 1.8 ideally, there were many RTP related fixes.
Nothing specifically about this here, but it might still help.

> Example after running for a couple of minutes: 
>     Pipeline Clock:[16905692471587] Pipeline Base
> Time:[16662001463649] Buffer PTS:[243730006699]. A little
> calculation: 
>         clock - base = running time 
>         (16905692471587 - 16662001463649) = 243691007938, which is
> less than PTS: 243730006699 (bad).
> 
> And just for reference - the first buffer to arrive at the appsink:
>     Pipeline Clock:[16663381713212] Pipeline Base
> Time:[16662001463649] Buffer PTS[480006699]. A little calculation: 
>         clock - base = running time 
>         (16663381713212 - 16662001463649) = 1380249563, which is
> greater than the PTS: 480006699 (good).

How do you calculate the PTS? In an rtspsrc pipeline, the buffer PTS
and running time of the buffer should always be the same.

Or do you mean at the appsink the packet is arriving late, i.e. buffer
running time is less than clock running time, and that difference is
steadily increasing?

If that is the case, you'll have to check the PTS calculation in
gst-plugins-good/gst/rtpmanager/rtpjitterbuffer.c to see where things
go wrong there.

Also is this with a TCP based or UDP based RTP stream? For TCP based
streams we currently don't do proper translation between the sender and
receiver clocks, which might cause such problems. However for TCP this
is also far from trivial due to all the buffering in the protocol and
the inherent non-realtime'ness. Detecting and fixing up cases where
things slowly drift apart should be possible to detect though once it
reaches a specific threshold, that would have to be implemented there
though.

-- 
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: 931 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20161024/60ffdf33/attachment.sig>