draft-ietf-avt-rtp-rfc3984bis-10.txt   draft-ietf-avt-rtp-rfc3984bis-11.txt 
Obsoletes RFC 3984 Obsoletes RFC 3984
Audio/Video Transport WG Y.-K. Wang Audio/Video Transport WG Y.-K. Wang
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Standards track R. Even Intended status: Standards track R. Even
Expires: October 2010 Self-employed Expires: December 2010 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
R. Jesup R. Jesup
WorldGate Communications WorldGate Communications
April 4, 2010 June 25, 2010
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-10.txt draft-ietf-avt-rtp-rfc3984bis-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 4, 2010. This Internet-Draft will expire on December 25, 2010.
Copyright Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
skipping to change at page 4, line 18 skipping to change at page 4, line 18
Correction...................................................85 Correction...................................................85
12.6. Low Bit-Rate Streaming.................................88 12.6. Low Bit-Rate Streaming.................................88
12.7. Robust Packet Scheduling in Video Streaming............89 12.7. Robust Packet Scheduling in Video Streaming............89
13. Informative Appendix: Rationale for Decoding Order Number...90 13. Informative Appendix: Rationale for Decoding Order Number...90
13.1. Introduction...........................................90 13.1. Introduction...........................................90
13.2. Example of Multi-Picture Slice Interleaving............90 13.2. Example of Multi-Picture Slice Interleaving............90
13.3. Example of Robust Packet Scheduling....................92 13.3. Example of Robust Packet Scheduling....................92
13.4. Robust Transmission Scheduling of Redundant Coded Slices96 13.4. Robust Transmission Scheduling of Redundant Coded Slices96
13.5. Remarks on Other Design Possibilities..................96 13.5. Remarks on Other Design Possibilities..................96
14. Backward Compatibility to RFC 3984..........................97 14. Backward Compatibility to RFC 3984..........................97
15. Changes from RFC 3984.......................................98 15. Changes from RFC 3984.......................................99
16. Acknowledgements...........................................100 16. Acknowledgements...........................................101
17. References.................................................101 17. References.................................................101
17.1. Normative References..................................101 17.1. Normative References..................................101
17.2. Informative References................................101 17.2. Informative References................................102
18. Authors' Addresses.........................................103 18. Authors' Addresses.........................................104
1. Introduction 1. Introduction
This memo specifies an RTP payload specification for the video This memo specifies an RTP payload specification for the video
coding standard known as ITU-T Recommendation H.264 [1] and ISO/IEC coding standard known as ITU-T Recommendation H.264 [1] and ISO/IEC
International Standard 14496 Part 10 [2] (both also known as International Standard 14496 Part 10 [2] (both also known as
Advanced Video Coding, or AVC). In this memo the name H.264 is Advanced Video Coding, or AVC). In this memo the name H.264 is
used for the codec and the standard, but the memo is equally used for the codec and the standard, but the memo is equally
applicable to the ISO/IEC counterpart of the coding standard. applicable to the ISO/IEC counterpart of the coding standard.
skipping to change at page 97, line 23 skipping to change at page 97, line 23
multiple access units in the same RTP packet. An access unit is multiple access units in the same RTP packet. An access unit is
specified in the H.264 coding standard to comprise all NAL units specified in the H.264 coding standard to comprise all NAL units
associated with a primary coded picture according to subclause associated with a primary coded picture according to subclause
7.4.1.2 of [1]. Consequently, slices of different pictures cannot 7.4.1.2 of [1]. Consequently, slices of different pictures cannot
be interleaved, and the multi-picture slice interleaving technique be interleaved, and the multi-picture slice interleaving technique
(see section 12.6) for improved error resilience cannot be used. (see section 12.6) for improved error resilience cannot be used.
14. Backward Compatibility to RFC 3984 14. Backward Compatibility to RFC 3984
The current document is a revision of RFC 3984 and obsoletes it. The current document is a revision of RFC 3984 and obsoletes it.
The technical changes relative to RFC 3984 are listed in section 15.
This section addresses the backward compatibility issues. This section addresses the backward compatibility issues.
The technical changes are listed in section 15. It should be noted that for the majority of cases, there will be no
compatibility issues for legacy implementations per RFC 3984 and
new implementations per this document to interwork. Compatibility
issues may only occur when both of the following conditions are
true: 1) legacy implementations and new implementations are
interworking; and 2) parameter sets are transported out of band.
Even when such compatibility issues occur, it is easy to debug and
find out the reason according to the following analyses.
Items 1), 2), 3), 7), 9), 10), 12) and 13) are bug-fix type of Items 1), 2), 3), 7), 9), 10), 12) and 13) are bug-fix type of
changes, and do not incur any backward compatibility issues. changes, and do not incur any backward compatibility issues.
Item 4), addition of six new media type parameters, does not incur Item 4), addition of six new media type parameters, does not incur
any backward compatibility issues for SDP Offer/Answer based any backward compatibility issues for SDP Offer/Answer based
applications, as legacy RFC 3984 receivers ignore these parameters, applications, as legacy RFC 3984 receivers ignore these parameters,
and it is fine for legacy RFC 3984 senders not to use these and it is fine for legacy RFC 3984 senders not to use these
parameters as they are optional. However, there is a backward parameters as they are optional. However, there is a backward
compatibility issue for SDP declarative usage based applications, compatibility issue for SDP declarative usage based applications
e.g. those using RTSP and SAP, because the SDP receiver per RFC (only for the parameter sprop-level-parameter-sets as the other
3984 cannot accept a session for which the SDP includes an five parameters are not usable in declarative usage), e.g. those
unrecognized parameter. Therefore, the RTSP or SAP server may have using RTSP and SAP, because the SDP receiver per RFC 3984 cannot
to prepare two sets of streams, one for legacy RFC 3984 receivers accept a session for which the SDP includes an unrecognized
and one for receivers according to this memo. parameter. Therefore, the RTSP or SAP server may have to prepare
two sets of streams, one for legacy RFC 3984 receivers and one for
receivers according to this memo.
Items 5), 6), and 11) are related to out-of-band transport of Items 5), 6), and 11) are related to out-of-band transport of
parameter sets. There are following backward compatibility issues. parameter sets. There are following backward compatibility issues.
1) When a legacy sender per RFC 3984 includes parameter sets for a 1) When a legacy sender per RFC 3984 includes parameter sets for a
level different than the default level indicated by profile- level different than the default level indicated by profile-
level-id to sprop-parameter-sets, the parameter value of sprop- level-id to sprop-parameter-sets, the parameter value of sprop-
parameter-sets is invalid to the receiver per this memo and parameter-sets is invalid to the receiver per this memo and
therefore the session may be rejected. therefore the session may be rejected.
skipping to change at page 101, line 5 skipping to change at page 101, line 17
upgrade and asymmetry. upgrade and asymmetry.
16. Acknowledgements 16. Acknowledgements
Stephan Wenger, Miska Hannuksela, Thomas Stockhammer, Magnus Stephan Wenger, Miska Hannuksela, Thomas Stockhammer, Magnus
Westerlund, and David Singer are thanked as the authors of RFC 3984. Westerlund, and David Singer are thanked as the authors of RFC 3984.
Dave Lindbergh, Philippe Gentric, Gonzalo Camarillo, Gary Sullivan, Dave Lindbergh, Philippe Gentric, Gonzalo Camarillo, Gary Sullivan,
Joerg Ott, and Colin Perkins are thanked for careful review during Joerg Ott, and Colin Perkins are thanked for careful review during
the development of RFC 3984. Stephen Botzko, Magnus Westerlund, the development of RFC 3984. Stephen Botzko, Magnus Westerlund,
Alex Eleftheriadis, Thomas Schierl, Tom Taylor, Ali Begen, Aaron Alex Eleftheriadis, Thomas Schierl, Tom Taylor, Ali Begen, Aaron
Wells, Stuart Taylor, and Robert Sparks are thanked for their Wells, Stuart Taylor, Robert Sparks, Dan Romascanu, and Niclas
valuable comments and inputs during the development of this memo. Comstedt are thanked for their valuable comments and inputs during
the development of this memo.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
17. References 17. References
17.1. Normative References 17.1. Normative References
[1] ITU-T Recommendation H.264, "Advanced video coding for [1] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services", November 2007. generic audiovisual services", November 2007.
skipping to change at page 101, line 33 skipping to change at page 101, line 46
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD "RTP: A Transport Protocol for Real-Time Applications", STD
64, RFC 3550, July 2003. 64, RFC 3550, July 2003.
[6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[7] Josefsson, S., "The Base16, Base32, and Base64 Data [7] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 4648, October 2006.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Lennox, J., Ott, J., and Schierl, T., "Source-Specific Media [9] Lennox, J., Ott, J., and Schierl, T., "Source-Specific Media
Attributes in the Session Description Protocol (SDP)", RFC Attributes in the Session Description Protocol (SDP)", RFC
5576, June 2009. 5576, June 2009.
17.2. Informative References 17.2. Informative References
 End of changes. 12 change blocks. 
19 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/