How to avoid losing even a single packet: ST 2022-7 in real-world live broadcasting

Introduction to ST 2022‑7

Published in 2013, the SMPTE ST 2022‑7 specification was developed to provide a mechanism for increasing the reliability of media data transmission over IP networks. Its key concept is seamless failover. The specification uses the Seamless Protection Switching technology, which enables the simultaneous transmission of the same RTP datagrams over multiple independent routes.

Why is this needed?

IP networks are unreliable by their nature and thus prone to packet losses, delays, and momentary disruptions. ST 2022‑7 solves this by providing redundant streams. If one route degrades or goes down, the receiving side continues to receive the data using an alternative route and reconstruct the resulting TS stream without interruptions or noticeable switching artifacts. For live broadcasting, this is critical.

This approach is common in professional settings like broadcast production and remote production where the traffic passes through a multitude of different provider networks, including dedicated links, satellite links, and the public Internet. ST 2022‑7 is also used in contribution systems to deliver the signal from field sources to the central studios as well as modern studio‑based IP media companies where stable processing of raw media content is required.

Today, major industry players, including EBU, consider ST 2022‑7 a fundamental element of a robust IP infrastructure. The Tech 3371 recommendation by EBU specifies the use of ST 2022‑7 seamless failover as a mandatory requirement for media nodes where signal continuity is critical.

In particular, ST 2022‑7 is recommended as the minimum acceptable source redundancy requirement for SDI‑over‑IP systems defined in ST 2110. Transmitting raw, uncompressed data requires a steady and stable input signal until the end of stream (EOS).

With the ongoing growth of cloud services and remote production, demand for ST 2022‑7 technology continues to rise. In scenarios like this, the traffic passes through many nodes in networks belonging to different providers, increasing the risk of individual route degradation. The specification offers a proven, deterministic mechanism whereby duplicate RTP packets are sent over alternative routes and then seamlessly assembled at the receiver, which is perfect for live streaming.
 

Operating principle of ST 2022‑7

The underlying principle of ST 2022‑7 is a simple and effective one: create duplicate media data streams and transmit them simultaneously over multiple independent routes, making it possible to significantly reduce the risk of packet loss. The packets are synchronized by the RTP header fields defined in RFC 3550.

Preparing streams for transmission

On the source side, the key role is played by the sender element — known as a splitter — that prepares the redundant ST 2022‑7 streams. It can be implemented as a separate component of the signal delivery system or as part of the transcoder or gateway.

The splitter generates at least two RTP streams identical in both the RTP headers and the payload, allowing the receiving side to seamlessly reconstruct the signal.

Each RTP packet can then be encapsulated in a transmission protocol (e.g., UDP, SRT, or RIST) and sent over different network routes to avoid creating a single point of failure.

Stream reception and recovery

On the receiving side, the receiver — known as the switcher — collects the streams from different sources and reconstructs the original stream. Like the splitter, it can also be part of the transcoder or gateway.

The receiver deencapsulates the incoming packets, extracting RTP packets as the payload and sending them to separate buffers. The buffers are used to compensate for jitter and delays.

In the buffers, the packets are sorted by the key RTP header fields, "Sequence number" and "Timestamp". If one path degrades (e.g., due to packet loss or delay), the corresponding buffer will have a gap in its data. When that happens, the switcher automatically switches to another source’s buffer which contains the missing RTP packet. The switching is imperceptible and does not affect the output stream.

RTP headers used in ST 2022‑7

ST 2022‑7 relies on the RTP header defined in RFC 3550. Two fields are key here:

• Sequence number, a 16‑bit field that provides packet numbering. Its value is incremented by one for each subsequent packet. This field is used to detect losses, order the packets in sequence, and match duplicates between streams.
• Timestamp, a 32‑bit field reflecting the point in time when the data was sampled — for example, based on the generator’s internal clock. This parameter is needed to synchronize duplicate streams.

Another important variable for delay compensation is buffer size. It is determined by the difference between the fastest stream received and those that have arrived with the largest delay.

Example implementation of stream synchronization mechanism

To demonstrate how synchronization works in ST 2022‑7, consider a typical 6 Mbps (750 000 bytes/s) HD video stream encapsulating 7 MPEG‑TS packets into one RTP packet with a payload size of 1316bytes.

