MPEG-TS, the MPEG transport stream, is a container format that multiplexes video, audio and data into fixed 188-byte packets designed for transmission over channels that may lose or corrupt data. It is defined in the MPEG-2 Systems standard, ISO/IEC 13818-1, and remains the backbone of digital television and much live video delivery.
Among containers and formats, MPEG-TS differs from file-oriented containers such as MP4 and MOV because it has no global index or header. A receiver can join the stream at almost any point and begin decoding after it finds the next set of program tables and a keyframe.
How the MPEG-TS packet structure works
Every transport stream packet is exactly 188 bytes long and starts with the sync byte 0x47, which lets a receiver lock onto packet boundaries in a continuous bit stream. The sync byte is the first of four header bytes, which carry the fields that route and protect the payload.
| Field | Size | Purpose |
|---|---|---|
| Sync byte | 8 bits | Marks the packet start, always 0x47 |
| Transport error indicator | 1 bit | Flags a packet known to be corrupted |
| Payload unit start indicator | 1 bit | Signals that a new PES packet or table begins |
| Packet identifier (PID) | 13 bits | Identifies which elementary stream or table the packet belongs to |
| Adaptation field control | 2 bits | Indicates payload, adaptation field or both |
| Continuity counter | 4 bits | Increments per PID to reveal lost packets |
The optional adaptation field carries timing and signaling information, most importantly the program clock reference (PCR), and stuffing bytes that pad packets when a payload does not fill them. Compressed audio and video are first wrapped in PES packets with presentation and decoding timestamps, and those PES packets are then sliced across many transport packets.
Program tables and timing
A transport stream describes its own contents through program-specific information (PSI) tables that repeat at regular intervals. The program association table always travels on PID 0 and lists the programs in the stream, and each program map table then lists the PIDs and codec types of that program’s video, audio and data streams.
Timing relies on a 27 MHz system clock. The PCR samples this clock so the receiver can reconstruct it, and the standard requires a PCR at least every 100 ms, while broadcast practice often specifies 40 ms. Presentation and decoding timestamps run at 90 kHz with 33 bits, so they wrap around after roughly 26.5 hours, a detail that long-running live systems must handle correctly.
Because one stream can hold several programs, MPEG-TS distinguishes a single program transport stream from a multiple program transport stream. Broadcasters use the latter to carry several television channels in one modulated carrier, together with service information tables defined by systems such as DVB and ATSC.
MPEG-TS compared with other containers
MPEG-TS trades storage efficiency for robustness and joinability. File containers optimize for random access and editing, while transport streams optimize for continuous delivery where loss is expected.
| Container | Structure | Error resilience | Typical use |
|---|---|---|---|
| MPEG-TS | Fixed 188-byte packets, repeated tables | High | Broadcast, IPTV, contribution, HLS |
| M2TS | 192-byte packets with timestamp prefix | High | Blu-ray and AVCHD recordings |
| MPEG program stream | Variable packs for reliable media | Low | DVD video |
| MP4 and MOV | Indexed boxes or atoms | Low before finalization | Files, progressive download, editing |
| MKV | Flexible elements with cues | Moderate | Archiving and playback files |
The fixed packet size costs bandwidth. The 4-byte header alone is about 2 percent overhead, and repeated tables, PES headers and null stuffing packets in constant-bitrate streams add more. Muxing into MPEG-TS is therefore a deliberate choice for transport, not for compact storage.
Where MPEG-TS is used in practice
MPEG-TS appears wherever video must travel continuously and reliably over imperfect links. The table below summarizes the main applications and the reason each relies on the format.
| Application | How MPEG-TS is carried | Why it fits |
|---|---|---|
| Terrestrial, cable and satellite TV | Modulated broadcast multiplex | Several channels with service tables and error tolerance |
| IPTV and contribution feeds | UDP or RTP, usually seven packets per datagram | 1,316-byte payloads fit a standard network frame |
| HLS streaming | Segments of a few seconds each | Each segment starts decodable for adaptive switching |
| SRT and similar protocols | Transport stream over reliable UDP | Low latency contribution over the internet |
| Camera and recorder files | M2TS variant | Robust recording that survives interruption |
Newer streaming workflows increasingly use fragmented MP4 instead of transport stream segments, because it reduces overhead and works with common encryption across HLS and DASH. MPEG-TS nevertheless remains dominant in broadcast and contribution chains.
Common problems and pitfalls
Most transport stream faults are diagnosed with stream analyzers that check timing, tables and counters against broadcast measurement guidelines such as ETSI TR 101 290.
- Continuity counter errors, which indicate packet loss or a faulty multiplexer.
- PCR jitter or excessive intervals, which cause audio drift, stutter or decoder buffer problems.
- Missing or infrequent PAT and PMT, which slow channel changes and stream joins.
- Segments that do not start with a keyframe in HLS, which break clean bitrate switching.
- Timestamp wraparound bugs in long live sessions, which can freeze players after many hours.
- Storing archives in MPEG-TS, which wastes space and complicates seeking compared with MP4 or MKV.
Understanding it simply
MPEG-TS is a way of packing video and sound into many small, equal-sized parcels so they can be sent like a steady stream of envelopes. Each envelope is labeled with which program and which track it belongs to.
If a few envelopes get lost on the way, the receiver simply notices the gap and keeps going. A television can also tune in halfway through, because the stream regularly repeats its table of contents. The key idea is reliability during transmission, not saving space on a disk.
Applied in practice
A regional broadcaster sends its live news program from a stadium to the central studio over the internet. The encoder at the venue produces H.264 video and AAC audio and multiplexes them into a single program transport stream at a constant 8 Mbit/s.
The stream travels over SRT, with seven transport packets per datagram and PCR inserted every 40 ms. In the studio, a stream analyzer monitors continuity counters and PCR accuracy while the playout system decodes the feed for air.
During a brief network dropout, the analyzer logs a handful of continuity errors, SRT retransmits most of the lost data and the decoder conceals the rest. The live program continues without a visible interruption, which is exactly the resilience the transport stream design provides.