Transmit absolute time

[Pietro Bonfa']

Dear Sebastian,

RFC6051 looks exactly like what I need but implementing it into
gstreamer means modifying the plugins performing the RTP payload and
depay, am I correct? This sounds like a hard work for a newcomer of
gstreamer like me.

As of today, the simple approach of starting the acquisitions on the
RPis "at the same time" gives the best synchronization (since the
acquisition frequency is fixed).
For this reason a metadata stream could be a reasonable approach as long
as I'm sure I can grab all the frames. References for this approach?
Chapter 12 of the manual?

Finally, there's plenty of space in my mailbox! If you could send me (or
upload) the presentation maybe I would find some keywords to deepen this
topic.

Thanks again,
Pietro

ps: in the mean time I prepared two simple codes to check the accuracy
and the behaviour of the rtsp implementation with random delays.
First one is a merging of the netclock and appsrc examples in
rtsp-server. The receiver is a simple appsink which shows buffer timestamps.

http://pastebin.com/dTpGhKWn
http://pastebin.com/Q5u5nP0z

This gives about 0.2 msec accuracy when determining frame duration in a
localhost stream. This is not completely related to this question but
maybe it can be helpful to someone reading about this stuff.



On 10/14/2015 03:02 PM, Sebastian Dröge wrote:
> On Di, 2015-10-13 at 17:18 +0200, Pietro Bonfa' wrote:
>> My main goal is to estimate the time difference between various frames
>> acquired from many devices.
>>
>> This means I would opt for "transfer accurate timestamps as metadata" in
>> your list.
> 
> So you only need to know the timestamps, not synchronise the media
> according to them? If you use RTP/RTSP, you could use an header
> extension like the one from RFC6051. But that one is for NTP
> timestamps, you could do the same for PTP timestamps.
> Alternatively some kind of metadata stream could also be used.
> 
> For the NTP header extension, I have some half finished code here that
> needs some finishing. Additionally you would need to ensure that on the
> sender side, the pipeline is using the PTP clock and the PTP clock is
> used as the "NTP" clock for RTP.
> 
>> I really look forward to see your presentation. I searched for your
>> slides on the gstreamer website but I could not find them. Are they
>> available somewhere else?
> 
> If your mailbox is big enough, I can send them to you. Or upload them
> somewhere otherwise. But I guess they are not too useful without what I
> said during the presentation :)
> 
>> Finally, I read your post about PTP and I can correctly interface the
>> PTP server with gstreamer thanks to your work so...thank you!
>> And thanks also for your time.
> 
> You're welcome! Let me know if there's something not working well with
> these things, and how well the PTP clock works for your use cases :)
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>