For 6 Mbps streams, the time equivalent of 101 RTP packets is about 177 ms. Our implementation has a minimum buffer size of 101 RTP packets.

How do you convert RTP packets to milliseconds, given the stream bitrate?

1. First, calculate the total data length in bits:
   V_bits = 101 [RTP packets] × 7 [TS packets] × 188 [bytes] × 8 [bits] = 1 063 328 bits.
2. Next, obtain the content duration as:
   T = 1 063 328 [bits] / 6 000 000 [bps] ≈ 0.177 s = 177 ms.

On the transmitter / sender side, the stream is duplicated to be transmitted along independent paths. "Sequence number" is incremented by 1 for each subsequent RTP packet. "Timestamp" reflects the point in time when the data was sampled. Both fields are completely identical in all the duplicate streams.

At this bitrate, about 570 RTP packets are generated each second:
(6 Mbps / 8 bits) = 750 000 bytes/s ÷ (7 × 188 bytes) ≈ 570 packets/s.

On the receiver / switcher side, packets arriving along different paths are buffered and aligned using the headers.

• "Sequence number" (16 bits). In theory, this makes it possible to compensate an inter‑path delay difference of up to ≈ 115 seconds:
  2¹⁶ ÷ 570 ≈ 115 s, where 2¹⁶ is the number of possible Sequence Number values, and 570 is the number of packets generated per second at a bitrate of 6 Mbps.
• "Timestamp" (32 bits). Enables one‑to‑one packet mapping within a time range of about 13 hours:
  2³² ÷ 90 000 ÷ 3600 ≈ 13 hours, where 2³² is the number of possible "Timestamp" values, 90 000 is the video stream sampling rate (number of ticks/samples per second), and 3600 is the number of seconds in one hour for converting the result from seconds to hours.

If the delay difference significantly exceeds 13 hours, RTP packets may be mapped incorrectly, which will cause playback artifacts on the end user device.

In practice, the buffer size does not exceed five seconds.

Legend:

1. UDP data protocol
2. RTP header
3. Sequence number
4. Timestamp
5. Seven TS packets as payload

Using "Sequence number" and "Timestamp" together enables precise matching of identical packets from different streams, allowing the receiver to instantly select the correct copy of a packet and ensure the perfect continuity of the broadcast.

This means that you can transmit two or more identical RTP‑over‑SRT or RTP‑over‑RIST streams via different providers or even different types of network links such as fiber‑optic, satellite, or mobile. The receiver combines them in real time and provides stable and reliable delivery even when one of the connections goes down entirely.

One of the key advantages of our implementation is that it utilizes monotonically increasing values ("Sequence number" and/or other counters) in the transport‑level headers. This approach does not depend on RTP specifics and can be used with any protocols and containers that have monotonically increasing counters in packet headers.

The technology has already been successfully adapted and implemented for the T2‑MI container format. The mechanism we have developed enables complete and seamless stream failover over multiple independent links (IP, ASI, and satellite). This ensures the absence of even momentary disruptions on the modulator output.

The same principle can also be applied to other modern protocols where monotonically increasing values are used. This makes ST 2022‑7 a universal technology for building fault‑tolerant systems at any scale.

If you need reliable seamless video stream failover, we are ready to discuss implementation options based on your specific requirements and integrate the solution into your infrastructure.
 

ST 2022‑7 in restreaming and transcoding: pros and cons

Pros

The use of ST 2022‑7 gives several obvious advantages compared to no‑failover transmission:

• Reliability boost: multi‑path stream redundancy protects against packet losses and network disruptions.
• Seamless switching: provides automatic stream selection without noticeable interruptions in the production.
• Increased resilience in IP networks: suitable for high‑availability broadcasting.

The greatest practical value of the ST 2022‑7 standard is demonstrated in live broadcasting. Consider a live broadcast of a soccer game. Cameras at the stadium capture HD/UHD video and audio — for example, via an SDI interface. This raw stream is then encoded (using AVC/HEVC for video and AAC for audio) and converted into IP streams.

To avoid potential disruptions, perhaps due to cable breaks or network overload, ST 2022‑7 is used. In this arrangement, the RTP stream is duplicated several times, encapsulated in RIST or SRT with RTP as the payload, and sent over two independent paths: the primary (fiber optic) and the backup (satellite with a bidirectional back‑channel).

