The ST 2110-2x Documents

SMPTE 2110-2x standards describe how to construct real-time video stream flows in broadcast systems. They coexist with standards from other organizations and incorporate them where necessary.

ST 2110 reserves the range for part numbers 20 to 29 for video related topics. Part 20 is the most complex and the others enhance it for specific situations.

ST 2110-20 – Uncompressed Active Video

Production mandates that quality is more important than bandwidth efficiency. Hence, ST 2110 part 20 describes the delivery of uncompressed video via RTP streams over an IP network.

The 2017 edition of ST 2110-20 has been superseded by the 2022 edition. A side-by-side comparison of both editions reveals a few differences:

• Alpha channel support now added.
• Signaling for the ST 2115 LOGS3 transfer characteristic is introduced.
• Some bibliographic references have been updated.
• Improved descriptions based on the Protocol Implementation Conformance Statement (PICS) for ST 2110 (which is a work in progress).
• Some details from ST 2110-21 have been incorporated.

Note: The document with a footer indicating the approval date 28-03-2022 contains errors. They are corrected in the version republished on 14-12-2022.

Part 20 is based on these VSF technical recommendations:

• TR-03 – Technical Recommendation for Transport of Uncompressed Elementary Stream Media Over IP.
• TR-04 – Utilization of ST-2022- 6 Media Flows within a VSF TR-03 Environment.

The Video Services Forum have published additional useful guidance as Technical Recommendation TR-05. This was released in 2018 and is based on the 2017 edition of ST 2110-20. Read this carefully because the specification pre-dates the revised 2022 edition of 2110-20.

Uncompressed (lossless) video is delivered using RTP with additional signaling sent via SDP (Session Description Protocol) to tell the destination how to interpret the incoming stream. This is based on earlier work in ST 2022-6. The stream requires enough bandwidth to support a large payload.

The latency depends on how much work is required to convert the incoming source into the elementary streams and unpacking it at the receiver. Audio and ancillary data are delivered separately.

The RTP payload format is described by IETF RFC 4175 with additional color sampling modes described by RFC 4421.

ST 2110-21 – Traffic Shaping & Delivery Timing

Traffic shaping is important for managing the available bandwidth where multiple elementary streams are delivered via the same route. If all the streams burst at the same time, the network would become saturated and the streams would break down due to packet loss. They might also overwhelm a receiver by filling its input buffer.

Traffic shaping also helps to avoid packet jitter where the packet delivery times become irregular. Jitter causes problems with the precision timing of packets. Part 21 describes two alternative scenarios with SDP parameters that signal the timing properties of each RTP stream:

• Network Compatibility Model – The network will cope with many streams without overflowing the switch buffers or queues. This relies on a receiver buffer being drained at least as fast as new packets are arriving.
• Virtual Receiver Buffer Model – The sequence of packets will not underflow nor overflow receiver buffers because they enter the buffer and leave it immediately. This also relies on packets arriving in a timely manner so the buffer is never empty when the next packet needs to be accessed. Because packets are taken from the buffer at regularly timed intervals, the jitter is eliminated.

RTP Stream Senders

The RTP stream senders are defined as one of three basic types. The narrow senders adhere to a more accurate timing resolution and tend to be hardware based. Wide senders are software driven.

Narrow Gapped senders (Type N) may suspend transmission during the vertical blanking interval. Data derived from the vertical blanking period may be transmitted on ANC streams during those gaps.

Narrow Linear senders (Type NL) transmit their packets at a steady and constant cadence.

Wide senders (Type W) are used for software implementations that have more flexible timing than the hardware-based type N and NL senders. Packet times may be earlier or later than a linear sender.

The receivers are designed to handle bursts of packets in different ways. This will reduce the jitter that could disrupt the PTP:

• N – Narrow – Supports bursts of up to 4 packets and is compatible with type N or NL senders.
• W – Wide Synchronous – Supports bursts of up to 20 packets and is compatible with type N, NL and W senders provided they are locked to the same common time-source used by the receiver.
• A – Wide Asynchronous – Similar to the type W receiver but does not need to be locked to the same time-source as the sender.

ST 2110-22 – Constant Bit-rate Compression

Originally ST 2110 only supported the uncompressed video described in part 20. Part 22 adds constant bitrate compressed video using one of the registered codecs. Other acceptably fast codecs may be registered in due course:

• VC-2 (AKA Dirac)
• JPEG-XS

The compressed output is lossy but visually unimpaired. The losses are small enough that chroma-keying is unaffected. These are fast codecs with a coding latency of less than 1ms on sufficiently fast hardware/software. This is equivalent to just a few lines of video. The compression ratio and hence the reduced network bandwidth depend on the complexity of the content. VC-2 has quoted a compression ratio better than 5:1 and JPEG-XS might be between 10:1 and 20:1.

If these compression ratios are achievable, then it resolves one of the major bandwidth limitation criticisms levelled at the circa 2017 (four-part) ST 2110 design.

The latency needs for ST 2110 probably rule out using AVC and HEVC codecs due to the time it takes to compress video with them. With advanced hardware solutions, you may be able to reduce their latency to an acceptable level.

ST 2110-22 constant bitrate delivery is broadly similar to ST 2110-20. Some parameter settings are specific to this format and the video codec is configured for constant rather than variable bitrate.

Although it is designed to be format agnostic, ST 2110-22 expects to carry video coded with one of the known registered codecs. Other codecs are likely to be registered in due course.

Be careful to use the correct version of the standard when deploying compatible equipment or software. Specifying ST 2110-22 alone is not enough without indicating which edition is being deployed. The ST 2110-22:2019 and ST 2110- 22:2022 documents are different editions of the same standard with slightly different coding strategies.

