Transmit absolute time
pietro_bonfa at yahoo.it
Thu Oct 15 02:42:27 PDT 2015
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
> 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
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.
More information about the gstreamer-devel