Without using ST 2022‑7, a path failure can cause a signal interruption lasting several seconds. Losing as little as one second during a live broadcast can entail huge financial and reputational costs, especially when millions are watching. ST 2022‑7 preserves broadcast continuity and reduces the risks, especially in remote production with cloud networks.

Cons

Just like any other technology, ST 2022‑7 has its limitations:

• Increased bandwidth demand: duplicating the streams means at least doubling the traffic.
• Additional delay: the buffer size is set to compensate the inter‑stream delay.

The use of ST 2022‑7 with different transport protocols such as UDP, SRT, and RIST has certain nuances. Each option has its own benefits and downsides that should be considered in the system design. These are discussed in detail below.
 

ST 2022‑7 over RTP/UDP

Thanks to the direct use of RTP/UDP and the absence of extra transport layers, ST 2022‑7 has minimal overhead and can be easily integrated into existing networks.

The absence of error correction mechanisms such as ARQ or FEC makes this approach especially attractive where keeping the latency to the minimum is key. In controlled networks with predictable transmission quality, this makes it possible to minimize the additional latency, including the receiver buffer delay (see "Example implementation of stream synchronization mechanism" above).

Moreover, ST 2022‑7 over RTP/UDP scales well, can easily work with multicast, and consumes minimal computational resources.

There are, however, limitations. Due to the lack of built‑in error correction, the reliability is entirely determined by the physical independence and quality of the redundant streams. If the same packet gets lost in all duplicate streams at the same time, this will inevitably cause visual or audio artifacts. In fact, the chances of this happening are higher for RTP/UDP than for the more secure protocols.

In addition, the standard does not provide for encryption or authentication. The signal is transmitted in clear form and is thus vulnerable to packet interception, analysis, or spoofing. Unlike RIST and SRT, ST 2022‑7 over RTP/UDP does not adapt to network changes due to not having ARQ, FEC, dynamic overload control, or packet recovery. Therefore, this option is ill‑suited for public or unstable IP networks lacking delivery guarantees and route stability. In these scenarios, it is noticeably inferior to RIST and SRT in terms of reliability.

ST 2022‑7 over RTP/UDP is an optimum choice for the controlled internal IP networks within a single facility (e.g., a stadium), where low latency and guaranteed loss‑free delivery are required.
 

ST 2022‑7 over SRT and RIST

In some scenarios, a more effective approach is to use ST 2022‑7 together with SRT or RIST.

SRT

SRT was developed based on UDT (UDP‑based Data Transfer Protocol), a protocol tailored for media streaming. UDT is designed for high‑performance data transmission over UDP and is superior to TCP in high‑bandwidth scenarios.

SRT is primarily geared towards minimum‑latency unicast (point‑to‑point) transmission over unreliable networks. This protocol features enhanced stream management and live stream handling at a low packet loss level of 10–12 %. Its encryption (PSK) provides acceptable security for most scenarios. SRT is easy to configure and deploy even in a complex network infrastructure. It does not natively support multicast. Today, this protocol is widely adopted within the industry and supported by numerous software and hardware vendors.

RIST

RIST was created by a group of experts from Video Services Forum (VSF) and RIST Forum based on RTP/RTCP. The protocol is optimized for reliable transmission of video over unreliable networks with multicast (point‑to‑multipoint) support.

RIST is well‑adapted to low‑bandwidth links and extremely poor networks, maintaining stability at loss levels of up to 25–50 % (100–200 % with the overhead), thanks to its efficient bandwidth management. It offers advanced stream encryption mechanisms (PSK/EAP) and is fully compatible with existing RTP equipment. Despite being less common than SRT, RIST can be implemented in existing infrastructures without the need to replace the RTP/RTCP‑based devices due to its excellent compatibility with professional equipment.
 

ST 2022‑7 + SRT

The ST 2022‑7 + SRT combination is effective in scenarios where two things are important: minimal latency (normally, less than a second) and resilience in an unstable network with a low packet loss level. SRT handles the retransmission of lost packets and adapts automatically to the current network conditions, smoothing out network fluctuations without a noticeable increase in the latency.

