Audio/Video Transport WG T. Kristensen
Internet-Draft TANDBERG
Intended status: Standards Track March 9, 2009
Expires: September 10, 2009
RTP Payload Format for H.264 RCDO Video
draft-ietf-avt-rtp-h264-rcdo-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This memo describes an RTP Payload format for the Reduced-Complexity
Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as
specified in H.241. RCDO reduces the decoding cost and resource
Kristensen Expires September 10, 2009 [Page 1]
Internet-Draft H.264 RCDO RTP Payload March 2009
consumption of the video processing. The RTP Payload format is based
on the description in RFC 3984.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . . 3
3. Media Format Background . . . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 4
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 4
5. Payload Examples . . . . . . . . . . . . . . . . . . . . . . . 4
6. Congestion Control Considerations . . . . . . . . . . . . . . . 4
7. Payload Format Parameters . . . . . . . . . . . . . . . . . . . 4
7.1. Media Type Definition . . . . . . . . . . . . . . . . . . . 4
8. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Offer/Answer Considerations . . . . . . . . . . . . . . . . 6
8.2. Declarative SDP Considerations . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . . 8
12.2. Informative references . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Kristensen Expires September 10, 2009 [Page 2]
Internet-Draft H.264 RCDO RTP Payload March 2009
1. Introduction
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 [4] and ITU-T H.241 [5], 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 [3]. The RCDO
approach is already addressed in the latest version of H.241 [5].
This proposal defines media type parameters, a new H.264 media
subtype for RCDO and allows use in SDP.
2. Conventions, Definitions and Acronyms
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 [1].
3. Media Format Background
The Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline
profile bitstreams is specified in Annex B of H.241 [5]. 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 [3]. 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 [5].
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 [3].
To maintain backward compatibility with existing H.264
implementations, this memo proposes a separate media subtype for RCDO
Kristensen Expires September 10, 2009 [Page 3]
Internet-Draft H.264 RCDO RTP Payload March 2009
named H264-RCDO.
4. Payload Format
Section 5 of RFC 3984 [3] applies.
4.1. RTP Header Usage
Editorial note: Refer to RFC 3984 or include verbatim/sligthly
modified version from Section 5 of RFC 3984 [3] in final version.
4.2. Payload Header
Editorial note: Refer to RFC 3984 or include verbatim/sligthly
modified version from Section 5 of RFC 3984 [3] in final version.
5. Payload Examples
TBD or refer to RFC3984.
6. Congestion Control Considerations
Congestion control for RTP SHALL be used in accordance with RFC 3550
[6], and with any applicable RTP profile; e.g., RFC 3551 [7]. 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.
7. Payload Format Parameters
This RTP payload format is identified using the H264-RCDO media type
which is registered in accordance with RFC 4855 [8] and using the
template of RFC 4288 [9].
7.1. Media Type Definition
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.
Kristensen Expires September 10, 2009 [Page 4]
Internet-Draft H.264 RCDO RTP Payload March 2009
Type name: video
Subtype name: H264-RCDO
Required parameters:
rate: Indicates the RTP timestamp clock rate. The rate value MUST
be 90000.
Optional parameters:
The optional media type parameters specified in RFC 3984 [3] apply,
with the following constraints:
profile-level-id: 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.
Encoding considerations: This type is only defined for transfer via
RTP (RFC 3550).
Security considerations: See section X of RFC YYYY. (TBD. Update
when this memo becomes an RFC)
Interoperability considerations: None
Published specification: (TBD. Update when this memo becomes an
RFC. Also refer to H.264 and H.241 in an IANA way.)
Applications that use this media type: None
Kristensen Expires September 10, 2009 [Page 5]
Internet-Draft H.264 RCDO RTP Payload March 2009
Additional information: None
Magic number(s): None
File extension(s): None
Macintosh file type code(s): None
Person & email address to contact for further information:
Tom Kristensen <tom.kristensen@tandberg.com>
Intended usage: COMMON
Restrictions on usage: 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.
Author: Tom Kristensen
Change controller: IETF Audio/Video Transport working group
delegated from the IESG.
8. Mapping to SDP
The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of RFC 4855 [8].
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
8.1. Offer/Answer Considerations
When H264-RCDO is offered over RTP using SDP in an Offer/Answer model
[2] for unicast and multicast usage, the limitations and rules
described in Section 8.2.2 of RFC 3984 [3] apply. Note that the
H264-RCDO profile-level-id parameter can only take the value 0 (no
profile) for the profile part.
8.2. Declarative SDP Considerations
When H264-RCDO over RTP is offered with SDP in a declarative style,
as in RTSP [13] or SAP [14], the considerations in Section 8.2.3 of
Kristensen Expires September 10, 2009 [Page 6]
Internet-Draft H.264 RCDO RTP Payload March 2009
RFC 3984 [3] apply. Note that the H264-RCDO profile-level-id
parameter can only take the value 0 (no profile) for the profile
part.
9. IANA Considerations
This memo requests that IANA registers H264-RCDO as specified in
Section Section 7.1. 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).
10. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [6], 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 [10] is recommended. Other mechanism that may be
used are IPsec [11] and TLS [12] (RTP over TCP), but also other
alternatives may exist.
Refer also to section 9 of RFC 3984 [3], as no reasons for separate
considerations are introduced in this document.
11. Acknowledgements
The RTP Payload Formats HOWTO [15] was used for guidance and proved
helpful in the process.
12. References
Kristensen Expires September 10, 2009 [Page 7]
Internet-Draft H.264 RCDO RTP Payload March 2009
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Wenger, S., Hannuksela, M., Stockhammer, T., Westerlund, M.,
and D. Singer, "RTP Payload Format for H.264 Video", RFC 3984,
February 2005.
[4] International Telecommunications Union, "Advanced video coding
for generic audiovisual services", ITU-T Recommendation H.264,
March 2005.
[5] International Telecommunications Union, "Extended video
procedures and control signals for H.300-series terminals",
ITU-T Recommendation H.241, May 2006.
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[8] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855, February 2007.
12.2. Informative references
[9] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[10] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[11] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[13] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
Kristensen Expires September 10, 2009 [Page 8]
Internet-Draft H.264 RCDO RTP Payload March 2009
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[15] Westerlund, M., "How to Write an RTP Payload Format",
draft-ietf-avt-rtp-howto-06 (work in progress), March 2009.
Author's Address
Tom Kristensen
TANDBERG
Philip Pedersens vei 22
N-1366 Lysaker
Norway
Phone: +47 67125125
Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no
URI: http://www.tandberg.com
Kristensen Expires September 10, 2009 [Page 9]
