RP-NDI-PTPv2_2010

proposal for PTPv2 genlock in ndi

This page contains a technical proposal which is not currently a published or formal standard. If you have comments or feedback on the content of this proposal PLEASE contact us with your contribution.

 

The NDI IP Video protocol SDK does not currently offer any formal interface with PTPv2 clocks which are widely used in AES67 and SMPTE2110 workflows.  At the junction of NDI and SMPTE/AES67 worlds, there is a requirement for NDI to access the PTPv2 clock sources used in the SMPTE2110 and AES67 Data streams. For example - where an AES67 Stream must be produced from an NDI source, it will be necessary to know the current PTPv2 Grandmaster Clock ID, and also to establish an anchor between the PTPv2 Time, and the start timestamp of the NDI Stream. During the stream, it may also be necessary to identify and correct any drift between the PTPv2 Grandmaster clock and the NDI computer CPU Clock (although there will be no drift if the CPU clock is already synchronised with PTPv2.

 

This proposal defines a metadata message which can be sent as a synchronising feed (similar to a traditional genlock) to NDI receivers providing a PTPv2 time reference which can be compared with the CPU time, and used when constructing outgoing AES67 or SMPTE2110 streams. The message also provides the Grandmaster ID which must be declared with the stream announcement in order to define the reference clock to be used.

 

NDI has a real time metadata message which can carry this data. This document is an attempt to standardise support for PTPv2 genlock in order to prevent different implementations by each vendor by way of a recommended practice technical note.

 

Basic Premise:

The focus is based on the need to provide a feed of PTPv2 time and GMID via an NDI stream to be used like a genlock.

 

This metadata is generated as a Metadata-only NDI stream by a device or software which has direct access to PTPv2 data and can dispatch this data as NDI to propogate it to receivers. It is accepted that the process of replicating PTPv2 over NDI will affect the tolerance and accuracy of the received clock data, but it is anticipated that it will still be sufficiently accurate to be useful.

 

Example :

ndi_metadata_frame.p_data =

<PTPv2>

<GMID>00-10-4b-ff-fe-7a-87-3d</GMID>

<DOMAIN>0</DOMAIN>

<TIME>21564484188184<TIME>

</PTPv2>

 

The GMID is the GrandMaster ID of the currently elected system grand master. TIME is PTPv2 current time translated into NDI Time (100 nSec granularity). DOMAIN is the ptpv2 domain on which the clock was discovered. The metadata packets will also carry the source timestamp of the sending system, plus the receiver can reference their own system time. With all this information to hand it becomes possible to interface between the 2 worlds.  The timecode field of the metadata packet also contains the NDI Time equivalent of the PTPv2 clock.  These messages may arrive at any frequency although they should be expected at least once per second or thereabouts

 

This proposal has been implemented into the Sienna NDI Processing Engine's PTP_Converter module which reads the PTPv2 state from the network and outputs NDI_PTPv2 synchronising messages.

 

If you have any questions, or you would like to engage Sienna for NDI Consultancy or Custom Development, please contact info @ sienna.tv

appsupport @ gallery.co.uk