As well as a few corrections, the 2022 revision clarifies the requirements for traffic shaping and delivery timing. The sender type N option is also added.  In order to distinguish the version, the SMPTE Standard Number (SSN) is now included in the SDP signaling metadata to distinguish between these two variants.

RP 2110-23 – Uncompressed Active Parallel Video

Part 23 is published as a recommended practice document and is not a formal standard. If a single network link has insufficient capacity, RP 2110-23 extends part 20 to describe how to split a high-bandwidth video stream into multiple lower bandwidth streams. This is similar to how a high speed ‘Supermotion’ camera operates. The output streams have lower frame-rates and are created according to several different interleaving decompositions. The same net amount of data is moved via several alternative routes but each stream can be accommodated within the available bandwidth.

The Session Description Protocol (SDP) describes the decomposition method being used so that the receiver can correctly reconstruct the picture.

These points are addressed by RP 2110-23:

• Several alternative decomposition methods.
• Grouping of multiple streams.
• Signaling the stream availability.
• SDP declarations.
• Addressing conventions.
• RTP time-stamping constraints.

The receiver combines the frames from the incoming streams to recreate the footage at the original frame-rate.

This recommended practice document may only be of interest to organizations that are working with very high-resolution images. Image sizes of 4K and higher may require such a huge bandwidth that a single network link is overwhelmed.

Note: This technique only works with uncompressed streams. It would be impractical to use this with previously compressed video streams.

Sample Interleaving

ST 425-5 and ST 2082-12 describe how to interleave samples. This allows a lower resolution preview image to be reconstructed from any single stream. All four streams are required to reconstruct the complete image. ST 2082-12 has a detailed explanation of the Sample Interleaving decomposition technique:

RP 2110-23 also offers a simpler solution which divides an image into quadrants. This is called Square Division decomposition:

High data rates also arise from lower definition video running at very high frame rates. Super-motion cameras are used at sporting events for slow-motion action replays. They divide the video along the time axis (Temporal Division decomposition) and deliver the frames in a cyclic manner across several streams. Observing a single stream previews the video at a lower frame-rate:

RP 2110-24 – Special Considerations For SD Video

Part 24 is published as a recommended practice document. It refines the definition of the pixel sampling in a line of Standard Definition (SD) video in the source material. It accounts for the following:

• 525 vs 625 lines.
• 4:3 vs 16:9 pixel aspect ratios.
• Horizontal image size.
• Additions to ST 125 that describe the original analog source video timings.

RP 2110-24 describes how to map the Image Format Line Numbers specified in ST 125 to correspond with the Sample Row numbers defined by ST 2110-20.

The media type parameters for height and width in ST 2110-20 are derived from the video area defined in ST 125.

Refer to RP 202 which describes how interlaced video must be properly (vertically) aligned prior to compression. This will affect the height value.

ST 2110 Part 20 should be reviewed before studying this document as it relates to the formatting of the line-by-line video content into RTP packets.

RP 2110-25 – Measurement Practices

The European Broadcasting Union (EBU) has contributed their testing protocols to facilitate the integration of systems from different manufacturers. Use these protocols to monitor and analyze the traffic to indicate failures. This is particularly helpful when analyzing how the content is buffered. The probing tools must not disturb or slow down the flow of the network packets.

Recommended practice RP 2110-25 describes this EBU research and provides insights about the internal structures and processes within ST 2110. It also provides example code.

Diagnostic techniques are based on the same core principles of measurement, observation and divide/conquer, regardless of the type of architecture being inspected. Insert test-probes and analyze network traffic in the same way that you might have used an oscilloscope to analyze the analog video signals. The tools may be different but the process is the same.

RP 2110-25 illustrates how to analyze traffic down to the IP datagram level where the dispatch and arrival times for each packet are visible.

Study this document carefully and use it to develop automated monitoring tools to watch the system continuously. If any measurements depart from the expected nominal values, trigger an alert to warn the ops team so they can intervene. Monitoring tools must run separately from the main workflow and cannot interrupt or delay the packets being transmitted.

Section 4 describes the measurements as they apply to various ST 2110 parts. Refer to these sections in the various ST 2110 documents to see them in context:

Example testing code written in the Python language is provided in Appendix B of the recommended practice document. This will help to analyze how the content is buffered.

Rewrite the tests in a more efficient language for networks having higher throughput. Systems level programming is ideally coded in ANSII Standard C-Language and compiled down to directly executed machine code (perhaps with the free GNU CC compiler – gcc).

Languages such as Python, Perl, JavaScript and Java are executed via an interpreter which adds a performance overhead that compiled C-Language avoids.

Consider using Objective-C coding paradigms (also compiled by gcc) as this facilitates building complex object-based data structures that can be easily serialized into an RDBMS data system for storage and later analysis.

Relevant Standards

Obtain copies of the documents listed in the Normative References section of each standard. IETF RFC documents and ITU recommendations should be easy to acquire. The VSF technical recommendations are also free to access.

The vintage column describes a release date where a specific revision of an associated document is referred to from other standards. This is not always the very latest version and some problems with integration between systems from different manufacturers may be due to different revisions of the standards being used to design their products.

Further Study

In addition to the SMPTE ST standards documents, there are many Recommended Practice (RP) documents that support them. Joining the SMPTE organization as an associate member is not expensive and gives access to all of their standards documents free-of-charge. This is a very worthwhile benefit and SMPTE should be applauded for that gesture. The AES offers a similar incentive.

ST 2110 also relies on many other standards bodies and expert groups. Most of these (other than ISO) also offer their standards documents free of charge.

Looking ahead, there are royalty free open-source codecs on the horizon that will likely be registered within ST 2110. If these encode the video with sufficient performance, they could be used with ST 2110-20. If they provide constant bitrate variants, they will augment ST 2110-22.

These Appendix articles contain additional information you may find useful: