Increasingly, 8K formats are being used to shoot footage at major sporting events such as the Olympic games. This creates a significantly larger video data feed and even with the newer, highly advanced codecs, OB units still require higher bandwidth to contribute content to the production data center.

Real-time delivery of live content is only possible with a high enough capacity link. Although broadcasters might shoot at high resolution up to 8K onsite, they may not be about to ship that back due to insufficient bandwidth. There are some options if the necessary equipment and software with sufficient compute capacity is available locally to solve this: 

• The whole 8K image can be scaled down to a lower resolution. If you have a fast enough converter, this can happen in real-time with hardware but introduces some latency due to the conversion.
• A proxy for the 8K footage can be created and sent back so the production team can work on it with the full resolution 8K data sent via a store and forward technique that delivers files slower than real-time. That full resolution footage can be conformed to the proxy edit later. Making the proxy introduces latency.
• Footage can be edited at the remote location and sent back as lower resolution conformed products.
• The 8K image can be pan-and-scan windowed down to a lower resolution. Some latency is introduced but possibly less than scaling the whole image.

ST 2110 Implications

ST 2110 requires very precise timing from a centralized PTP (Precision Time Protocol) source. This is feasible in a single studio setting but likely near impossible to achieve between an outside broadcast unit and a production data center.

Synchronizing with multiple OB units and a central studio, not to mention planning for more flexible compute processing resources, requires buffering so that the streams can be re-aligned. Latency rears its ugly head again. 

Based on established studies, the recommendation is to operate as two independent ST 2110 timing pools each synchronized to its own local PTP. Real-world time codes can be embedded in ancillary data as the content is transported between the locations.

Because ST 2110 separates video and audio, both assets need to be marked with timestamps so they can be resynchronized at the receiving end.

Recalling the discussions on cloud-based workflows from Broadcast Bridge’s Cloud Compute Infrastructure Themed Content Collection, the transition between time-linear vs time-non-linear content is managed at the edge of the cloud. The same approach can be deployed here.

The Video Services Forum (VSF) published Technical Recommendation TR-11 describing Signal Transport and Timing Considerations for Ground-Cloud-Cloud-Ground workflows. This discusses how to cross the boundary between the two types of timing.

Dealing With Latency Issues

Here are the principal points in the delivery chain where latency is introduced:

• Ingest from camera.
• Encoding.
• Format conversion.
• Decoding.
• Compression.
• Matrix switching.
• Video effects processing.
• Embedding and de-embedding audio.
• Delivery distance.
• Choice of link transport technology.
• Network router hops.

Latency is less of a problem if the audio and video remain synchronized with each other, but once they are separated and travel via different routes, latency becomes a much bigger problem.

When it is not embedded, audio will often arrive at the receiver before the video. Some system designers suggest the optimal solution is to embed the audio into the video as early as possible (preferably in the camera) and keep it embedded all the way to the destination. Note that this is contrary to the ST 2110 approach that separates audio and video media.

It is important that the audio and video arrive at the production data center perfectly aligned even if it means they arrive later. Buffering and time-stamping is mandated to bring them back into perfect synchronization.

Primary buffering happens at the RTP protocol level to ensure that network packets have all arrived and are arranged in the correct order to start with.

Secondary buffering is used to synchronize the essence media once the video frames and audio samples are extracted from the RTP network packets.

Some workflows are more concerned with latency than others, and latency is especially critical in online betting scenarios that can be accessed by bots. It is not hard to conceive of an AI system detecting a goal on a mobile device that is present in the stadium and placing an instantaneous bet on the outcome of a match before the footage has arrived at the betting company. The betting industry is well aware of this possibility and is already working on technology solutions. Broadcasters will ultimately benefit from that work.

It has always been a good idea to look at what is going on outside of our own silo for inspiration or solutions, and this is a prime example.

Related Standards

Here is a selection of standards that describe network topologies and data transfer protocols for remote contribution. This is not an exhaustive list. Some other standards are related to these but they are not directly relevant. They are listed in the normative and informative reference sections of these documents as supporting standards.

The Internet Engineering Task Force (IETF) publishes a collection of RFC documents. One of the techniques they have developed uses a model description language called YANG. The RFC documents describe how to use YANG to create a descriptive model of network topologies. That model will be machine readable and facilitates workflow automation.

Conclusion

Understanding how different network topologies and Ethernet connectivity devices work is vital to not only better understand IP networking infrastructures, but ultimately to more efficiently deliver remotely created content contributions back to the production data center.

And cloud-based workflows can also be connected into this network infrastructure, bringing remote outside broadcast crews closer to the center of operations than has ever been possible before. With very fast links, content can be deployed in either direction and more of the production workload can be – and is – taking place remotely.