RTP Payload Format for MPEG-4 Audio/Visual Streams
obsoletes
- rfc-3016 — RTP Payload Format for MPEG-4 Audio/Visual Streams
Extracted elements (27)
Multiple small VOPs (e.g., empty VOPs with vop_coded=0, or arbitrarily shaped VOPs with few coding blocks) are permitted to be concatenated into one RTP packet to reduce per-packet header overhead, despite the general rule that different VOPs should be in separate packets.
No additional media-specific RTP header fields are defined for MPEG-4 Visual because MPEG-4 Visual already has built-in error resiliency tools for recovering corrupt headers (usable across RTP/IP, H.223/mobile, MPEG-2 TS), unlike H.261 or MPEG-1/2 which required extra RTP headers.
The 'rate' parameter for MP4A-LATM is defined unambiguously for the SBR case: when SBR presence is not explicitly signaled it SHALL equal the core codec sampling rate; when SBR is explicitly signaled it SHALL equal the SBR (output) sampling rate. This resolves an ambiguity in RFC 3016 and supports legacy AAC decoders.
RFC 6416 is NOT backward compatible with RFC 3016 because a binary-incompatible newer version of LATM is mandated. Existing RFC 3016 implementations using the old LATM version MUST be updated; implementations already using the newer LATM (e.g., 3GPP PSS) may already comply with RFC 6416.
When MPEG-4 Visual short video header mode is used, the RTP payload format for H.263 SHOULD be used instead; RFC 4629 is RECOMMENDED, but RFC 4628 MAY be used for compatibility with older implementations.
A header (configuration info, GOV, VOP header, video packet header, etc.) SHALL NOT be split across a plurality of RTP packets. This is required to maintain error resiliency.
Different VOPs SHOULD be fragmented into different RTP packets so that each RTP timestamp uniquely indicates the VOP time framing. An exception allows multiple consecutive small VOPs in one RTP packet.
For scalable MPEG-4 Audio streams, the server SHALL assign a different RTP payload type value to each layer, and the dependency relationships between enhanced and base layers MUST be signaled as specified in RFC 5583.
If an audioMuxElement is too large to fit within the Path MTU, the audioMuxElement SHALL be fragmented and spread across multiple RTP packets. It is RECOMMENDED to put one audioMuxElement in each RTP packet when size permits.
In in-band configuration mode (muxConfigPresent=1), the StreamMuxConfig element SHOULD be transmitted repeatedly depending on network conditions, since a lost frame containing StreamMuxConfig can render subsequent frames undecodable.
It is RECOMMENDED that a single video packet is sent as a single RTP packet, and the video packet size SHOULD be adjusted so that the resulting RTP packet does not exceed the Path MTU.
LATM multiplexing of multiple objects (programs) and scalable layers MUST NOT be used in RTP packetization. SA data and TTSI data MUST NOT be transported by this RTP packetization.
MPEG-4 Audio streams MUST be formatted as LATM (Low-overhead MPEG-4 Audio Transport Multiplex) streams before being mapped onto RTP packets.
Receivers MUST ignore any unspecified parameter in both the MP4V-ES and MP4A-LATM media type registrations to ensure that additional parameters can be added in future revisions.
Senders MUST set the StreamMuxConfig elements taraBufferFullness and latmBufferFullness to their largest respective value in the SDP 'config' parameter; receivers MUST ignore these two elements when present in 'config'.
The Combined Configuration/Elementary stream mode MUST be used for MPEG-4 Visual so that configuration information is carried to the same RTP port as the elementary stream. If out-of-band configuration is needed (e.g., SIP, RTSP), the optional parameter 'config' MUST be used.
The first byte of each audioMuxElement SHALL be located at the first payload location in an RTP packet. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without removal of syntax elements.
For scalable MPEG-4 Audio streams, audio data of each layer SHOULD be packetized onto different RTP streams to allow differentiated treatment at the IP level. All layers share one StreamMuxConfig, and LATM header information maps each layer to its configuration.
The MPEG-4 Audio RTP timestamp indicates the sampling instance of the first audio frame in the packet. Timestamps are RECOMMENDED to start at a random value for security. Default clock rate is 90 kHz unless overridden out-of-band.
The MPEG-4 Visual RTP timestamp indicates the sampling instance of the VOP in the packet. When multiple VOPs are in one packet, the timestamp indicates the earliest VOP time; timestamps for remaining VOPs are derived from VOP header fields (modulo_time_base, vop_time_increment). Default resolution is 90 kHz.
The RTP marker bit for MPEG-4 Audio is set to 1 when the packet contains a complete audioMuxElement or the last fragment of an audioMuxElement, indicating audioMuxElement boundaries.
The RTP marker bit for MPEG-4 Visual is set to 1 to indicate the last (or only) RTP packet of a VOP. When multiple VOPs are carried in one RTP packet, the marker bit is also set to 1.
This document updates the media subtype 'MP4V-ES' (video) and 'MP4A-LATM' (audio) registrations originally from RFC 3016. The updated registrations are in Sections 7.1 and 7.3 respectively.
Most MPEG-4 codecs define an extension mechanism to transmit extra data within a valid stream that is gracefully skipped by non-supporting decoders. This mechanism could be exploited to embed unwanted data in an otherwise legitimate stream.
RTP packets using this payload format require confidentiality (via RTP payload encryption), integrity protection, and source authentication. SRTP (RFC 3711) is recommended where suitable; IPsec (RFC 4301) and TLS (RFC 5246) are also cited as alternatives.
MPEG-4 Audio RTP payload carries the audioMuxElement byte-aligned directly after the standard RTP header. The first byte of each audioMuxElement is at the first payload byte position; no additional header fields are added.
MPEG-4 Visual RTP payload carries the MPEG-4 Visual bitstream byte-aligned directly after the standard RTP header with no additional header fields. The bitstream fragment begins immediately at the first payload byte.