• This combination is ideal for point‑to‑point transmission via the public Internet in remote production scenarios.
• It can also be effective for transmitting video signal over unstable networks, including mobile ones (4G/5G, Wi‑Fi), where momentary interruptions and abrupt fluctuations of the available bandwidth are possible.
• It is well‑suited for live sports broadcasts and news production, where the fastest possible delivery with ultra‑low latency is required. Automatic stream failover and live‑broadcast SRT optimization mechanisms help preserve broadcast continuity.

This combination also makes sense in ecosystems with broad support of SRT‑compatible hardware and software as well as in scenarios that prioritize ease of configuration and quick integration, including open‑source environments where SRT is already very common.
 

ST 2022‑7 + RIST

The ST 2022‑7 + RIST combination is geared towards large‑scale signal distribution in provider and corporate IP networks. It is especially effective in point‑to‑multipoint scenarios where one source serves a large number of receivers. Multicasting and the optimized exchange of control messages make it possible to reduce network load.

• This combination is well‑suited for multi‑vendor environments where open standards and cross‑vendor hardware interoperability are important. Formalized RIST profiles and the focus on interoperable solutions simplify the building of unified IP infrastructure while avoiding a single vendor lock‑in.
• This is also ideal in hybrid arrangements with unidirectional links (satellite, radio relay) and IP failover where reliable recovery of lost data is required, including scenarios with co‑utilization of satellite and IP links. RIST ensures that by using re‑requests and stream adaptation.
• ST 2022‑7 + RIST makes sense in corporate and provider infrastructures that prioritize data integrity and corporate networking compatibility, because RIST supports formalized security and authentication mechanisms.

The choice of protocol to use with ST 2022‑7 will always depend on the specific objective. Latency, reliability, security, and interoperability with the existing infrastructure remain the key factors.
 

Stream behavior: experiment and analysis

Objective

The objective was to demonstrate how seamless switching between two transport stream (TS) delivery links works in practice when using the SMPTE ST 2022‑7 technology in combination with the SRT delivery protocol. The tests were conducted in real‑world global Internet conditions, including US–CN and US–DE–CN routes as well as mobile 4G links with artificially introduced packet losses. The key measure of success was the complete recovery of the resulting UDP stream at the output with zero losses.

Test infrastructure

A broadcasting system based on the Ubuntu 22.04 operating system was deployed on the AWS cloud infrastructure (California region), including a local media server and an instance of the CodecWorks Gateway software.

The experiment involved generating and broadcasting two transport streams (TS) using the ST 2022‑7 technology. The streams were transmitted to the global Internet sequentially via a single network interface using SRT and RIST protocols while keeping the network and hardware configuration completely unchanged.

The receiving part was deployed in Beijing (China) on a local physical host running Windows 10 and another instance of CodecWorks Gateway.

TS stream reception was carried out over two independent mobile provider links. To guarantee the transmission of the TS streams over different routes, one of the links was established through a VPN tunnel in Germany. For both protocols, the stream reception and processing conditions remained fully identical. The resulting reconstructed transport stream was then sent over UDP to the localhost interface.

Network degradation

Overall, the Internet currently has good, high‑performance backbone links between the world’s data centers. If dedicated copper or fiber‑optic links with sufficient bandwidth are used, there is usually little to no packet loss.

Here, increased network load was simulated on both mobile links to create more challenging and illustrative conditions. The first link was connected to the network via Wi‑Fi, which significantly affected the packet loss ratio, while the second one was connected via an Ethernet cable to a 5G router. To amplify the effect and reduce the overall data latency, the minimum recommended delay of 120 ms was set for both protocols. This is the minimum recommended value for SRT, and the same value was used for RIST.

China has a well‑developed 5G mobile network, with practical speeds approaching 200–400 Mbps in some areas. Setting both links to 4G capped each link’s bandwidth at about 98 Mbps. When a VPN tunnel was added on the second link, the speed fell to roughly 50 % of the initial value (approximately 50 Mbps).

The duration of the experiment was about 20 minutes.
 

Results

SMPTE ST 2022‑7 + SRT

Based on the recommendations on configuring SRT connections, the lost packet recovery delay (TsbPd Delay) should be equal to 3–4 times the RTT. These recommendations are given in the SRT Protocol Technical Overview.

RTT (Round Trip Time) is the time it takes a data packet to travel from the sender to the recipient and back.

TsbPd Delay (Time‑stamped Banked Packet Delivery Delay) is a fixed buffering delay that SRT adds for stream synchronization.

