The MPEG Transport Stream standard is nearly 30 years old, yet it remains the foundation of DVB broadcasting and IPTV—and is still frequently used in OTT workflows. Let’s take a closer look at why it exists, which parameters need to be monitored, and what typical TS workflows look like in practice.
What Is MPEG-TS and Why Is Multiplexing Needed?
When you watch a TV program, it may seem like only video is being transmitted over the network. In reality, it’s a combination of multiple data components:
- Video
- Audio (one or more tracks)
- Subtitles
- Teletext
- Service data for synchronization
- Ad insertion markers (SCTE-35), used by splicers for content replacement
All of this must be packaged in a way that ensures audio stays in sync with video, subtitles appear at the right time, and the receiver understands how the components relate to each other. This is exactly what the MPEG Transport Stream standard defines—a media container format that encapsulates all these elementary streams.
Multiplexing is a complex process that requires high precision and careful handling of multiple parameters. This is especially critical in real-time broadcasting, where the stream is processed and transmitted simultaneously.
Evaluating Quality: The ETSI TR 101 290 Standard
To assess how correctly a multiplexer is operating, the ETSI TR 101 290 standard defines a set of parameters to monitor and classifies errors by priority.
The most critical are Priority 1 errors. Two illustrative examples:
Continuity_count error — The continuity counter of TS packets is broken. This indicates that one or more packets were lost during transmission. On screen, this may appear as pixelation, image breakup, or visible artifacts.
PID error — An elementary stream declared in the PMT table is missing. For example, subtitles are listed in the PMT, but no corresponding data is actually transmitted. The receiver expects the stream, but it never arrives.
It’s important to understand that the real-world impact of these errors depends heavily on what happens to the stream next. DVB broadcasting via a modulator is the most demanding scenario. Segmenting into chunks for HLS delivery is far more tolerant.
DVB: The Most Demanding Scenario
If the output stream is sent to a DVB modulator, multiplexing requirements are extremely strict. Modulators are sensitive to:
PCR (Program Clock Reference) accuracy
PCR repetition intervals
CBR (Constant Bitrate) stability
IAT (Inter-Arrival Time) — packet spacing intervals
The presence and correctness of all service tables
Incorrect PCR placement may lead to synchronization issues at the receiver side. By contrast, if the stream is later segmented into HLS for OTT delivery, PCR precision is largely irrelevant. Therefore, multiplexing requirements vary significantly depending on the final use case.
Typical Multiplexer Workflows
Let’s look at several common scenarios.
Transcoding an SPTS
Probably the most common case. What happens:
An SPTS (e.g., UDP multicast) arrives at the input.
The stream is demultiplexed into its elementary components:
- Video
- Audio
- Teletext
- SCTE-35
Video and audio are transcoded (for example, MPEG-2 → AVC, MPEG → AAC). Teletext and SCTE-35 markers are passed through unchanged, or optionally removed from the output.
The streams are reassembled by the multiplexer.
The result is sent to the network, potentially using a different protocol such as RTP, SRT, or RIST.
SRT-to-UDP Restreaming with Remultiplexing
A common requirement is to receive a stream via SRT and redistribute it via UDP multicast. In theory, the stream could simply be forwarded unchanged. In practice, however, issues often arise:
PCR errors
Irregular packet timing
Analyzer warnings
Remultiplexing helps resolve these problems by:
Correcting PCR
Adding padding
Smoothing bitrate
This results in a cleaner, more standards-compliant stream before further distribution.
Splitting MPTS into SPTS (Demultiplexing)
The reverse scenario: the input is a multi-program transport stream (MPTS) containing several channels, and the output consists of separate single-program streams (SPTS), each carrying one channel.
For example, receiving one UDP multicast stream with 10 programs and redistributing them as 10 independent streams.
Statistical Multiplexing
This is a relatively new feature that has seen increasing demand in recent years.
Imagine you have 50 Mbps of bandwidth and 10 channels. If you divide the bandwidth evenly, each channel gets 5 Mbps (CBR). But this is inefficient: a news channel with mostly static content consumes the same bitrate as a fast-paced action channel.
Statistical multiplexing (statmux) solves this problem by dynamically redistributing bitrate among channels based on scene complexity. Each encoder evaluates the complexity of its current content and sends this information to a central analyzer. The analyzer collects data from all encoders and provides bitrate recommendations to each one, based on total available bandwidth and current demand.
The result: the same 10 channels within the same bandwidth, but with significantly improved overall quality.
Multiplexing is the foundation upon which everything else in television broadcasting is built. Once you understand it, it becomes much easier to move on to the next steps: scrambling, statistical multiplexing, and choosing the right hardware. We’ll cover those topics in the upcoming articles.
Top comments (0)