RTP Payload Format for MPEG1/MPEG2 Video
obsoleted by
- rfc-2250 — RTP Payload Format for MPEG1/MPEG2 Video
Extracted elements (25)
For MPEG System/Transport Streams, the RTP timestamp is derived from the sender's 90 kHz clock synchronized to PCR/SCR and represents the target transmission time of the first byte—it is NOT passed to the MPEG decoder. Its purpose is estimating and reducing network-induced jitter and synchronizing relative time drift, which differs from the typical RTP presentation timestamp semantics.
MPEG Audio frames have variable size: for Layer-II at 44.1 kHz and 384 kbits/sec, average frame size is 1.25 KB. If packets are 500 bytes, each audio frame straddles 3 RTP packets. The Frag_offset field was added specifically to handle this fragmentation without requiring the receiver to scan for frame boundaries.
MPEG slices are used as the unit of recovery from data loss or corruption: an MPEG-compliant decoder advances to the beginning of the next slice on error. The B (Beginning-of-slice) and E (End-of-slice) bits in the encapsulation header are provided specifically to facilitate this slice-based recovery.
On initial decode of an RTP-encapsulated MPEG Elementary Stream, a receiver may discard all packets until the S (Sequence-header-present) bit is set to 1, at which point sufficient state is available for the MPEG decoder. After any packet loss (gap in RTP sequence number), the receiver may discard packets until the B (Beginning-of-slice) bit is set, ensuring the decoder can resynchronize at a slice boundary.
The packetizer should periodically inject the Video_Sequence_Header into the network stream (preceded by end-of-stream indicator) to allow channel switching and arbitrary join points for decoding a continuously relayed MPEG bit-stream, even when the source file contains the header only at the start.
Two distinct payload formats are defined: one for MPEG System/Transport/Program Streams (Section 2) to maximize interoperability with MPEG System environments including TIU/RIU end-systems, and one for MPEG Elementary Streams (Section 3) to maximize compatibility with the Internet architecture and other RTP-encapsulated media. The choice avoids forcing MPEG System overhead on pure internet end-systems.
A distinct RTP payload type is assigned to MPEG1/MPEG2 Video and MPEG1/MPEG2 Audio respectively. No further indication of MPEG1 vs MPEG2 needs to be carried in the RTP or MPEG-specific headers, as this distinction is available in the ES headers themselves (e.g., sequence_extension() presence for video).
MPEG1 Video is distinguished from MPEG2 Video at the video sequence header: MPEG2 Video has sequence_header() followed by sequence_extension(). The MPEG2 profile and level are determined by the profile_and_level_indicator field of sequence_extension(). MPEG1 Audio is distinguished from MPEG2 Audio via the ancillary_data() header.
The specification targets four end-system types: Transmitting Interworking Unit (TIU), Receiving Interworking Unit (RIU), Transmitting Internet End-System (TAES), and Receiving Internet End-System (RAES). Each transmitter type must interoperate with each receiver type, driving the need for two payload format profiles.
A minimum RTP payload size of 261 bytes MUST be supported to contain the largest single MPEG ES header (the extension_data() header containing quant_matrix_extension()). Each ES header must be completely contained within a single packet.
For MPEG Elementary Streams, Presentation Time Stamps of 32 bits at 90 kHz accuracy SHALL be carried in the fixed RTP header. All packets that make up an audio or video frame shall have the same timestamp.
For MPEG2 Transport Streams, the RTP payload MUST contain an integral number of MPEG transport packets (188 bytes each). The number of transport packets is computed by dividing RTP payload length by 188. Multiple small MTS packets should be aggregated into a single RTP packet to avoid end-system inefficiencies.
The beginning of an MPEG slice must either be the first data in a packet (after any MPEG ES headers) or must follow after an integral number of slices. This ensures the next slice boundary can be found after a packet loss without requiring the receiver to scan packet contents.
Three fragmentation rules for MPEG Video ES: (1) Video_Sequence_Header, when present, will always be at the beginning of an RTP payload; (2) GOP_header, when present, will always be at the beginning or follow a Video_Sequence_Header; (3) Picture_Header, when present, will always be at the beginning or follow a GOP_header.
When multiple audio frames are encapsulated in one RTP packet, an integral number of audio frames MUST be contained and the Frag_offset header SHALL be set to 0. The audio fragmentation indicator header (Section 3.5) SHALL be present for all MPEG1/2 Audio payload types.
FBV (full_pel_backward_vector), BFC (backward_f_code), FFV (full_pel_forward_vector), and FFC (forward_f_code) are copied from the most recent picture header into the RTP video-specific header. These values enable Picture_Header reconstruction after packet loss by providing the necessary motion vector context at each packet.
For MPEG ES video, the RTP M bit is set to 1 on the packet containing the MPEG frame end code (0 otherwise). For audio, the M bit is set to 1 on the first packet of a talk-spurt (0 otherwise). The RTP timestamp for video represents the presentation time and may not be monotonically increasing when B pictures are present.
The M bit in RTP packets carrying MPEG System/Transport/Program Streams is set to 1 whenever the timestamp is discontinuous (e.g., when a sender switches data sources), allowing receivers and any intervening RTP mixers or translators to ignore the timestamp discontinuity in their clock phase detectors.
The P field (3 bits, Picture-Type) encodes the MPEG picture type: I=1, P=2, B=3, D=4; value 000b is forbidden and 101b–111b are reserved. FBV, BFC (backward motion vector fields) are zero for I and P frames; FFV, FFC (forward motion vector fields) are zero for I frames only. All four fields are constant per picture across all RTP packets.
The S bit (Sequence-header-present) is normally 0 and set to 1 at each occurrence of an MPEG sequence header in the payload. This allows receivers to detect the presence of the sequence header in an RTP packet without scanning the payload, enabling fast synchronization on stream join.
The TR (Temporal-Reference) field is 10 bits and carries the temporal reference of the current picture within the current GOP, ranging 0–1023. It is constant across all RTP packets of a given picture and is used by receivers to detect lost GOP headers and Picture headers.
RFC 2038 contains no explicit Security Considerations section, which was common for 1996-era Standards Track RFCs. The format carries no authentication or integrity protection; implementations should rely on underlying transport-layer or application-layer security mechanisms when integrity or authenticity of MPEG streams is required.
Error recovery for lost GOP/Picture headers uses two counters: ref_pic_temp (for I/P frames) and dep_pic_temp (for B frames), both initialized at each GOP start and incremented by one per picture. A mismatch between the counter value and the TR field in an arriving RTP packet indicates a lost header. A lost GOP header can be reconstructed with null time_code, repeated closed_gop flag, and broken_link=1; a lost Picture header is reconstructed from P, TR, FBV, BFC, FFV, FFC in the next Beginning-of-slice packet.
MPEG Audio-specific header: 32-bit field at start of payload after any RTP headers for MPEG1/2 Audio payload type. Fields: MBZ (16 bits, must be zero), Frag_offset (16 bits, byte offset into the audio frame for the data in this packet; 0 when packet contains complete frame(s)).
MPEG Video-specific header: 32-bit field appended after the RTP fixed header on every video packet. Fields: MBZ (6 bits), TR/Temporal-Reference (10 bits, 0–1023, constant per picture), MBZ (2 bits), S/Sequence-header-present (1 bit), B/Beginning-of-slice (1 bit), E/End-of-slice (1 bit), P/Picture-Type (3 bits: I=1,P=2,B=3,D=4), FBV (1 bit), BFC (3 bits), FFV (1 bit), FFC (3 bits).