RTP Payload Format for H.264 RCDO Video

The Reduced-Complexity Decoding Operation (RCDO) for H.264 offers a solution to support higher resolutions at the same high framerates used in current implementations, but with reduced processing requirements, compared to today's needs. This is achieved by reducing the complexity and thus the decoding cost/resource consumption of the video processing. ITU-T H.264 and ITU-T H.241 , its associated video procedures and signalling recommendation, continue to evolve. The IETF RTP payload formats and parameters need to be updated to include important new functionalities not covered in RFC 3984 . The RCDO approach is already addressed in the latest version of H.241 . This proposal defines media type parameters, a new H.264 media subtype for RCDO and allows use in SDP.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams is specified in Annex B of H.241 . RCDO is specified as a separate H.264 mode, and is distinct from any profile defined in H.264. An RCDO bitstream obey to all the constraints of the Baseline profile. The media format is based on the H.264 RTP Payload format as specified in RFC 3984 . Therefore, RFC 3984 is referred to several times in this memo. In order to signal H.264 additional modes the parameter AdditionalModesSupported is specified in Table 9f of H.241 . Currently, the only mode defined is RCDO. Informational note: Other additional modes may be defined in the future. However, as H.264 additional modes may or may not be distinct from the Profiles in H.264 - these modes would require separate extensions to RFC 3984 . To maintain backward compatibility with existing H.264 implementations, this memo proposes a separate media subtype for RCDO named H264-RCDO.

Section 5 of RFC 3984 applies.

Editorial note: Refer to RFC 3984 or include verbatim/sligthly modified version from Section 5 of RFC 3984 in final version.

TBD or refer to RFC3984.

Congestion control for RTP SHALL be used in accordance with RFC 3550 , and with any applicable RTP profile; e.g., RFC 3551 . An additional requirement if best-effort service is being used is: users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters.

This RTP payload format is identified using the H264-RCDO media type which is registered in accordance with RFC 4855 and using the template of RFC 4288 .

Editorial note: For now we describe the changes and differences to the H264 media type. Copy unchanged parts verbatim from RFC 3984 in the final version and for IANA registration. The media subtype for the ITU-T H.264 | ISO/IEC 14496-10 codec is allocated from the IETF tree. The receiver MUST ignore any unspecified parameter. Type name: video Subtype name: H264-RCDO Required parameters: Indicates the RTP timestamp clock rate. The rate value MUST be 90000. Optional parameters: The optional media type parameters specified in RFC 3984 apply, with the following constraints: RCDO is distinct from any profile, this implies that the profile value 0 (no profile) and the profile_idc byte of the profile-level-id parameter are equal to 0. An RCDO bitstream MUST obey to all the constraints of the Baseline profile. Therefore, only constraint_set0_flag is equal to 1 in the profile-iop part of the profile-level-id parameter, the remaining bits are set to 0. For example, if a codec supports level 2.1, the profile-level-id becomes 00800d, in which 00 indicates the "no profile" value, 80 indicates the constraints of the Baseline profile and 0d indicates level 1.3. When level 2.1 is supported, the profile-level-id becomes 008015. If no profile-level-id is present, level 1 MUST be implied, i.e. equivalent to profile-level-id 00800a. This type is only defined for transfer via RTP (RFC 3550). See section X of RFC YYYY. (TBD. Update when this memo becomes an RFC) None (TBD. Update when this memo becomes an RFC. Also refer to H.264 and H.241 in an IANA way.) None None None None None Tom Kristensen <tom.kristensen@tandberg.com> COMMON This media type depends on RTP framing, and hence is only defined for transfer via RTP, ref RFC3550. Transport within other framing protocols is not defined at this time. Tom Kristensen IETF Audio/Video Transport working group delegated from the IESG.

The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855 . An example of media representation of a level 2 bitstream is as follows: m=video 54321 RTP/AVP 101 a=rtpmap:101 H264-RCDO/90000 a=fmtp:101 profile-level-id=008014;max-mbps=60000

When H264-RCDO is offered over RTP using SDP in an Offer/Answer model for unicast and multicast usage, the limitations and rules described in Section 8.2.2 of RFC 3984 apply. Note that the H264-RCDO profile-level-id parameter can only take the value 0 (no profile) for the profile part.

When H264-RCDO over RTP is offered with SDP in a declarative style, as in RTSP or SAP , the considerations in Section 8.2.3 of RFC 3984 apply. Note that the H264-RCDO profile-level-id parameter can only take the value 0 (no profile) for the profile part.

This memo requests that IANA registers H264-RCDO as specified in Section . The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" (http://www.iana.org/assignments/rtp-parameters).

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification , and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets through suitable cryptographic integrity protection mechanism. Cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection and at least source authentication capable of determining if an RTP packet is from a member of the RTP session or not. Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signalling protocol employed. Therefore a single mechanism is not sufficient, although if suitable the usage of SRTP is recommended. Other mechanism that may be used are IPsec and TLS (RTP over TCP), but also other alternatives may exist. Refer also to section 9 of RFC 3984 , as no reasons for separate considerations are introduced in this document.

The RTP Payload Formats HOWTO was used for guidance and proved helpful in the process.