RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video
Extracted elements (25)
A separate media subtype H264-RCDO is defined (rather than reusing H264) to ensure backward compatibility with deployed implementations of H.264. RCDO is distinct from any H.264 profile, so a new subtype prevents confusion with standard H.264 decoders.
The max-br and max-dpb parameters were added primarily to complement similar codepoints in ITU-T Recommendation H.245, facilitating signaling gateway designs between IP and H.300-series environments.
The max-dpb parameter uses units of 8/3 macroblocks (changed from 1024 bytes in RFC 3984) to maintain backward compatibility with RFC 3984 while also supporting all profiles defined in the 2010 H.264 specification, which added color formats and bit depths not supported earlier.
For interoperability with systems not supporting H264-RCDO, it is RECOMMENDED to offer the H264 media subtype as well. Listing H264-RCDO before H264 on the SDP 'm=' line signals preference per RFC 3264 Offer/Answer rules.
In both offer/answer and declarative SDP contexts, the profile_idc byte of the H264-RCDO profile-level-id parameter can only take the value 0 (no profile), distinguishing it from standard H.264 profile negotiation.
A receiver MUST NOT signal values of max-mbps, max-fs, max-cpb, max-dpb, and max-br that taken together meet the requirements of a higher level than the highest level specified in profile-level-id or max-recv-level.
An RCDO bitstream MUST obey all the constraints of the Baseline profile; therefore, only constraint_set0_flag equals 1 in the profile-iop part of the profile-level-id parameter.
Congestion control for RTP SHALL be used in accordance with RFC 3550 and any applicable RTP profile. When best-effort service is used, implementations SHALL monitor packet loss to ensure it remains within acceptable parameters.
If level-asymmetry-allowed is 0 (or absent) in either the offer or the answer, the level used in the offerer-to-answerer direction MUST be the same as in the reverse direction.
If no profile-level-id is present, level 1 (equivalent to profile-level-id 00800a) MUST be implied.
max-recv-level MUST NOT be present if the highest level the receiver supports is not higher than the default level indicated by profile-level-id.
sprop-deint-buf-req MUST NOT be present when packetization-mode is absent or 0 or 1, and MUST be present when packetization-mode equals 2. Its value MUST be greater than or equal to the maximum de-interleaving buffer occupancy in bytes.
sprop-interleaving-depth MUST NOT be present when packetization-mode is absent or 0 or 1, and MUST be present when packetization-mode equals 2. Its value MUST be an integer in the range 0 to 32767.
sprop-parameter-sets MUST only contain parameter sets conforming to the profile-level-id; the subset of coding tools indicated MUST equal the default sub-profile and the level MUST equal the default level.
The mapping of the H264-RCDO payload format media subtype and parameters to SDP SHALL be done according to Section 3 of RFC 4855.
The packetization-mode parameter controls which packetization mode is used: value 0 or absent means single NAL mode MUST be used; value 1 means non-interleaved mode MUST be used; value 2 means interleaved mode MUST be used. The value MUST be an integer in the range 0 to 2.
The payload format defined in Section 5 of RFC 6184 SHALL be used for H264-RCDO, including RTP header usage and payload format. No new packet format is introduced.
The RTP timestamp clock rate (rate parameter) MUST be 90000 for H264-RCDO.
When in-band-parameter-sets equals 1, use-level-src-parameter-sets MUST NOT be present or MUST be equal to 0. When in-band-parameter-sets equals 1, the sender MUST transmit all parameter sets in-band.
When multiple capability parameters (max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br) are present, the receiver MUST support all signaled capabilities simultaneously.
When redundant-pic-cap is not present, a value of 0 MUST be used. When present, the value MUST be either 0 or 1. When the indicated profile disallows redundant coded pictures, redundant-pic-cap MUST be 0.
The H264-RCDO media subtype uses a profile-level-id where profile_idc is always 0 (no profile) and only constraint_set0_flag is 1 in the profile-iop byte, reflecting RCDO's compliance with Baseline profile constraints while being distinct from any named profile.
The sprop-level-parameter-sets parameter conveys parameter sets for levels different from the default level, structured as PLId:PSL pairs separated by colons, enabling receivers to install parameter sets for a specific level and discard the rest.
IANA registered H264-RCDO as a new video media subtype under the IETF tree, and added it to the IANA registry for 'RTP Payload Format MIME types'.
RTP packets using the H264-RCDO payload format are subject to the security considerations of the RTP specification (RFC 3550), applicable RTP profiles, and the H.264 RTP payload format specification in RFC 6184. No additional security considerations are introduced by this specification.