Transmit absolute time

[Pietro Bonfa']

Dear Sebastian and Carlos,

thanks for this extremely stimulating discussion. Carlo's work is very
encouraging for me, it is exactly what I want to do.
I'm carefully reading your messages in order to come up with a solution
that incorporates both your comments.

With respect to Sebastian's comment about synchronisation:

On 10/15/2015 08:14 AM, Sebastian Dröge wrote:
> So, do you want *synchronisation* or just get the capture times
> according to some network clock as metadata? :)

Synchronisation is useful but not needed. My approach is so simple I can
work out the synchronization in my code outside gstreamer (see below).

>
> If you want synchronisation, see what Carlos wrote and also take a look
> at
>
http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/examples/test-netclock.c
>
http://cgit.freedesktop.org/gstreamer/gst-rtsp-server/tree/examples/test-netclock-client.c
> That's very similar to what Carlos did, but gives you not 100% accurate
> synchronisation, the RTP header extension could. The synchronisation
> will be up to 11 microseconds accurate with the example code there
> (90kHz RTP clock rate).

I tried that approach and it works amazingly well!
The only piece of information I cannot extract up to now (but it's
available in principle) is the time difference between the frames from
the various pipelines.

Just to make it clear: I have frame-grabbers working at 40 fps which are
allowed to start on every second (all times referred to synchronized PTP
clocks).
So, in principle, all frames from the frame-grabbers are like
n.000, n.025, n.050, n.075 etc etc, where n is an integer number of
seconds since a reference time (say Epoch).

In reality (considering only two frame grabbers for simplicity) I have
frame-grabber 1 acquiring frames on
n.001, n.026, n.051 etc etc

and frame-grabber 2 acquiring frames on
n.003, n.028, n.053 etc etc


So the problem here are, of course, those 2 ms and not the 11
microseconds of RTP.


>
> These two are using the GStreamer netclock, but it's a one-line change
> to make it use the PTP clock.

Yes, already done and it works great.


Thanks again,
Pietro