RTP Payload Format for MPEG1/MPEG2 Video
obsoletes
- rfc-2038 — RTP Payload Format for MPEG1/MPEG2 Video
Extracted elements (27)
Although the MPEG standard does not require periodic repetition of the Video_Sequence_Header, implementations are encouraged to inject it periodically to enable channel switching and arbitrary-point entry into a continuously relayed stream. When playing from a file where the header appears only once, the packetizer should save and periodically re-inject it.
The RTP timestamp for MPEG System streams deliberately does not represent media presentation time; instead it tracks target transmission time. This non-standard use of the RTP timestamp is justified by the need to reduce network-induced jitter and synchronize clock drift between transmitter and receiver in MPEG System environments.
Two distinct payload formats are defined: Section 2 encapsulates MPEG System/Transport/Program streams to maximize interoperability with native MPEG System environments (TIU/RIU), while Section 3 encapsulates Elementary Streams directly in RTP to maximize compatibility with Internet architecture and other RTP media streams (TAES/RAES).
This document obsoletes RFC 2038. The revision extends the packet loss resilience mechanisms in Section 3.4 to include additional picture header information required for MPEG-2, and adds a new Security Considerations section.
Each MPEG ES header must be completely contained within a single RTP packet. Consequently, a minimum RTP payload size of 261 bytes must be supported to accommodate the largest single ES header (extension_data() containing quant_matrix_extension()).
MPEG video fragmentation rules require that the Video_Sequence_Header always appear at the beginning of an RTP payload, a GOP_header always appears at the beginning or immediately after a Video_Sequence_Header, and a Picture_Header always appears at the beginning or immediately after a GOP_header.
Distinct RTP payload types are assigned for MPEG-1 System Streams, MPEG-2 Program Streams, and MPEG-2 Transport Streams in the MPEG System encapsulation (Section 2), and separately for MPEG-1/2 video Elementary Streams and MPEG-1/2 audio Elementary Streams in the ES encapsulation (Section 3).
Error recovery strategy: on initial decode, a receiver may discard all packets until the S (Sequence-header-present) bit is set to 1, at which point sufficient state for MPEG decoding is present. After any packet loss (detected by RTP sequence number gap), the receiver may discard packets until the B (Beginning-of-slice) bit is set.
For Elementary Stream encapsulation, 32-bit 90 KHz Presentation Time Stamps (PTS) are carried in the fixed RTP header. All RTP packets making up a single audio or video frame carry the same timestamp. For video streams with B pictures, the timestamp may not be monotonically increasing.
For MPEG-1 payloads, a lost Picture_Header is reconstructed from the P, TR, FBV, BFC, FFV, and FFC fields present in the next received packet plus stream-dependent defaults. For MPEG-2, the T-bit MPEG-2 header extension supplies the additional parameters required.
For MPEG-2 Transport Streams, the RTP payload MUST contain an integral number of 188-byte MTS packets. Multiple small MTS packets are aggregated into a single RTP packet; the count is computed by dividing the RTP payload length by 188.
For MPEG System/Transport stream encapsulation, each RTP packet carries a 90 KHz timestamp synchronized to the MPEG PCR or SCR, representing the target transmission time of the first byte of the payload. This timestamp is not passed to the MPEG decoder and is used solely to estimate network jitter and synchronize transmitter/receiver clock drift.
GOP and Picture_Header loss is detected by comparing the TR field against receiver-maintained ref_pic_temp and dep_pic_temp counters. A mismatch signals a lost header; a null GOP header can be reconstructed using a null time_code, the previous closed_gop flag, and broken_link=1.
MPEG slices are the unit of error recovery. The beginning of a slice must be either the first data in a packet (after any ES headers) or must follow an integral number of complete slices, ensuring that the next slice boundary after a packet loss can be located without scanning packet contents.
Multiple MPEG audio frames may be encapsulated in one RTP packet, but only as an integral number of complete frames; in this case the Frag_offset in the audio fragmentation header is set to 0. If a single audio frame is too large for one RTP packet, it may be fragmented across multiple packets using the Frag_offset field.
RTP M bit usage for Elementary Streams: for video, set to 1 on the packet containing the MPEG frame end code; for audio, set to 1 on the first packet of a talk-spurt.
RTP M bit usage for MPEG System streams: set to 1 whenever the timestamp is discontinuous (e.g., when a sender switches data sources), enabling receivers and RTP mixers to ignore the timestamp discontinuity in clock phase detectors.
The AN and N bits support MPEG-2 error resilience: AN=1 activates the N bit; N=1 signals that picture header parameters changed and cannot be reconstructed from a previously transmitted header of the same picture type. N must be constant across all packets of a given picture.
The P field (3 bits) encodes picture type: I=1, P=2, B=3, D=4; value 0 is forbidden and values 5–7 are reserved. FBV/BFC apply only to B frames; FFV/FFC apply to P and B frames; all four must be zero for I frames.
The T bit signals that an MPEG-2 video-specific header extension (Section 3.4.1) follows the base video header. Its inclusion is optional and intended to improve error resilience by supplying picture coding parameters for GOP/Picture_Header reconstruction after packet loss.
When E=1 in the MPEG-2 header extension, one or more additional extension blocks (quant matrix, picture display, temporal/spatial scalable, copyright) follow. These are self-identifying via extension start codes; zero-padding aligns them to 32-bit boundaries. Their inclusion in any given RTP packet is optional even when the MPEG-2 extension header is present.
A potential denial-of-service threat exists if decoders have non-uniform computational load; an attacker could inject pathological datagrams to overload receivers. The MPEG encoding used here does not exhibit significant non-uniformity, mitigating this risk.
A receiver may be overloaded by excessive packet volume from undesired sources. Network-layer authentication can discard such packets but may itself be costly. In multicast environments, future IGMP versions and multicast routing protocols may support source pruning to let receivers select allowed sources.
Confidentiality is achieved by encrypting RTP packets. Because MPEG data compression is applied end-to-end, encryption can be performed after compression without conflict. The security properties of the RTP specification and applicable RTP profile apply.
The MPEG-2 Video-specific header extension is a 32-bit field following the base video header when T=1. It carries: X (1 bit, reserved), E (1 bit, further extensions present), f_[0,0]/f_[0,1]/f_[1,0]/f_[1,1] (4 bits each, forward/backward h/v f_codes), DC (2 bits, intra_DC_precision), PS (2 bits, picture_structure), and single-bit flags T, P, C, Q, V, A, R, H, G, D (composite_display_flag). When D=1, an additional 32 bits of composite display information follow.
The MPEG Audio-specific header is a 32-bit field placed at the start of the payload (after RTP headers) for every MPEG-1/2 Audio packet. Fields: MBZ (16 bits, reserved zero), Frag_offset (16 bits, byte offset into the audio frame for the data in this packet).
The MPEG Video-specific header is a 32-bit field appended after the RTP fixed header on every video ES packet. Fields: MBZ (5 bits, reserved zero), T (1 bit, MPEG-2 extension present), TR (10 bits, temporal reference 0–1023), AN (1 bit, active N-bit), N (1 bit, new picture header), S (1 bit, sequence-header-present), B (1 bit, beginning-of-slice), E (1 bit, end-of-slice), P (3 bits, picture type), FBV (1 bit), BFC (3 bits), FFV (1 bit), FFC (3 bits).