[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kristensen-avt-rtp-h264-rcdo) 00 01 02 03 04 05 06 07 08 RFC 6185

Audio/Video Transport WG                                   T. Kristensen
Internet-Draft                                                  TANDBERG
Intended status: Standards Track                       November 19, 2007
Expires: May 22, 2008


                RTP Payload Format for H.264 RCDO Video
                    draft-ietf-avt-rtp-h264-rcdo-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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
   consumption of the video processing.  The RTP Payload format is based
   on the description in RFC 3984.






Kristensen                Expires May 22, 2008                  [Page 1]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


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 . . . . . . . . . . . . . .  7
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   10. Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     12.1. Normative References . . . . . . . . . . . . . . . . . . .  8
     12.2. Informative references . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10




























Kristensen                Expires May 22, 2008                  [Page 2]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


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 RFC 3984 [3].

   To maintain backward compatibility with existing H.264
   implementations, this memo proposes a separate media subtype for RCDO



Kristensen                Expires May 22, 2008                  [Page 3]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


   named H264-RCDO.


4.  Payload Format

   Section 5 of RFC 3984 [3] applies.

4.1.  RTP Header Usage

      Editorial note: Include verbatim or sligthly modified version from
      Section 5 of RFC 3984 [3] in a later phase.  Or simply refer to
      RFC 3984?

4.2.  Payload Header

      Editorial note: Include verbatim or sligthly modified version from
      Section 5 of RFC 3984 [3] in a later phase.  Or simply refer to
      RFC 3984?


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: Complete formal media type specification TBD.  For
      now we mainly describe the changes and differences.  Copy 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.



Kristensen                Expires May 22, 2008                  [Page 4]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


   The receiver MUST ignore any unspecified parameter.

   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.

         Editorial note: In H.241 the profile value is set to 0,
         assuming no profile.  Therefore this draft currently proposes
         using 0 for the profile part of profile-level-id.  However, as
         RCDO is applied to Baseline profile bitstreams we might
         consider using the Baseline profile as value.  TBD.

      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)







Kristensen                Expires May 22, 2008                  [Page 5]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


   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

   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;max-smbps=360000

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



Kristensen                Expires May 22, 2008                  [Page 6]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


   H264-RCDO profile-level-id parameter does only have 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
   RFC 3984 [3] apply.  Note that the H264-RCDO profile-level-id
   parameter does only have 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.





Kristensen                Expires May 22, 2008                  [Page 7]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


11.  Acknowledgements

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


12.  References

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



Kristensen                Expires May 22, 2008                  [Page 8]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


         Protocol", RFC 4301, December 2005.

   [12]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [13]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.

   [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-01 (work in progress), December 2006.


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 May 22, 2008                  [Page 9]

Internet-Draft           H.264 RCDO RTP Payload            November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Kristensen                Expires May 22, 2008                 [Page 10]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/