Introduction
In our previous whitepaper entitled ‘Transparent vs. Boundary Clocks (PTP) in Broadcast Environments, we offered a ten-thousand foot view of PTP in the broadcast IP environment to introduce the concept of PTP for broadcast engineers, technicians, system integrators and anyone interested in the subject. Riedel has deployed ST2110 systems around the world and has found a common set of challenges are always present during ST2110 deployments. For this reason, we created a new whitepaper on the takeaways from our different experiences. But first, let us return briefly to our previous PTP whitepaper: SMPTE uses PTP as the synchronization mechanism for video, audio and metadata over IP, and the AES uses PTP for AES67 synchronization. The following figure (Figure. 1) shows the typical configuration of a network with PTP. Figure 1. Video and Time Reference in an IP Media Facility (courtesy of Michel Proulx)
TAKEAWAYS FROM DEPLOYMENTS
The following sections provide an overview of the key takeaways from our various installations around the globe. The goal of this document is to highlight some key points that the Riedel team discovered during deployment in various systems. Our team understands that the ST2110 specification, moving forward, will add more key points and we consider those as equally important as the ones covered in this document. We will do our best effort to keep this document up to date to help our customers avoid roadblocks and pitfalls. 04 | Subject to change without notice. Errors and omis sions exce
PTP: BACKBONE OF THE ST2110
DEPLOYMENT
One of our team’s most important takeaways: Without a stable and constant PTP, the ST2110 system will not work or will only partially work with glitches on video and pops in the audio. It is preferable that your system has at least one PTP Grandmaster to be considered synchronous in ST2110 specification. The Riedel team considers the PTP Grandmaster as mandatory for ST2110 deployments, just as Black Burst or Tri-Level Sync is mandatory in an SDI installation. A key action for SDI studios and installations is to synchronize every incoming feed with the studio's Black Burst reference to ensure the vertical blanking is aligned. In ST2110, there is no vertical blanking, but all the ‘0’ pixels should be aligned. This is achieved with PTP and timestamping. PTP acts just like a Black Burst reference signal. The major difference when using PTP, compared to a legacy reference signal, lies in the definition of an absolute origin point in time (1970-01-01T00:00:00TAI), defined as SMPTE Epoch. PTP time is zero at Epoch and then starts counting forward up to now. Similarly, a video signal synchronized to PTP would have its VSYNC occur at the SMPTE Epoch and then, at every frame rate increment up to now. In an ST2110 system, alignment between video sources and PTP reference is done through a timestamping mechanism. Every field/ frame of video is timestamped using the value of the PTP time when its VSYNC (hereafter defined as the alignment point) occurs. In the case of multiple video streams, timestamps in the packets should all be in sync for the receiver to welcome all synchronized feeds and subsequently allow for desired processing.
Takeaway:
One PTP Grandmaster is mandatory for any ST2110 deployment. Riedel can guide you in the choice of a PTP Grandmaster.
ptp VS sdi synchronization
Having a PTP in the system is mandatory, but during the transition from an SDI system to ST2110, a synchronization between the PTP and the Black Burst (SDI sync) is also critical. Of course, frame synchronizers can fix free-run SDI incoming feeds. ST2110 is used widely within a studio environment, and therefore latency is critical. To minimize delay, it is a good practice to synchronize the SDI inputs with the studio/plant reference before the gateway. Otherwise, the incoming signals will need to be frame- synchronized with the PTP, which adds one frame of delay (Figure 2.). Figure 2. Sender with Frame Sync on PTP SMPTE Standard ST2059-1 defines that the feed should be locked on the PTP alignment point (AP). In addition, the ST2110-10 Standard defines synchronous senders as senders aligned to PTP. The specification also defines asynchronous sender types not synchronized to PTP, which will therefore need a frame sync before or inside of the 2110 encapsulator. The majority of deployed systems are using synchronous senders. 04 | Subject to change without notice. Errors and omissions exp
NON-EPOCH-AWARE SIGNAL
GENERATOR VERSUS EPOCH-
AWARE PTP GENERATOR
Bridging between SDI and IP brings some challenges between Non-Epoch-Aware equipment and Epoch-Aware generators. Legacy signal generators aren’t always Epoch-Aware; these generators were used to lock on the frequency, but not necessarily on phase or any defined Epoch. Nowadays, signal generators and PTP generators are Epoch-Aware (ST2059-1), which makes them lock on both phase and frequency. The following figure (Figure 3.) shows the offset (between the AP and the VSYNC) that can occur when the studio legacy Black Burst is not phase-aligned with SMPTE Epoch. Figure 3. Offset Between Non-Epoch-Aware VSYNC and PTP Alignment Point
Takeaway:
In an ST2110 receiver, there is no provision for adjustable compensation offset. Riedel products have compensation offset engines to enable you to use Non-Epoch-Aware signal generators.
PTP VS. MULTI-ESSENCE STREAM
SYNCHRONIZATION
When working with an ST2110 system, all the SDI essences, i.e. video, audio and ANC, are transmitted over IP separately. You then need a way to link back together those separated streams when required. This is achieved using packet timestamping. The PTP Grandmaster's time must be used to generate those ST2110 timestamps, as it is the unique common point of reference in the system for all the streams. When correctly timestamped on the sender side, a receiver will always be able to realign all of its incoming multi-essence streams, regardless of the delay difference between the paths in the network. That realignment, based on PTP time, is critical to ensure a clean and quiet switching between sources. A non-negligible advantage of having correctly timestamped packets at sources, is that it is easier to avoid lip-sync errors. The figure below (Figure 4.) shows different senders, with video and audio essences or video essence only, transmitting timestamped packets over different network paths, all up to one receiver device. This receiver places incoming video and audio into their respective buffer space and realigns everything at its output, reading the right packet, (i.e.: the one with the timestamp to be read, from the buffers according to the PTP time value).
Takeaway:
In an ST2110 system, a PTP Grandmaster, along with synchronous sources, is critical to allow for correct realignment of several multi- essence streams. Riedel receivers have realignment engines to make sure essences at the output are well aligned together and to the PTP reference. 04 | Subject to change without notice. Errors and omissions exce
GRANDMASTER, BOUNDARY
CLOCK, SLAVE LOAD
It is important to understand the role of each clock type. Please see the Riedel whitepaper entitled “Transparent Vs Boundary Clocks (PTP) in Broadcast Environments" that touches on this subject: https://www.riedel.net/fileadmin/user_upload/800- downloads/07-Guides/Transparent_versus_Boundary_Clocks.pdf
UNDERSTANDING THE NETWORK
CLOCK TREE
The clock tree choice will impact the amount of PTP traffic going around the network. In an ideal network, the Grandmaster would only see boundary clocks, which themselves are master to their respective downstream slave devices. This makes scaling easier, reduces traffic to the Grandmaster and makes policing of traffic much easier. In Figure 5., the PTP Grandmaster only sees two (2) slave clocks. Adding a slave clock to group A or group B will not impact the Grandmaster. These groups can grow or change as required. Some of the downsides of having the slave clock directly connected to the Grandmaster include increased workload, limited system scalability and challenges to traffic policing (as some slave devices might not support a certain type of PTP message mode, Ex: Slave A-2 supports only multicast messages and Slave B-1 supports only hybrid modes). Figure 6. Uncontrolled Slave Clock Connection to Grandmaster | Subject to change without notice. Errors and omissions ex
Brief overview of PTP message types:
Unicast: All messages between slave and master are unicast. Multicast: All messages between slave and master are multicast.
Takeaway:
Riedel recommends a Grandmaster-to-boundary clock architecture to facilitate scalability, reduce traffic to the Grandmaster and make policing of traffic much easier.
QOS IMPORTANCE FOR PTP vs. SDI ESSENCE AND MANAGEMENT TRAFFIC
If PTP traffic shares the same physical transport medium as ST2110 essences, then it is important to establish a priority by traffic type. PTP packets are small compared to essence flows (either -20, -30 or -40). The time interval between PTP packets will be longer than any essence packets. If the bandwidth of the transmission medium is reached, the packets most likely to be dropped are the PTP packets, and the timing reference will be lost or affected (See Figure 8. & 9.). Video (-20) Audio (-30) ¼ ANC (-40) 04 | Subject to change without notice. Errors and omissions exo
Takeaway:
Riedel recommends prioritizing PTP packets by employing policies on high bandwidth usage. Riedel can help with policy guidelines.
CONCLUSION
PTP is the backbone of any ST2110 deployment. Riedel recommends one PTP Grandmaster as mandatory for any ST2110 deployment to be considered synchronous with ST2110 specification. The PTP Grandmaster, along with synchronous sources, is critical to allow for correct realignment of several multi-essence streams. A Grandmaster-to-boundary clock architecture will facilitate scalability, reduce traffic to the Grandmaster and make policing of traffic much easier. In an ST2110 system, receivers must have realignment engines, like the ones Riedel offers, to make sure essences at the output are well- aligned with one another and with the PTP reference. As ST2110 receivers don't allow for adjustable compensation offset, it is important to integrate product solutions, such as those from Riedel, that include compensation offset engines to enable the use of Non-Epoch-aware signal generators. Finally, Riedel recommends prioritizing PTP packets by employing policies on high bandwidth usage. -04 | Subject to change without notice. Effors and omissions exce