Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
IEC 13818‑9‑01: Real‑Time Interface for MPEG‑2 Systems Decoders – Technical Overview
Understanding the implementation of the MPEG‑2 Real‑Time Interface (RTI) as specified in CAN/CSA‑ISO/IEC 13818‑9‑01
Scope and Objectives
The international standard ISO/IEC 13818‑9:1996, adopted in Canada as CAN/CSA‑ISO/IEC 13818‑9‑01 (often referred to as IEC 13818‑9‑01), defines the Real‑Time Interface (RTI) for MPEG‑2 systems decoders. The RTI establishes a standardised electrical and protocol interface between a transport stream (TS) demultiplexer and an MPEG‑2 video/audio decoder, ensuring deterministic delivery of compressed data with precise synchronisation. The standard primarily targets digital television receivers, set‑top boxes, and professional decoding equipment that rely on MPEG‑2 Systems (ISO/IEC 13818‑1).
The objective of IEC 13818‑9‑01 is to guarantee interoperability between components from different manufacturers, while maintaining the real‑time constraints needed for seamless decoding and presentation. The specification covers signal definitions, timing parameters, data framing, and error handling mechanisms required to prevent buffer underflow or overflow in the decoder’s system target decoder (STD) model.
Tip: When designing an RTI interface, ensure that strobe-to-data setup and hold times adhere strictly to the minimum values specified in Tables 1 and 2 of the standard to avoid data corruption and synchronisation loss.
Technical Requirements
RTI Bus Architecture and Signals
The RTI defines a parallel bus consisting of 8 data lines (DATA[7:0]), a strobe signal (STRB), a valid signal (VLD), and a synchronisation flag (SYNC). The demultiplexer drives the bus, and the decoder acts as the receiver. Data words are transferred on each rising edge of the strobe when VLD is asserted. The SYNC signal marks the beginning of a Packetised Elementary Stream (PES) header or a System Clock Reference (SCR) packet, enabling the decoder to align its clock and buffer state.
Key timing parameters are defined to meet the MPEG‑2 Systems decoding latency requirements. The table below summarises the most critical signal characteristics.
| Signal | Direction | Description | Timing Constraint |
|---|---|---|---|
DATA[7:0] | Input to decoder | Byte‑wide compressed data | Setup/hold relative to STRB ≥ 5 ns |
STRB | Input | Strobe clock (pulse on valid data) | Min period 40 ns (25 Mbytes/s max) |
VLD | Input | Data valid indicator | Asserted before STRB ≥ 10 ns |
SYNC | Input | Start of PES/SCR packet | Asserted with first byte of packet; hold ≥ 2 cycles |
Data Protocol and Synchronisation
The RTI requires that byte‑aligned data be sent in strict sequence according to the STD model. The demultiplexer must not overflow the decoder’s internal input buffer (typically 4 KB). The standard mandates a back‑pressure mechanism via a BUSY signal (optional), which the decoder asserts when its input buffer is nearly full. Additionally, the SYNC signal is used to convey start‑code timing and to reset the decoder’s packet parser. All timestamps (PTS, DTS) embedded in the bitstream are translated into the RTI data stream without modification; the decoder extracts them from the elementary stream for presentation synchronisation.
Warning: Incorrect RTI implementation can cause audio/video desynchronisation or decoder stall. Pay careful attention to the propagation delay matching between data and strobe signals, especially in high‑speed backplanes.
Implementation Highlights
Integrating RTI in Set‑Top Box Designs
Modern systems‑on‑chip (SoCs) for digital TV often embed both a transport demultiplexer and an MPEG‑2 decoder on the same die. However, for modular designs (e.g., conditional access modules or external decoders), the RTI remains a common off‑chip interface. Implementation typically requires a dedicated 8‑bit bus running at up to 25 MHz, with careful PCB layout to minimise skew. The standard allows for either 3.3 V or 5 V logic, provided setup/hold times are satisfied.
A typical RTI transmitter (demux) must:
- Parse the incoming transport stream and extract the desired elementary stream.
- Assemble PES packets and remove the transport layer.
- Generate
SYNCpulses at the start of each PES packet. - Calculate and manage PCR (Program Clock Reference) delivery if required.
- Implement flow control using the optional
BUSYsignal to prevent buffer overflow.
The receiver (decoder) uses the SYNC signal to initialise its PES parser each time a new audio or video frame begins. Internal state machines handle start‑code detection and decode the timestamps for audio‑video synchronisation.
Success: Adhering to IEC 13818‑9‑01 ensures interoperability between different vendors’ transport stream demultiplexers and MPEG‑2 decoders, reducing integration risk and shortening time‑to‑market for digital television products.
Compliance and Testing
Compliance with IEC 13818‑9‑01 is verified through a combination of electrical conformance tests and functional stream‑driven validation. Recognised test laboratories (e.g., Digital TV Group, DVB Project Office) offer certification programmes that include the RTI interface. The standard defines a reference decoder model against which candidate implementations are compared. Test bitstreams with known timing constraints (e.g., buffer fullness boundary conditions) are used to stress the interface.
Key compliance checks include:
- Electrical timing compliance (setup/hold, pulse widths, signal rise/fall times).
- Data integrity under worst‑case bus loading.
- Correct generation and recognition of
SYNCpulses. - Robustness against missing or late data (handling of discontinuities).
- Buffer overflow prevention under maximum bitrate conditions (80 Mbit/s).
Manufacturers often include an internal self‑test mode that loops back the RTI transmitter to the receiver to validate the complete data path before compliance submission.
Danger: Non‑compliance with the RTI timing requirements may result in buffer violations, decoder crashes, and failure of certification testing. Always characterise the bus across worst‑case process, voltage, and temperature conditions.
Frequently Asked Questions
Q: What is the primary function of the Real‑Time Interface (RTI) defined in IEC 13818‑9‑01?
A: The RTI provides a standardised parallel bus that delivers compressed MPEG‑2 elementary stream data from a transport demultiplexer to a decoder while maintaining strict timing alignment with the MPEG‑2 Systems clock. Its primary role is to guarantee that the decoder receives the data in real time, with synchronisation markers, so that audio‑video presentation can proceed without buffer underflow or overflow.
A: The RTI provides a standardised parallel bus that delivers compressed MPEG‑2 elementary stream data from a transport demultiplexer to a decoder while maintaining strict timing alignment with the MPEG‑2 Systems clock. Its primary role is to guarantee that the decoder receives the data in real time, with synchronisation markers, so that audio‑video presentation can proceed without buffer underflow or overflow.
Q: How does the RTI relate to the broader MPEG‑2 Systems standard (ISO/IEC 13818‑1)?
A: ISO/IEC 13818‑1 defines the packetised transport stream and program stream, as well as the system target decoder (STD) model. Part 9 (IEC 13818‑9‑01) extends this by specifying a concrete hardware interface that realises the STD model. The RTI allows the separation of the demultiplexing and decoding stages while preserving the deterministic timing assumptions of the STD.
A: ISO/IEC 13818‑1 defines the packetised transport stream and program stream, as well as the system target decoder (STD) model. Part 9 (IEC 13818‑9‑01) extends this by specifying a concrete hardware interface that realises the STD model. The RTI allows the separation of the demultiplexing and decoding stages while preserving the deterministic timing assumptions of the STD.
Q: Is the RTI still relevant for modern video codecs like H.264 or HEVC?
A: While many modern SoCs integrate all decoding functions on a single chip, the RTI remains in use for legacy broadcast equipment and for modular conditional‑access systems. Newer codecs typically use simpler packetised interfaces (e.g., transport stream over PCIe or USB), but the timing concepts of the RTI continue to inform real‑time interface design in digital video systems.
A: While many modern SoCs integrate all decoding functions on a single chip, the RTI remains in use for legacy broadcast equipment and for modular conditional‑access systems. Newer codecs typically use simpler packetised interfaces (e.g., transport stream over PCIe or USB), but the timing concepts of the RTI continue to inform real‑time interface design in digital video systems.
Q: What are the most common pitfalls when designing an RTI interface?
A: The most frequent issues include: (1) exceeding the maximum allowed strobe period (causes data starvation), (2) failing to meet data setup/hold times at the decoder (leads to bit errors), (3) incorrect handling of the SYNC signal during sequence boundaries (disrupts PES parsing), and (4) omitting the BUSY flow‑control signal, which can cause buffer overflows during peak bitrate.
A: The most frequent issues include: (1) exceeding the maximum allowed strobe period (causes data starvation), (2) failing to meet data setup/hold times at the decoder (leads to bit errors), (3) incorrect handling of the SYNC signal during sequence boundaries (disrupts PES parsing), and (4) omitting the BUSY flow‑control signal, which can cause buffer overflows during peak bitrate.