RTP Payload Format for Scalable Video Coding
Extracted elements (28)
MST was designed for layered multicast where different receivers subscribe to different subsets of scalability layers; SST was retained for unicast and point-to-point scenarios where multiple RTP sessions add complexity without benefit.
The NI-TC mode was defined to carry both RTP timestamps and CS-DON values simultaneously, allowing receivers to choose their preferred decoding-order recovery technique without requiring separate session configurations or breaking interoperability.
The PACSI NAL unit was introduced to allow MANEs to make forwarding and discarding decisions based on a single summary NAL unit rather than parsing codec-internal NAL unit structures, enabling scalable MANE operation without requiring deep knowledge of the SVC codec syntax.
RFC 6190 is backward compatible with RFC 6184: when an H.264/AVC-compatible subset of the SVC base layer is transmitted in its own RTP session, RFC 6184 packetization must be used, allowing legacy RFC 6184 receivers to join multi-session transmissions and decode the base layer without modification.
SVC NAL unit types 14, 15, and 20 are reserved in H.264/AVC Annex A profiles and are silently ignored by conforming H.264/AVC decoders, ensuring that the AVC base layer sub-stream is decodable by existing H.264/AVC equipment without changes.
Dependency between RTP sessions in multi-session transmission MUST be signaled according to Section 7.2.3. SST SHOULD be used for point-to-point unicast; MST SHOULD be used for point-to-multipoint multicast with heterogeneous receivers.
For an RTP packet whose payload is a PACSI NAL unit, the RTP timestamp MUST equal the NALU-time of the next non-PACSI NAL unit in transmission order.
For NI-MTAP, J MUST be 0 for SST and for MST NI-T mode. J MUST be 1 for NI-C and NI-TC modes, and when present the DON field MUST carry the CS-DON value as defined in Section 6.2.2.
If the OPTIONAL mst-mode media type parameter is not present, SST MUST be used; if mst-mode is present, MST MUST be used. The MST packetization mode in use MUST be signaled by the value of the mst-mode parameter.
NAL units in an NI-MTAP MUST be aggregated in decoding order. The Type field MUST be 31, Subtype MUST be 2, and fields K and L MUST both be 0.
PACSI NAL units MUST NOT be fragmented. Their Type field MUST be equal to 30.
Receivers MUST ignore the entire NAL unit when the Subtype field (in a type-31 extension octet) equals any reserved value (0 or 3–31).
The M bit of an RTP packet whose payload is an NI-MTAP MUST be set to 1 if the last NAL unit in decoding order of the access unit associated with the RTP timestamp is contained in the packet.
The RR (reserved_three_2bits) field in the three-byte SVC NAL unit header extension MUST be equal to binary '11'; decoders must ignore its value.
The SVC base layer or any H.264/AVC compatible subset, when transmitted in its own RTP stream (in either SST or MST), MUST use RFC 6184 packetization to ensure compatibility with RFC 6184 receivers.
When a PACSI NAL unit is present in an aggregation packet, it MUST be the first aggregated NAL unit and there MUST be at least one additional aggregated NAL unit in the packet.
When MST NI-C mode is in use, empty NAL units (type 31, subtype 1) MUST NOT be used. When MST I-C mode is in use, both empty NAL units and NI-MTAP NAL units MUST NOT be used.
Four MST packetization modes are defined: NI-T (non-interleaved, timestamp-based order recovery), NI-C (non-interleaved, CS-DON-based), NI-TC (combined timestamp and CS-DON), and I-C (interleaved, CS-DON-based). NI-T/NI-C/NI-TC target low-latency systems; I-C supports non-real-time applications.
The Cross-Session Decoding Order Number (CS-DON) is a derived variable indicating NAL unit decoding order across all session-multiplexed RTP sessions carrying the same SVC bitstream, used by NI-C, NI-TC, and I-C modes for decoding order recovery.
The Empty NAL unit (type 31, subtype 1) consists solely of the two-byte extension NAL unit header with no payload. It is used to ensure inter-session timestamp alignment required for decoding order recovery in NI-T and NI-TC MST modes.
The PACSI (Payload Content Scalability Information) NAL unit (type 30) is a new NAL unit type providing a summary of scalability information and CS-DON values for data in an RTP packet, enabling MANEs to make forwarding decisions without parsing codec-defined inner NAL units.
The SVC NAL unit header is a four-byte header for NAL unit types 14 and 20, extending the one-byte H.264/AVC header with three bytes encoding R, I (idr_flag), PRID (6 bits priority), N, DID (3 bits dependency_id), QID (4 bits quality_id), TID (3 bits temporal_id), U, D, O, and RR (2 bits reserved) fields.
This document registers the media subtype 'video/H264-SVC' with IANA, distinct from 'video/H264' (RFC 6184). New format-specific parameters include mst-mode, sprop-avc-ready, and scalable-layer-id, among others.
The security considerations of RFC 3550 and RFC 6184 apply. MANEs that parse and rewrite RTP/RTCP headers must be trusted entities when operating with SRTP, as they process media in cleartext; SRTP key management must account for this trust relationship.
Each non-interleaved multi-time aggregation unit in an NI-MTAP consists of: 16-bit NAL unit size (network byte order), 16-bit TS offset (NALU-time minus RTP timestamp, with modular wraparound), optional 16-bit DON, and the NAL unit bytes. The earliest aggregation unit's TS offset MUST be zero.
The NAL unit extension octet, present when Type=31, carries a 5-bit Subtype field and three 1-bit flags J, K, L. Subtype=1 denotes an empty NAL unit; Subtype=2 denotes an NI-MTAP; all other Subtype values are reserved.
The payload header length varies by Type: if Type equals 14, 20, or 30 the first 4 bytes form the payload header; if Type equals 31, the first 2 bytes form the header; otherwise the payload header is the first byte of the RTP packet payload.
The SVC NAL unit header extension occupies 3 additional octets after the standard 1-byte NAL unit header for types 14 and 20: byte 2 = R(1)|I(1)|PRID(6); byte 3 = N(1)|DID(3)|QID(4); byte 4 = TID(3)|U(1)|D(1)|O(1)|RR(2).