SRT Line 1 statistics

Data reception statistics for SRT Line 1 is given below. This link provided data transmission between Beijing (CN) and California (USA) over the trans‑Pacific backbones (see https://www.submarinecablemap.com/).

Despite TsbPd Delay being about half the size of RTT, about 17 minutes into the experiment, the "Lost packets" and "Dropped packets" figures were approximately equal. The reason is an unstable Wi‑Fi connection. A significant portion of re‑requested packets was lost between the Wi‑Fi transmitter and receiver. Meanwhile, the "Retransmitted packets" metric confirms that some of the packets were successfully recovered as a result of re‑requests, local losses notwithstanding.

SRT Line 2 statistics

The data below represent traffic reception on the SRT Line 2 link connecting Beijing and California via Germany and the Atlantic. (https://www.submarinecablemap.com/)

Thanks to the stable connection between the 5G router and the receiving host, the "Lost packets" and "Dropped packets" figures are much lower here than for SRT Line 1. TsbPd Delay is several times lower than RTT, which points to a longer path compared to SRT Line 1 and the effect of the delay on losses in the delivery network. The "Retransmitted packets" metric again confirms partial recovery of the lost packets.

Receiver statistics

A complex delivery network led to both SRT links being unstable. It is this fact that allowed us to demonstrate in practice how seamless UDP stream reconstruction using SMPTE ST 2022‑7 works.

Below are the key JSON statistics of the reconstructed stream:

• selectedStreamID: the ID of the active buffer from which the receiver is currently transmitting data to the output: 0 (SRT Line 1) and 1 (SRT Line 2).
• outputPackets: the total number of transmitted packets on the output.
• Switches: the total number of switches between the sources.
• bufferedPackets: the number of packets in each buffer’s queue.
• losses: the number of lost (missing) packets on the receiver output.
• bufferedDuration: the amount of data accumulated in each buffer (ms).
• sequenceErrors: the number of sequence errors (missing packets) in each buffer’s input streams.
• delays: the delay of the input streams relative to the minimum‑delay stream (ms).

From the statistics, it can be seen that the inter‑stream delay (delays) is approximately 0.5 seconds. This directly affects the overall delivery latency. The sequenceErrors value suggests that the TsbPd Delay value is insufficient for the effective recovery of the input streams. As an example, TsbPd Delay could be set to 120 ms to reduce the overall data latency according to specific design requirements.

And finally, the key metric: losses = 0. This metric is the decisive one for the end users of the seamless failover technology: it confirms that the resulting TS stream was completely recovered without any losses at the output.

Elecard Boro statistics for reconstructed UDP stream

The real‑time analysis of the reconstructed UDP stream obtained using the Elecard Boro live broadcast monitoring system showed high signal quality and full signal integrity during the entire test.

The bitrate (CBR) remains stable at approximately 5.5 Mbps for almost the entire duration of monitoring and then drops sharply to 0 at the end of the test.

Delay between incoming packets: the Maximum Inter‑packet Arrival Time (IAT) is stable (~3.8–4.2 ms).

TS packet losses per second: Media Loss Rate (MLR) = 0 — losses are completely absent.

Integrity errors: no Continuity Counter Errors or Timestamp Discontinuity recorded for the entire test duration, confirming the absence of lost packets and sequence errors.

Audio: the loudness level is stable in the range [-23; -40]LUFS, confirming the absence of audio artifacts and signal dropouts.

Events: the stream stabilized quickly after the start of the monitoring task (H.264 1920x1080 25 fps video, AAC audio); at the end of the test, BadSource (No signal) was detected after the end of the transmission. There were no other events recorded in the Task Events log.

Summary of results
The ST 2022-7 + SRT technology provided perfect seamless recovery of the resulting UDP stream without a single lost packet or СС error at the output, despite the challenging conditions on the unstable source links.

Conclusion

Implementing the ST 2022-7 standard into restreaming and transcoding processes provides tangible benefits in terms of reliability and quality of media content delivery.

This technology makes it possible to preserve broadcast continuity even in challenging network conditions, minimize the risk of losses, and ensure the stable operation of media services. Given the growing demands for service quality and content availability, this is becoming not just an advantage but a key component of modern broadcasting infrastructure.

Article by Vitalii Bauman, Technical Support Engineer at Elecard