The fixed-size packets, simple timing model, and built-in error detection allow receivers to join a stream at any point and keep playing despite errors, rather than failing outright. In short, it prioritizes deterministic behavior and graceful degradation over efficiency or elegance, which is exactly what live and real-time broadcast requires.

In other words, MPEG TS continues to be prevalent in the broadcast industry as it optimizes for failure behavior, not peak efficiency.

No Reverse Path

MPEG-TS was designed for one-way delivery. Much like SDI, there is no reverse path to signal retransmission of lost data. If a packet is lost, then it is lost forever. At its core, MPEG-TS is a continuous sequence of fixed-size packets, either 188- or 204-bytes long.

The 204-byte version takes the 188-byte packet and adds Reed-Solomon coding to allow for error detection. The first byte of the packet is the sync-byte and acts as an anchor to allow the receiver to sync up to the start of packet boundaries. It is assumed that in the transport stream, although the sync-byte is value 0x47, it will only occur regularly at the start of packet boundary, thus providing a convenient place for the receiver to synchronize to. It means a decoder scanning a noisy stream can reliably re-establish packet boundaries without needing any prior context.

The MPEG-TS is immediately distinguished from file formats and most streaming containers. It was not designed to represent media efficiently or elegantly, but to keep decoders running under hostile conditions without having to send control information back to the transmitter. In other words, MPEG-TS does not attempt to manage delivery, reliability, or congestion control. It assumes packets may be lost and designs the media layer accordingly.  IP, particularly over UDP, makes no guarantees about delivery or ordering.

Byte Boundaries

The 188-byte boundary of the sync-byte, known as the packet identifier (PID) forms the header of the packet which includes continuity counters that increment on each packet, thus allowing the detector to determine if a packet has been lost, and how the packets should be assembled for the higher level video, audio, and metadata. As the packets are fixed in size, there is no ambiguity regarding variable-length structures that might be broken by a single missing byte.

This same 188-byte structure fits comfortably inside the payload of an IP packet. When carried over IP, multiple MPEG-TS packets are grouped into a single UDP datagram. This fits within the Ethernet MTU limits and avoids IP fragmentation, thus reducing unpredictable failure behavior. If a UPD packet is lost, the receiver can resynchronize to the stream and continue where it left off. There is no ambiguity about framing or alignment, and recovery occurs within a few packets.

SMPTE’s ST 2022 has deliberately standardized how MPEG-TS is transported over IP/UDP datagrams, thus preserving the existing broadcast workflows but at the same time moving the transport layer to IP/Ethernet. Furthermore, ST 2022-1 and ST 2022-2 define how forward error correction is employed in the stream, thus providing detection and some correction of errors in the packets. The IP packet encapsulation method maintains the MPEG-TS structure and timing, thus allowing broadcasters to adopt IP networks without having to employ new timing planes such as PTP (as required for ST 2110).

Multicast Routing

Broadcast infrastructures traditionally use distribution amplifiers to replicate video and audio to multiple devices, such as monitors, production switchers and sound consoles. IP networks further develop this idea using multicast routing.

MPEG-TS works well with UDP/IP multicast as it has no session-level dependency. In computing terms we would call this stateless operation. MPEG-TS/UDP/IP fits well with multicasting allowing downstream devices to join and leave the streams as required. As the timing plane is built into the MPEG-TS through the PCR, no external timing plane is needed as the clock references are built directly into the standard. This also simplifies signal recovery after a path switch or any outage caused in the network links.

There is no handshake, no control plane, and no requirement to receive a “start of stream” preamble in MPEG-TS, thus allowing it to recover quickly from any disturbance, which again lends itself well to IP networks, even for distribution where dual streaming is employed with ST 2022-7.

Full Transparency

The MPEG-TS – ST 2022 – IP stack is transparent to failure. If an IP packet drops then ST 2022 exposes the state of the transport layer, and MPEG-TS exposes any video, audio, or metadata loss through the continuity counters. All three layers can be individually tested and monitored and there is no hidden silent fixing by buffering. Engineers can see any issues at any of the layers, measure them, and diagnose them. The whole stack operates through published standards and protocols thus removing the “black box” syndrome from the infrastructure.

Carrying MPEG-TS over ST 2022 continues to coexist with ST 2110. Although both employ IP at a transport level, the two standards are optimized for different operational requirements.

MPEG-TS with ST 2022 addresses the problem of moving video, audio, and metadata across networks that are not fully under the broadcaster’s control. The specifications assume the IP network will be subject to packet loss, jitter, and that routing will change with little notice, thus relying on MPEG-TS’s packet-based structure, continuity counters and embedded timing to keep decoders synchronized, resulting in minimal disturbance to the sound and vision. Although IP packet losses manifest themselves as video and audio disturbance, the errors are localized to a single service allowing the output to continue rather than fail catastrophically. This makes MPEG-TS / ST 2022 well suited to contribution and distribution over WANs, telco links, and shared infrastructure.

Contrast With ST 2110

By contrast, ST 2110 is designed for production inside tightly engineered facilities. It transports separate video, audio, and metadata with precise timing alignment using the PTP IEEE 1588 v2 timing plane. This enables flexible routing, clean switching, and format agnostic workflows, but it also assumes a lossless, low-jitter network where timing stability is guaranteed. If any of those assumptions cannot be delivered, failures quickly propagate across multiple services with catastrophic consequences.

The coexistence of these standards reflects a deliberate architectural demarcation. ST 2110 optimizes for precision and high flexibility where the network can be engineered to behave deterministically. Whereas MPEG-TS over ST 2022 optimizes for resilience and predictable failure where a truly deterministic network is not achievable. In practice, many broadcasters employ both systems simultaneously: ST 2110 within the studio and production facility, and MPEG-TS/ST 2110 at the edges where external connectivity is required.

MPEG-TS employs its own PCR on a per service basis, that is for the same video, audio, and metadata. This makes it difficult to switch seamlessly between different video and audio sources as they may well have differing time-bases and to achieve seamless switching sample rate conversion would be required which would result in a much more complicated system. As ST 2110 uses a common PTP clock reference for all the video, audio and metadata sources within a facility, seamlessly switching between them is much easier and reliable.

One of the key strengths of MPEG-TS is that its design never assumes a reliable transport. By treating packet loss as inevitable and combining this assumption with fixed-size packetization, MPEG-TS integrates naturally with IP networks, where delivery is best-effort and loss is expected rather than exceptional.