RTP Payload Format for MPEG-4 Audio/Visual Streams
obsoleted by
- rfc-6416 — RTP Payload Format for MPEG-4 Audio/Visual Streams
Extracted elements (30)
Fragmentation rules are designed to be flexible to accommodate MPEG-4 Visual's wide range of networks, avoiding overly rigid rules (e.g., one video packet per RTP packet always) while still preventing meaningless fragmentation that would hurt error resiliency.
LATM's multiple-object and scalable-layer multiplexing features are omitted from the RTP mapping because RTP carries streams individually; audio for scalable streams should be on separate RTP packets to allow differentiated IP-level treatment.
No extra RTP header fields are defined for MPEG-4 Visual because MPEG-4 Visual already includes built-in error resilience tools (e.g., Header Extension Code in video packet headers) that work across RTP/IP as well as other networks such as H.223/mobile and MPEG-2/TS.
The MPEG-4 Visual stream SHALL be compliant with the Profile@Level indicated by the 'profile-level-id' parameter; interoperability is achieved by negotiating this parameter to a mutually agreed value via MIME content or capability exchange.
These payload formats enable MPEG-4 Audio/Visual transport without MPEG-4 Systems (Sync Layer, Object Descriptors), which may make interoperability with MPEG-4 Systems environments difficult; other payload formats may be better suited to those applications.
A header SHALL NOT be split into a plurality of RTP packets, as doing so increases RTP/IP header overhead and decreases error resiliency.
Configuration information and Group_of_VideoObjectPlane() fields SHALL be placed at the beginning of the RTP payload or just after the header of the syntactically upper layer function.
Different VOPs SHOULD be fragmented into different RTP packets so that each RTP packet corresponds to a unique VOP time instance, except that multiple consecutive small VOPs MAY be carried within one RTP packet.
In in-band LATM mode (muxConfigPresent=1), the StreamMuxConfig element SHOULD be transmitted repeatedly depending on network conditions, because loss of a frame containing StreamMuxConfig makes the following frame non-decodable.
In the dynamic assignment of RTP payload types for scalable MPEG-4 Audio streams, a different PT value SHOULD be assigned to each layer in order of enhancement layer dependency, with the base layer having the smallest value.
It is RECOMMENDED that a single video packet is sent as a single RTP packet, and the packet size SHOULD be adjusted to not exceed path-MTU.
It is RECOMMENDED to put one audioMuxElement in each RTP packet; if the audioMuxElement is too large to fit within path-MTU, it MAY be fragmented across multiple RTP packets.
MPEG-4 Audio streams MUST be formatted using the LATM (Low-overhead MPEG-4 Audio Transport Multiplex) tool before being mapped onto RTP packets.
Structured Audio (SA) data and Text to Speech Interface (TTSI) data MUST NOT be transported by the RTP packetization defined in this document, as LATM was developed only for natural audio coding tools.
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.
The LATM multiplexing features for multiple objects (programs) and scalable layers MUST NOT be used in RTP-based applications defined by this document.
When the short video header mode is used, the RTP payload format for H.263 SHOULD be used; the RFC 2429 format is RECOMMENDED, but RFC 2190 MAY be used for compatibility with older implementations.
For MPEG-4 Visual, if an RTP packet contains only visual_object_sequence_end_code, the timestamp of the immediately preceding VOP in coding order is used; if it contains only configuration information or GoVOP fields, the timestamp of the next VOP is used.
SDP mapping for audio/MP4A-LATM: media name in 'm=', encoding name 'MP4A-LATM' and clock rate in 'a=rtpmap', 'ptime' in 'a=ptime', and 'profile-level-id', 'object', 'bitrate', 'cpresent', 'config' in 'a=fmtp'.
SDP mapping for video/MP4V-ES: media name in 'm=', encoding name 'MP4V-ES' and clock rate in 'a=rtpmap', and 'profile-level-id'/'config' parameters in 'a=fmtp' as semicolon-separated key=value pairs.
The LATM muxConfigPresent flag controls whether StreamMuxConfig is carried in-band (value 1, with useSameStreamMux indicator per frame) or must be provided out-of-band (value 0, via SDP 'config' parameter).
The RTP Marker (M) bit for MPEG-4 Audio indicates audioMuxElement boundaries: it is set to one when the RTP packet contains a complete audioMuxElement or the last fragment of one.
The RTP timestamp for MPEG-4 Audio indicates the sampling instance of the first audio frame in the packet; the default clock rate is 90 kHz unless overridden out-of-band, with other rates allowed only if equal to the audio sampling rate.
The RTP timestamp for MPEG-4 Visual indicates the sampling instance of the VOP; when multiple VOPs are in one packet the timestamp reflects the earliest VOP time, and timestamps of subsequent VOPs are derived from VOP header fields (modulo_time_base, vop_time_increment).
MIME type audio/MP4A-LATM is registered for LATM-framed MPEG-4 Audio streams carried over RTP; required parameter is 'rate' (default 90000); optional parameters include 'profile-level-id', 'object', 'bitrate', 'cpresent', 'config', and 'ptime'.
MIME type video/MP4V-ES is registered for MPEG-4 Visual Elementary Streams carried over RTP; optional parameters include 'rate' (default 90000), 'profile-level-id' (default 1, Simple Profile/Level 1), and 'config' (hex-encoded bitstream configuration).
Because this payload format is restricted to audio and video streams only, active content such as Java applets (MPEG-J) and scripts that the full MPEG-4 system allows cannot be transported, eliminating an associated class of security risks.
RTP packets using this payload format inherit the security considerations of the RTP specification; confidentiality is achieved by encrypting the compressed bitstream end-to-end, with no conflict between compression and encryption. RTP sequence numbers and timestamps MUST start at random values for security.
MPEG-4 Audio RTP payload carries a complete audioMuxElement or fragment thereof, byte-aligned starting at the first payload byte after the standard RTP header, with no removal of audioMuxElement syntax elements.
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 payload is optionally followed by RTP padding.