draft-ietf-avt-rtp-rfc3984bis-09.txt   draft-ietf-avt-rtp-rfc3984bis-10.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: August 2010 Self-employed Expires: October 2010 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
R. Jesup R. Jesup
WorldGate Communications WorldGate Communications
February 12, 2010 April 4, 2010
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-09.txt draft-ietf-avt-rtp-rfc3984bis-10.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 August 12, 2010. This Internet-Draft will expire on October 4, 2010.
Copyright Notice Copyright 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
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized
in section 15. Issues on backward compatibility to RFC 3984 are in section 15. Issues on backward compatibility to RFC 3984 are
discussed in section 14. discussed in section 14.
The H.264 Codec 1.1. The H.264 Codec
The H.264 video codec has a very broad application range that The H.264 video codec has a very broad application range that
covers all forms of digital compressed video, from low bit-rate covers all forms of digital compressed video, from low bit-rate
Internet streaming applications to HDTV broadcast and Digital Internet streaming applications to HDTV broadcast and Digital
Cinema applications with nearly lossless coding. Compared to the Cinema applications with nearly lossless coding. Compared to the
current state of technology, the overall performance of H.264 is current state of technology, the overall performance of H.264 is
such that bit rate savings of 50% or more are reported. Digital such that bit rate savings of 50% or more are reported. Digital
Satellite TV quality, for example, was reported to be achievable at Satellite TV quality, for example, was reported to be achievable at
1.5 Mbit/s, compared to the current operation point of MPEG 2 video 1.5 Mbit/s, compared to the current operation point of MPEG 2 video
at around 3.5 Mbit/s [10]. at around 3.5 Mbit/s [10].
skipping to change at page 6, line 7 skipping to change at page 6, line 7
presentation time of slices and pictures. The decoding process presentation time of slices and pictures. The decoding process
specified in H.264 is unaware of time, and the H.264 syntax does specified in H.264 is unaware of time, and the H.264 syntax does
not carry information such as the number of skipped frames (as is not carry information such as the number of skipped frames (as is
common in the form of the Temporal Reference in earlier video common in the form of the Temporal Reference in earlier video
compression standards). Also, there are NAL units that affect many compression standards). Also, there are NAL units that affect many
pictures and that are, therefore, inherently timeless. For this pictures and that are, therefore, inherently timeless. For this
reason, the handling of the RTP timestamp requires some special reason, the handling of the RTP timestamp requires some special
considerations for NAL units for which the sampling or presentation considerations for NAL units for which the sampling or presentation
time is not defined or, at transmission time, unknown. time is not defined or, at transmission time, unknown.
1.1. Parameter Set Concept 1.2. Parameter Set Concept
One very fundamental design concept of H.264 is to generate self- One very fundamental design concept of H.264 is to generate self-
contained packets, to make mechanisms such as the header contained packets, to make mechanisms such as the header
duplication of RFC 4629 [11] or MPEG-4 Visual's Header Extension duplication of RFC 4629 [11] or MPEG-4 Visual's Header Extension
Code (HEC) [12] unnecessary. This was achieved by decoupling Code (HEC) [12] unnecessary. This was achieved by decoupling
information relevant to more than one slice from the media stream. information relevant to more than one slice from the media stream.
This higher layer meta information should be sent reliably, This higher layer meta information should be sent reliably,
asynchronously, and in advance from the RTP packet stream that asynchronously, and in advance from the RTP packet stream that
contains the slice packets. (Provisions for sending this contains the slice packets. (Provisions for sending this
information in-band are also available for applications that do not information in-band are also available for applications that do not
skipping to change at page 6, line 42 skipping to change at page 6, line 42
slice header contains a codeword that indicates the sequence and slice header contains a codeword that indicates the sequence and
picture parameter set to be used. picture parameter set to be used.
This mechanism allows the decoupling of the transmission of This mechanism allows the decoupling of the transmission of
parameter sets from the packet stream, and the transmission of them parameter sets from the packet stream, and the transmission of them
by external means (e.g., as a side effect of the capability by external means (e.g., as a side effect of the capability
exchange), or through a (reliable or unreliable) control protocol. exchange), or through a (reliable or unreliable) control protocol.
It may even be possible that they are never transmitted but are It may even be possible that they are never transmitted but are
fixed by an application design specification. fixed by an application design specification.
1.2. Network Abstraction Layer Unit Types 1.3. Network Abstraction Layer Unit Types
Tutorial information on the NAL design can be found in [13], [14], Tutorial information on the NAL design can be found in [13], [14],
and [15]. and [15].
All NAL units consist of a single NAL unit type octet, which also All NAL units consist of a single NAL unit type octet, which also
co-serves as the payload header of this RTP payload format. The co-serves as the payload header of this RTP payload format. The
payload of a NAL unit follows immediately. payload of a NAL unit follows immediately.
The syntax and semantics of the NAL unit type octet are specified The syntax and semantics of the NAL unit type octet are specified
in [1], but the essential properties of the NAL unit type octet are in [1], but the essential properties of the NAL unit type octet are
skipping to change at page 68, line 7 skipping to change at page 68, line 7
S: out-of-band parameter sets S: out-of-band parameter sets
-: not usable, when present SHOULD be ignored -: not usable, when present SHOULD be ignored
Parameters used for declaring receiver capabilities are in general Parameters used for declaring receiver capabilities are in general
downgradable; i.e., they express the upper limit for a sender's downgradable; i.e., they express the upper limit for a sender's
possible behavior. Thus a sender MAY select to set its encoder possible behavior. Thus a sender MAY select to set its encoder
using only lower/less or equal values of these parameters. using only lower/less or equal values of these parameters.
Parameters declaring a configuration point are not changeable, with Parameters declaring a configuration point are not changeable, with
the exception of the level part of the "profile-level-id" parameter the exception of the level part of the "profile-level-id" parameter
for unicast usage. This expresses values a receiver expects to be for unicast usage. These express values a receiver expects to be
used and must be used verbatim on the sender side. used and must be used verbatim on the sender side.
When a sender's capabilities are declared, and non-downgradable When a sender's capabilities are declared, and non-downgradable
parameters are used in this declaration, then these parameters parameters are used in this declaration, then these parameters
express a configuration that is acceptable for the sender to express a configuration that is acceptable for the sender to
receive streams. In order to achieve high interoperability levels, receive streams. In order to achieve high interoperability levels,
it is often advisable to offer multiple alternative configurations; it is often advisable to offer multiple alternative configurations;
e.g., for the packetization mode. It is impossible to offer e.g., for the packetization mode. It is impossible to offer
multiple configurations in a single payload type. Thus, when multiple configurations in a single payload type. Thus, when
multiple configuration offers are made, each offer requires its own multiple configuration offers are made, each offer requires its own
 End of changes. 8 change blocks. 
8 lines changed or deleted 8 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/