draft-ietf-avt-rtp-rfc3984bis-08.txt   draft-ietf-avt-rtp-rfc3984bis-09.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: March 2010 Self-employed Expires: August 2010 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
R. Jesup R. Jesup
WorldGate Communications WorldGate Communications
September 21, 2009 February 12, 2010
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-08.txt draft-ietf-avt-rtp-rfc3984bis-09.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. This document may contain the provisions of BCP 78 and BCP 79.
material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in
such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than
English.
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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
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 March 21, 2009. This Internet-Draft will expire on August 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your publication of this document. Please review these documents
rights and restrictions with respect to this document. Code carefully, as they describe your rights and restrictions with
Components extracted from this document must include Simplified BSD respect to this document. Code Components extracted from this
License text as described in Section 4.e of the Trust Legal document must include Simplified BSD License text as described in
Provisions and are provided without warranty as described in the Section 4.e of the Trust Legal Provisions and are provided without
BSD License. warranty as described in the BSD License.
Abstract Abstract
This memo describes an RTP Payload format for the ITU-T This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec, excluding the ISO/IEC International Standard 14496-10 video codec, excluding the
Scalable Video Coding (SVC) extension and the Multivew Video Coding Scalable Video Coding (SVC) extension and the Multivew Video Coding
extension, for which the RTP payload formats are defined elsewhere. extension, for which the RTP payload formats are defined elsewhere.
The RTP payload format allows for packetization of one or more The RTP payload format allows for packetization of one or more
Network Abstraction Layer Units (NALUs), produced by an H.264 video Network Abstraction Layer Units (NALUs), produced by an H.264 video
encoder, in each RTP payload. The payload format has wide encoder, in each RTP payload. The payload format has wide
applicability, as it supports applications from simple low bit-rate applicability, as it supports applications from simple low bit-rate
conversational usage, to Internet video streaming with interleaved conversational usage, to Internet video streaming with interleaved
transmission, to high bit-rate video-on-demand. transmission, to high bit-rate video-on-demand.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized
in section 18. Issues on backward compatibility to RFC 3984 are in section 15. Issues on backward compatibility to RFC 3984 are
discussed in section 17. discussed in section 14.
Table of Contents Table of Contents
Abstract.........................................................2 Table of Contents................................................2
1. Introduction..................................................5 1. Introduction..................................................4
1.1. The H.264 Codec..........................................5 1.1. The H.264 Codec..........................................4
1.2. Parameter Set Concept....................................6 1.2. Parameter Set Concept....................................6
1.3. Network Abstraction Layer Unit Types.....................7 1.3. Network Abstraction Layer Unit Types.....................6
2. Conventions...................................................8 2. Conventions...................................................7
3. Scope.........................................................8 3. Scope.........................................................8
4. Definitions and Abbreviations.................................8 4. Definitions and Abbreviations.................................8
4.1. Definitions..............................................8 4.1. Definitions..............................................8
4.2. Abbreviations...........................................10 4.2. Abbreviations...........................................10
5. RTP Payload Format...........................................11 5. RTP Payload Format...........................................11
5.1. RTP Header Usage........................................11 5.1. RTP Header Usage........................................11
5.2. Payload Structures......................................13 5.2. Payload Structures......................................13
5.3. NAL Unit Header Usage...................................15 5.3. NAL Unit Header Usage...................................14
5.4. Packetization Modes.....................................17 5.4. Packetization Modes.....................................16
5.5. Decoding Order Number (DON).............................19 5.5. Decoding Order Number (DON).............................18
5.6. Single NAL Unit Packet..................................21 5.6. Single NAL Unit Packet..................................20
5.7. Aggregation Packets.....................................22 5.7. Aggregation Packets.....................................21
Table 4. Type field for STAPs and MTAPs........................23 Table 4. Type field for STAPs and MTAPs........................22
5.7.1. Single-Time Aggregation Packet.....................24 5.7.1. Single-Time Aggregation Packet.....................23
5.7.2. Multi-Time Aggregation Packets (MTAPs).............26 5.7.2. Multi-Time Aggregation Packets (MTAPs).............26
5.7.3. Fragmentation Units (FUs)..........................30 5.7.3. Fragmentation Units (FUs)..........................29
6. Packetization Rules..........................................34 6. Packetization Rules..........................................33
6.1. Common Packetization Rules..............................34 6.1. Common Packetization Rules..............................33
6.2. Single NAL Unit Mode....................................35 6.2. Single NAL Unit Mode....................................34
6.3. Non-Interleaved Mode....................................35 6.3. Non-Interleaved Mode....................................34
6.4. Interleaved Mode........................................36 6.4. Interleaved Mode........................................35
7. De-Packetization Process.....................................36 7. De-Packetization Process.....................................35
7.1. Single NAL Unit and Non-Interleaved Mode................36 7.1. Single NAL Unit and Non-Interleaved Mode................35
7.2. Interleaved Mode........................................37 7.2. Interleaved Mode........................................36
7.2.1. Size of the De-interleaving Buffer.................37 7.2.1. Size of the De-interleaving Buffer.................36
7.2.2. De-interleaving Process............................38 7.2.2. De-interleaving Process............................37
7.3. Additional De-Packetization Guidelines..................39 7.3. Additional De-Packetization Guidelines..................38
8. Payload Format Parameters....................................40 8. Payload Format Parameters....................................39
8.1. Media Type Registration.................................40 8.1. Media Type Registration.................................39
8.2. SDP Parameters..........................................59 8.2. SDP Parameters..........................................57
8.2.1. Mapping of Payload Type Parameters to SDP..........59 8.2.1. Mapping of Payload Type Parameters to SDP..........57
8.2.2. Usage with the SDP Offer/Answer Model..............60 8.2.2. Usage with the SDP Offer/Answer Model..............59
8.2.3. Usage in Declarative Session Descriptions..........69 8.2.3. Usage in Declarative Session Descriptions..........68
8.3. Examples................................................71 8.3. Examples................................................70
Offer SDP:......................................................76 Offer SDP:......................................................75
Answer SDP:.....................................................77 Answer SDP:.....................................................76
8.4. Parameter Set Considerations............................78 8.4. Parameter Set Considerations............................77
8.5. Decoder Refresh Point Procedure using In-Band Transport of 8.5. Decoder Refresh Point Procedure using In-Band Transport of
Parameter Sets (Informative).................................81 Parameter Sets (Informative).................................80
8.5.1. IDR Procedure to Respond to a Request for a Decoder 8.5.1. IDR Procedure to Respond to a Request for a Decoder
Refresh Point.............................................81 Refresh Point.............................................80
8.5.2. Gradual Recovery Procedure to Respond to a Request for 8.5.2. Gradual Recovery Procedure to Respond to a Request for
a Decoder Refresh Point...................................82 a Decoder Refresh Point...................................81
9. Security Considerations......................................82 9. Security Considerations......................................81
10. Congestion Control..........................................83 10. Congestion Control..........................................82
11. IANA Consideration..........................................84 11. IANA Consideration..........................................83
12. Informative Appendix: Application Examples..................84 12. Informative Appendix: Application Examples..................83
12.1. Video Telephony according to ITU-T Recommendation H.241 12.1. Video Telephony according to ITU-T Recommendation H.241
Annex A......................................................84 Annex A......................................................83
12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit 12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit
Aggregation..................................................85 Aggregation..................................................84
12.3. Video Telephony, Interleaved Packetization Using NAL Unit 12.3. Video Telephony, Interleaved Packetization Using NAL Unit
Aggregation..................................................85 Aggregation..................................................84
12.4. Video Telephony with Data Partitioning.................86 12.4. Video Telephony with Data Partitioning.................85
12.5. Video Telephony or Streaming with FUs and Forward Error 12.5. Video Telephony or Streaming with FUs and Forward Error
Correction...................................................86 Correction...................................................85
12.6. Low Bit-Rate Streaming.................................89 12.6. Low Bit-Rate Streaming.................................88
12.7. Robust Packet Scheduling in Video Streaming............90 12.7. Robust Packet Scheduling in Video Streaming............89
13. Informative Appendix: Rationale for Decoding Order Number...91 13. Informative Appendix: Rationale for Decoding Order Number...90
13.1. Introduction...........................................91 13.1. Introduction...........................................90
13.2. Example of Multi-Picture Slice Interleaving............91 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..................97 13.5. Remarks on Other Design Possibilities..................96
14. Acknowledgements............................................98 14. Backward Compatibility to RFC 3984..........................97
15. References..................................................98 15. Changes from RFC 3984.......................................98
15.1. Normative References...................................98 16. Acknowledgements...........................................100
15.2. Informative References.................................99 17. References.................................................101
16. Authors' Addresses.........................................101 17.1. Normative References..................................101
Phone: +1-908-541-3518.........................................101 17.2. Informative References................................101
Phone: +972-545481099..........................................101 18. Authors' Addresses.........................................103
Tom Kristensen.................................................101
Phone: +47 67125125............................................101
Phone: +1-215-354-5166.........................................101
Email: rjesup@wgate.com........................................101
17. Backward Compatibility to RFC 3984.........................101
18. Changes from RFC 3984......................................103
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.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized
in section 18. Issues on backward compatibility to RFC 3984 are in section 15. Issues on backward compatibility to RFC 3984 are
discussed in section 17. discussed in section 14.
1.1. The H.264 Codec 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 29 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.2. Parameter Set Concept 1.1. 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 7, line 19 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.3. Network Abstraction Layer Unit Types 1.2. 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 18, line 42 skipping to change at page 17, line 47
Some NAL unit or payload type values (indicated as reserved in Some NAL unit or payload type values (indicated as reserved in
Table 3) are reserved for future extensions. NAL units of those Table 3) are reserved for future extensions. NAL units of those
types SHOULD NOT be sent by a sender (direct as packet payloads, or types SHOULD NOT be sent by a sender (direct as packet payloads, or
as aggregation units in aggregation packets, or as fragmented units as aggregation units in aggregation packets, or as fragmented units
in FU packets) and MUST be ignored by a receiver. For example, the in FU packets) and MUST be ignored by a receiver. For example, the
payload types 1-23, with the associated packet type "NAL unit", are payload types 1-23, with the associated packet type "NAL unit", are
allowed in "Single NAL Unit Mode" and in "Non-Interleaved Mode", allowed in "Single NAL Unit Mode" and in "Non-Interleaved Mode",
but disallowed in "Interleaved Mode". However, NAL units of NAL but disallowed in "Interleaved Mode". However, NAL units of NAL
unit types 1-23 can be used in "Interleaved Mode" as aggregation unit types 1-23 can be used in "Interleaved Mode" as aggregation
units in STAP-B, MTAP16 and MTAP14 packets as well as fragmented units in STAP-B, MTAP16 and MTAP24 packets as well as fragmented
units in FU-A and FU-B packets. Similarly, NAL units of NAL unit units in FU-A and FU-B packets. Similarly, NAL units of NAL unit
types 1-23 can also be used in the "Non-Interleaved Mode" as types 1-23 can also be used in the "Non-Interleaved Mode" as
aggregation units in STAP-A packets or fragmented units in FU-A aggregation units in STAP-A packets or fragmented units in FU-A
packets, in addition to being directly used as packet payloads. packets, in addition to being directly used as packet payloads.
5.5. Decoding Order Number (DON) 5.5. Decoding Order Number (DON)
In the interleaved packetization mode, the transmission order of In the interleaved packetization mode, the transmission order of
NAL units is allowed to differ from the decoding order of the NAL NAL units is allowed to differ from the decoding order of the NAL
units. Decoding order number (DON) is a field in the payload units. Decoding order number (DON) is a field in the payload
skipping to change at page 40, line 38 skipping to change at page 39, line 38
A mapping of the parameters into the Session Description Protocol A mapping of the parameters into the Session Description Protocol
(SDP) [6] is also provided for applications that use SDP. (SDP) [6] is also provided for applications that use SDP.
Equivalent parameters could be defined elsewhere for use with Equivalent parameters could be defined elsewhere for use with
control protocols that do not use SDP. control protocols that do not use SDP.
Some parameters provide a receiver with the properties of the Some parameters provide a receiver with the properties of the
stream that will be sent. The names of all these parameters start stream that will be sent. The names of all these parameters start
with "sprop" for stream properties. Some of these "sprop" with "sprop" for stream properties. Some of these "sprop"
parameters are limited by other payload or codec configuration parameters are limited by other payload or codec configuration
parameters. For example, the sprop-parameter-sets parameter is parameters. For example, the sprop-parameter-sets parameter is
constrained by the profile-level-id parameter. The media sender constrained by the profile-level-id parameter.
selects all "sprop" parameters rather than the receiver. This
uncommon characteristic of the "sprop" parameters may not be
compatible with some signaling protocol concepts, in which case the
use of these parameters SHOULD be avoided.
8.1. Media Type Registration 8.1. Media Type Registration
The media subtype for the ITU-T H.264 | ISO/IEC 14496-10 codec is The media subtype for the ITU-T H.264 | ISO/IEC 14496-10 codec is
allocated from the IETF tree. allocated from the IETF tree.
The receiver MUST ignore any unspecified parameter.
Media Type name: video Media Type name: video
Media subtype name: H264 Media subtype name: H264
Required parameters: none Required parameters: none
OPTIONAL parameters: OPTIONAL parameters:
profile-level-id: profile-level-id:
A base16 [7] (hexadecimal) representation of the following A base16 [7] (hexadecimal) representation of the following
three bytes in the sequence parameter set NAL unit specified three bytes in the sequence parameter set NAL unit specified
in [1]: 1) profile_idc, 2) a byte herein referred to as in [1]: 1) profile_idc, 2) a byte herein referred to as
profile-iop, composed of the values of constraint_set0_flag, profile-iop, composed of the values of constraint_set0_flag,
constraint_set1_flag,constraint_set2_flag, constraint_set1_flag,constraint_set2_flag,
constraint_set3_flag, and reserved_zero_4bits in bit- constraint_set3_flag, and reserved_zero_4bits in bit-
significance order, starting from the most significant bit, significance order, starting from the most significant bit,
skipping to change at page 42, line 50 skipping to change at page 41, line 50
For example, in the table above, profile_idc equal to 58 For example, in the table above, profile_idc equal to 58
(Extended) with profile-iop equal to 11xx0000 indicates the (Extended) with profile-iop equal to 11xx0000 indicates the
same sub-profile corresponding to profile_idc equal to 42 same sub-profile corresponding to profile_idc equal to 42
(Baseline) with profile-iop equal to x1xx0000. Note that (Baseline) with profile-iop equal to x1xx0000. Note that
other combinations of profile_idc and profile-iop (not listed other combinations of profile_idc and profile-iop (not listed
in Table 5) may represent a sub-profile equivalent to the in Table 5) may represent a sub-profile equivalent to the
common subset of coding tools for more than one profile. common subset of coding tools for more than one profile.
Note also that a decoder conforming to a certain profile may Note also that a decoder conforming to a certain profile may
be able to decode bitstreams conforming to other profiles. be able to decode bitstreams conforming to other profiles.
For example, a decoder conforming to the High 4:4:4 profile For example, a decoder conforming to the High 4:4:4 profile
at certain level must be able to decode bitstreams confirming at certain level must be able to decode bitstreams conforming
to the Constrained Baseline, Main, High, High 10 or High to the Constrained Baseline, Main, High, High 10 or High
4:2:2 profile at the same or a lower level. 4:2:2 profile at the same or a lower level.
If the profile-level-id parameter is used to indicate If the profile-level-id parameter is used to indicate
properties of a NAL unit stream, it indicates that, to decode properties of a NAL unit stream, it indicates that, to decode
the stream, the minimum subset of coding tools a decoder has the stream, the minimum subset of coding tools a decoder has
to support is the default sub-profile, and the lowest level to support is the default sub-profile, and the lowest level
the decoder has to support is the default level. the decoder has to support is the default level.
If the profile-level-id parameter is used for capability If the profile-level-id parameter is used for capability
skipping to change at page 52, line 27 skipping to change at page 51, line 27
still choose to send parameter sets in-band. When in-band- still choose to send parameter sets in-band. When in-band-
parameter-sets is equal to 1, use-level-src-parameter-sets parameter-sets is equal to 1, use-level-src-parameter-sets
MUST NOT be present or MUST be equal to 0. When the MUST NOT be present or MUST be equal to 0. When the
parameter is not present, this receiver capability is not parameter is not present, this receiver capability is not
specified, and therefore the sender MAY send out-of-band specified, and therefore the sender MAY send out-of-band
parameter sets only, or it MAY send in-band-parameter-sets parameter sets only, or it MAY send in-band-parameter-sets
only, or it MAY send both. only, or it MAY send both.
level-asymmetry-allowed: level-asymmetry-allowed:
This parameter MAY be used in SDP Offer/Answer to indicate This parameter MAY be used in SDP Offer/Answer to indicate
whether level asymmetry, i.e., using a different level in the whether level asymmetry, i.e., sending media encoded at a
offerer-to-answerer direction than the level in the answerer- different level in the offerer-to-answerer direction than the
to-offerer direction, is allowed. The value MAY be equal to level in the answerer-to-offerer direction, is allowed. The
either 0 or 1. When the parameter is not present, the value value MAY be equal to either 0 or 1. When the parameter is
MUST be inferred to be equal to 0. The value 1 in both the not present, the value MUST be inferred to be equal to 0.
offer and the answer indicates that level asymmetry is The value 1 in both the offer and the answer indicates that
allowed. The value of 0 in either the offer or the answer level asymmetry is allowed. The value of 0 in either the
indicates the level asymmetry is not allowed. offer or the answer indicates the level asymmetry is not
allowed.
If "level-asymmetry-allowed" is equal to 0 (or not present) If "level-asymmetry-allowed" is equal to 0 (or not present)
in either the offer or the answer, level asymmetry is not in either the offer or the answer, level asymmetry is not
allowed. In this case, the level to use in the direction allowed. In this case, the level to use in the direction
from the offerer to the answerer MUST be the same as the from the offerer to the answerer MUST be the same as the
level to use in the opposite direction. level to use in the opposite direction.
packetization-mode: packetization-mode:
This parameter signals the properties of an RTP payload type This parameter signals the properties of an RTP payload type
or the capabilities of a receiver implementation. Only a or the capabilities of a receiver implementation. Only a
single configuration point can be indicated; thus, when single configuration point can be indicated; thus, when
capabilities to support more than one packetization-mode are capabilities to support more than one packetization-mode are
declared, multiple configuration points (RTP payload types) declared, multiple configuration points (RTP payload types)
must be used. must be used.
When the value of packetization-mode is equal to 0 or When the value of packetization-mode is equal to 0 or
packetization-mode is not present, the single NAL mode, as packetization-mode is not present, the single NAL mode MUST
defined in section 6.2 of RFC 3984, MUST be used. This mode be used. This mode is in use in standards using ITU-T
is in use in standards using ITU-T Recommendation H.241 [3] Recommendation H.241 [3] (see section 12.1). When the value
(see section 12.1). When the value of packetization-mode is of packetization-mode is equal to 1, the non-interleaved mode
equal to 1, the non-interleaved mode, as defined in section MUST be used. When the value of packetization-mode is equal
6.3 of RFC 3984, MUST be used. When the value of to 2, the interleaved mode MUST be used. The value of
packetization-mode is equal to 2, the interleaved mode, as packetization-mode MUST be an integer in the range of 0 to 2,
defined in section 6.4 of RFC 3984, MUST be used. The value inclusive.
of packetization-mode MUST be an integer in the range of 0 to
2, inclusive.
sprop-interleaving-depth: sprop-interleaving-depth:
This parameter MUST NOT be present when packetization-mode is This parameter MUST NOT be present when packetization-mode is
not present or the value of packetization-mode is equal to 0 not present or the value of packetization-mode is equal to 0
or 1. This parameter MUST be present when the value of or 1. This parameter MUST be present when the value of
packetization-mode is equal to 2. packetization-mode is equal to 2.
This parameter signals the properties of an RTP packet stream. This parameter signals the properties of an RTP packet stream.
It specifies the maximum number of VCL NAL units that precede It specifies the maximum number of VCL NAL units that precede
any VCL NAL unit in the RTP packet stream in transmission any VCL NAL unit in the RTP packet stream in transmission
skipping to change at page 53, line 45 skipping to change at page 52, line 43
sprop-deint-buf-req: sprop-deint-buf-req:
This parameter MUST NOT be present when packetization-mode is This parameter MUST NOT be present when packetization-mode is
not present or the value of packetization-mode is equal to 0 not present or the value of packetization-mode is equal to 0
or 1. It MUST be present when the value of packetization- or 1. It MUST be present when the value of packetization-
mode is equal to 2. mode is equal to 2.
sprop-deint-buf-req signals the required size of the de- sprop-deint-buf-req signals the required size of the de-
interleaving buffer for the RTP packet stream. The value of interleaving buffer for the RTP packet stream. The value of
the parameter MUST be greater than or equal to the maximum the parameter MUST be greater than or equal to the maximum
buffer occupancy (in units of bytes) required in such a de- buffer occupancy (in units of bytes) required in such a de-
interleaving buffer that is specified in section 7.2 of RFC interleaving buffer that is specified in section 7.2. It is
3984. It is guaranteed that receivers can perform the de- guaranteed that receivers can perform the de-interleaving of
interleaving of interleaved NAL units into NAL unit decoding interleaved NAL units into NAL unit decoding order, when the
order, when the de-interleaving buffer size is at least the de-interleaving buffer size is at least the value of sprop-
value of sprop-deint-buf-req in terms of bytes. deint-buf-req in terms of bytes.
The value of sprop-deint-buf-req MUST be an integer in the The value of sprop-deint-buf-req MUST be an integer in the
range of 0 to 4294967295, inclusive. range of 0 to 4294967295, inclusive.
Informative note: sprop-deint-buf-req indicates the Informative note: sprop-deint-buf-req indicates the
required size of the de-interleaving buffer only. When required size of the de-interleaving buffer only. When
network jitter can occur, an appropriately sized jitter network jitter can occur, an appropriately sized jitter
buffer has to be provisioned for as well. buffer has to be provisioned for as well.
deint-buf-cap: deint-buf-cap:
skipping to change at page 56, line 23 skipping to change at page 55, line 21
AbsDON(n) = AbsDON(m) + 65536 - DON(m) + DON(n) AbsDON(n) = AbsDON(m) + 65536 - DON(m) + DON(n)
If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768), If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768),
AbsDON(n) = AbsDON(m) - (DON(m) + 65536 - DON(n)) AbsDON(n) = AbsDON(m) - (DON(m) + 65536 - DON(n))
If (DON(m) > DON(n) and DON(m) - DON(n) < 32768), If (DON(m) > DON(n) and DON(m) - DON(n) < 32768),
AbsDON(n) = AbsDON(m) - (DON(m) - DON(n)) AbsDON(n) = AbsDON(m) - (DON(m) - DON(n))
where DON(i) is the decoding order number of the NAL unit where DON(i) is the decoding order number of the NAL unit
having index i in the transmission order. The decoding order having index i in the transmission order. The decoding order
number is specified in section 5.5 of RFC 3984. number is specified in section 5.5.
Informative note: Receivers may use sprop-max-don-diff to Informative note: Receivers may use sprop-max-don-diff to
trigger which NAL units in the receiver buffer can be trigger which NAL units in the receiver buffer can be
passed to the decoder. passed to the decoder.
max-rcmd-nalu-size: max-rcmd-nalu-size:
This parameter MAY be used to signal the capabilities of a This parameter MAY be used to signal the capabilities of a
receiver. The parameter MUST NOT be used for any other receiver. The parameter MUST NOT be used for any other
purposes. The value of the parameter indicates the largest purposes. The value of the parameter indicates the largest
NALU size in bytes that the receiver can handle efficiently. NALU size in bytes that the receiver can handle efficiently.
skipping to change at page 59, line 7 skipping to change at page 57, line 46
Author: Author:
Ye-Kui Wang, yekuiwang@huawei.com Ye-Kui Wang, yekuiwang@huawei.com
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IETF Audio/Video Transport working group delegated from the
IESG. IESG.
8.2. SDP Parameters 8.2. SDP Parameters
The receiver MUST ignore any parameter unspecified in this memo.
8.2.1. Mapping of Payload Type Parameters to SDP 8.2.1. Mapping of Payload Type Parameters to SDP
The media type video/H264 string is mapped to fields in the Session The media type video/H264 string is mapped to fields in the Session
Description Protocol (SDP) [6] as follows: Description Protocol (SDP) [6] as follows:
o The media name in the "m=" line of SDP MUST be video. o The media name in the "m=" line of SDP MUST be video.
o The encoding name in the "a=rtpmap" line of SDP MUST be H264 o The encoding name in the "a=rtpmap" line of SDP MUST be H264
(the media subtype). (the media subtype).
skipping to change at page 98, line 9 skipping to change at page 97, line 20
The RTP payload format for transport of MPEG-4 elementary streams The RTP payload format for transport of MPEG-4 elementary streams
[25] enables interleaving of access units and transmission of [25] enables interleaving of access units and transmission of
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. Acknowledgements 14. Backward Compatibility to RFC 3984
The current document is a revision of RFC 3984 and obsoletes it.
This section addresses the backward compatibility issues.
The technical changes are listed in section 15.
Items 1), 2), 3), 7), 9), 10), 12) and 13) are bug-fix type of
changes, and do not incur any backward compatibility issues.
Item 4), addition of six new media type parameters, does not incur
any backward compatibility issues for SDP Offer/Answer based
applications, as legacy RFC 3984 receivers ignore these parameters,
and it is fine for legacy RFC 3984 senders not to use these
parameters as they are optional. However, there is a backward
compatibility issue for SDP declarative usage based applications,
e.g. those using RTSP and SAP, because the SDP receiver per RFC
3984 cannot accept a session for which the SDP includes an
unrecognized 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
parameter sets. There are following backward compatibility issues.
1) When a legacy sender per RFC 3984 includes parameter sets for a
level different than the default level indicated by profile-
level-id to sprop-parameter-sets, the parameter value of sprop-
parameter-sets is invalid to the receiver per this memo and
therefore the session may be rejected.
2) In SDP Offer/Answer between a legacy offerer per RFC 3984 and an
answerer per this memo, when the answerer includes in the answer
parameter sets that are not a superset of the parameter sets
included in the offer, the parameter value of sprop-parameter-
sets is invalid to the offerer and the session may not be
initiated properly (related to change item 11).
3) When one endpoint A per this memo includes in-band-parameter-
sets equal to 1, the other side B per RFC 3984 does not
understand that it must transmit parameter sets in-band and B
may still exclude parameter sets in the in-band stream it is
sending. Consequently endpoint A cannot decode the stream it
receives.
Item7), allowance of conveying sprop-parameter-sets and sprop-
level-parameter-sets using the "fmtp" source attribute as specified
in section 6.3 of [9], is similar as item 4). It does not incur
any backward compatibility issues for SDP Offer/Answer based
applications, as legacy RFC 3984 receivers ignore the "fmtp" source
attribute, and it is fine for legacy RFC 3984 senders not to use
the "fmtp" source attribute as it is optional. However, there is a
backward compatibility issue for SDP declarative usage based
applications, e.g. those using RTSP and SAP, because the SDP
receiver per RFC 3984 cannot accept a session for which the SDP
includes an unrecognized parameter (i.e., the "fmtp" source
attribute). 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.
Item 14) removed that use of out-of-band transport of parameter
sets is recommended. As out-of-band transport of parameter sets is
still allowed, this change does not incur any backward
compatibility issues.
Item 15) does not incur any backward compatibility issues as the
added subsection 8.5 is informative.
Item 16) does not create any backward compatibility issues as the
handling of default level is the same if either end is RFC 3984
compliant, and furthermore, RFC 3984 compliant ends would simply
ignore the new media type parameters, if present.
15. Changes from RFC 3984
Following is the list of technical changes (including bug fixes)
from RFC 3984. Besides this list of technical changes, numerous
editorial changes have been made, but not documented in this
section. Note that section 8.2.2 is where much of the important
changes in this memo occurs and deserves particular attention.
1) In subsections 5.4, 5.5, 6.2, 6,3 and 6.4, removed that the
packetization mode in use may be signaled by external means.
2) In subsection 7.2.2, changed the sentence
There are N VCL NAL units in the deinterleaving buffer.
to
There are N or more VCL NAL units in the de-interleaving buffer.
3) In subsection 8.1, the semantics of sprop-init-buf-time,
paragraph 2, changed the sentence
The parameter is the maximum value of (transmission time of a
NAL unit - decoding time of the NAL unit), assuming reliable and
instantaneous transmission, the same timeline for transmission
and decoding, and that decoding starts when the first packet
arrives.
to
The parameter is the maximum value of (decoding time of the NAL
unit - transmission time of a NAL unit), assuming reliable and
instantaneous transmission, the same timeline for transmission
and decoding, and that decoding starts when the first packet
arrives.
4) Added media type parameters max-smbps, sprop-level-parameter-
sets, use-level-src-parameter-sets, in-band-parameter-sets, sar-
understood and sar-supported.
5) In subsection 8.1, removed the specification of parameter-add.
Other descriptions of parameter-add (in subsections 8.2 and 8.4)
are also removed.
6) In subsection 8.1, added a constraint to sprop-parameter-sets
such that it can only contain parameter sets for the same
profile and level as indicated by profile-level-id.
7) In subsection 8.2.1, added that sprop-parameter-sets and sprop-
level-parameter-sets may be either included in the "a=fmtp" line
of SDP or conveyed using the "fmtp" source attribute as
specified in section 6.3 of [9].
8) In subsection 8.2.2, removed sprop-deint-buf-req from being part
of the media format configuration in usage with the SDP
Offer/Answer model.
9) In subsection 8.2.2, made it clear that level is downgradable in
the SDP Offer/Answer model, i.e. the use of the level part of
"profile-level-id" does not need to be symmetric (the level
included in the answer can be lower than or equal to the level
included in the offer).
10)In subsection 8.2.2, removed that the capability parameters may
be used to declare encoding capabilities.
11)In subsection 8.2.2, added rules on how to use sprop-parameter-
sets and sprop-level-parameter-sets for out-of-band transport of
parameter sets, with or without level downgrading.
12)In subsection 8.2.2, clarified the rules of using the media type
parameters with SDP Offer/Answer for multicast.
13)In subsection 8.2.2, completed and corrected the list of how
different media type parameters shall be interpreted in the
different combinations of offer or answer and direction
attribute.
14)In subsection 8.4, changed the text such that both out-of-band
and in-band transport of parameter sets are allowed and neither
is recommended or required.
15)Added subsection 8.5 (informative) providing example methods for
decoder refresh to handle parameter set losses.
16)Added media type parameters max-recv-level, and level-asymmetry-
allowed, and adjusted associated text and examples for level
upgrade and asymmetry.
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. Randell Jesup, Stephen Botzko, Magnus the development of RFC 3984. Stephen Botzko, Magnus Westerlund,
Westerlund, Alex Eleftheriadis, Thomas Schierl, Tom Taylor, Ali Alex Eleftheriadis, Thomas Schierl, Tom Taylor, Ali Begen, Aaron
Begen, and Aaron Wells are thanked for their valuable comments and Wells, Stuart Taylor, and Robert Sparks are thanked for their
inputs during the development of this memo. 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.
15. References 17. References
15.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.
[2] ISO/IEC International Standard 14496-10:2008. [2] ISO/IEC International Standard 14496-10:2008.
[3] ITU-T Recommendation H.241, "Extended video procedures and [3] ITU-T Recommendation H.241, "Extended video procedures and
control signals for H.300 series terminals", May 2006. control signals for H.300 series terminals", May 2006.
[4] Bradner, S., "Key words for use in RFCs to Indicate [4] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 99, line 9 skipping to change at page 101, line 42
[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 3548, July 2003.
[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.
15.2. Informative References 17.2. Informative References
[10] Luthra, A., Sullivan, G.J., and T. Wiegand (eds.), Special [10] Luthra, A., Sullivan, G.J., and T. Wiegand (eds.), Special
Issue on H.264/AVC. IEEE Transactions on Circuits and Systems Issue on H.264/AVC. IEEE Transactions on Circuits and Systems
on Video Technology, July 2003. on Video Technology, July 2003.
[11] Ott, J., Bormann, C., Sullivan, G., Wenger, S., and R. Even [11] Ott, J., Bormann, C., Sullivan, G., Wenger, S., and R. Even
(Ed.), "RTP Payload Format for ITU-T Rec. H.263 Video", RFC (Ed.), "RTP Payload Format for ITU-T Rec. H.263 Video", RFC
4629, January 2007. 4629, January 2007.
[12] ISO/IEC IS 14496-2. [12] ISO/IEC IS 14496-2.
skipping to change at page 101, line 5 skipping to change at page 103, line 31
[28] Handley, M., Perkins, C., and E. Whelan, "Session [28] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[29] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, [29] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[30] Wenger, S., Chandra, U., and M. Westerlund, "Codec Control [30] Wenger, S., Chandra, U., and M. Westerlund, "Codec Control
Messages in the RTP Audio-Visual Profile with Feedback Messages in the RTP Audio-Visual Profile with Feedback
(AVPF)", RFC 5104, February 2008. (AVPF)", RFC 5104, February 2008.
16. Authors' Addresses 18. Authors' Addresses
Ye-Kui Wang Ye-Kui Wang
Huawei Technologies Huawei Technologies
400 Somerset Corp Blvd, Suite 602 400 Somerset Corp Blvd, Suite 602
Bridgewater, NJ 08807 Bridgewater, NJ 08807
USA USA
Phone: +1-908-541-3518 Phone: +1-908-541-3518
EMail: yekuiwang@huawei.com EMail: yekuiwang@huawei.com
skipping to change at page 101, line 41 skipping to change at line 4633
Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no
Randell Jesup Randell Jesup
WorldGate Communications WorldGate Communications
3190 Tremont Ave 3190 Tremont Ave
Trevose, PA 19053 Trevose, PA 19053
USA USA
Phone: +1-215-354-5166 Phone: +1-215-354-5166
Email: rjesup@wgate.com Email: rjesup@wgate.com
17. Backward Compatibility to RFC 3984
The current document is a revision of RFC 3984 and intends to
obsolete it. This section addresses the backward compatibility
issues.
The technical changes are listed in section 18.
Items 1), 2), 3), 7), 9), 10), 12), 13) are bug-fix type of changes,
and do not incur any backward compatibility issues.
Item 4), addition of six new media type parameters, does not incur
any backward compatibility issues for SDP Offer/Answer based
applications, as legacy RFC 3984 receivers ignore these parameters,
and it is fine for legacy RFC 3984 senders not to use these
parameters as they are optional. However, there is a backward
compatibility issue for SDP declarative usage based applications,
e.g. those using RTSP and SAP, because the SDP receiver per RFC
3984 cannot accept a session for which the SDP includes an
unrecognized 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
parameter sets. There are following backward compatibility issues.
1) When a legacy sender per RFC 3984 includes parameter sets for a
level different than the default level indicated by profile-
level-id to sprop-parameter-sets, the parameter value of sprop-
parameter-sets is invalid to the receiver per this memo and
therefore the session may be rejected.
2) In SDP Offer/Answer between a legacy offerer per RFC 3984 and an
answerer per this memo, when the answerer includes in the answer
parameter sets that are not a superset of the parameter sets
included in the offer, the parameter value of sprop-parameter-
sets is invalid to offerer and the session may not be initiated
properly (related to change item 11)).
3) When one endpoint A per this memo includes in-band-parameter-
sets equal to 1, the other side B per RFC 3984 does not
understand that it must transmit parameter sets in-band and B
may still exclude parameter sets in the in-band stream it is
sending. Consequently endpoint A cannot decode the stream it
receives.
Item 7), allowance of conveying sprop-parameter-sets and sprop-
level-parameter-sets using the "fmtp" source attribute as specified
in section 6.3 of [9], is similar as item 4). It does not incur
any backward compatibility issues for SDP Offer/Answer based
applications, as legacy RFC 3984 receivers ignore the "fmtp" source
attribute, and it is fine for legacy RFC 3984 senders not to use
the "fmtp" source attribute as it is optional. However, there is a
backward compatibility issue for SDP declarative usage based
applications, e.g. those using RTSP and SAP, because the SDP
receiver per RFC 3984 cannot accept a session for which the SDP
includes an unrecognized parameter (i.e., the "fmtp" source
attribute). 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.
Item 14) removed that use of out-of-band transport of parameter
sets is recommended. As out-of-band transport of parameter sets is
still allowed, this change does not incur any backward
compatibility issues.
Item 15) does not incur any backward compatibility issues as the
added subsection 8.5 is informative.
Item 16) does not create any backward compatibility issues as the
handling of default level is the same if either end is RFC 3984
compliant, and furthermore, RFC 3984 compliant ends would simply
ignore the new media type parameters, if present.
18. Changes from RFC 3984
Following is the list of technical changes (including bug fixes)
from RFC 3984. Besides this list of technical changes, numerous
editorial changes have been made, but not documented in this memo.
1) In subsections 5.4, 5.5, 6.2, 6,3 and 6.4, removed that the
packetization mode in use may be signaled by external means.
2) In subsection 7.2.2, changed the sentence
There are N VCL NAL units in the deinterleaving buffer.
to
There are N or more VCL NAL units in the de-interleaving buffer.
3) In subsection 8.1, the semantics of sprop-init-buf-time,
paragraph 2, changed the sentence
The parameter is the maximum value of (transmission time of a
NAL unit - decoding time of the NAL unit), assuming reliable and
instantaneous transmission, the same timeline for transmission
and decoding, and that decoding starts when the first packet
arrives.
to
The parameter is the maximum value of (decoding time of the NAL
unit - transmission time of a NAL unit), assuming reliable and
instantaneous transmission, the same timeline for transmission
and decoding, and that decoding starts when the first packet
arrives.
4) Added media type parameters max-smbps, sprop-level-parameter-
sets, use-level-src-parameter-sets, in-band-parameter-sets, sar-
understood and sar-supported.
5) In subsection 8.1, removed the specification of parameter-add.
Other descriptions of parameter-add (in subsections 8.2 and 8.4)
are also removed.
6) In subsection 8.1, added a constraint to sprop-parameter-sets
such that it can only contain parameter sets for the same
profile and level as indicated by profile-level-id.
7) In subsection 8.2.1, added that sprop-parameter-sets and sprop-
level-parameter-sets may be either included in the "a=fmtp" line
of SDP or conveyed using the "fmtp" source attribute as
specified in section 6.3 of [9].
8) In subsection 8.2.2, removed sprop-deint-buf-req from being part
of the media format configuration in usage with the SDP
Offer/Answer model.
9) In subsection 8.2.2, made it clear that level is downgradable in
the SDP Offer/Answer model, i.e. the use of the level part of
"profile-level-id" does not need to be symmetric (the level
included in the answer can be lower than or equal to the level
included in the offer).
10)In subsection 8.2.2, removed that the capability parameters may
be used to declare encoding capabilities.
11)In subsection 8.2.2, added rules on how to use sprop-parameter-
sets and sprop-level-parameter-sets for out-of-band transport of
parameter sets, with or without level downgrading.
12)In subsection 8.2.2, clarified the rules of using the media type
parameters with SDP Offer/Answer for multicast.
13)In subsection 8.2.2, completed and corrected the list of how
different media type parameters shall be interpreted in the
different combinations of offer or answer and direction
attribute.
14)In subsection 8.4, changed the text such that both out-of-band
and in-band transport of parameter sets are allowed and neither
is recommended or required.
15)Added subsection 8.5 (informative) providing example methods for
decoder refresh to handle parameter set losses.
16)Added media type parameters max-recv-level, and level-asymmetry-
allowed, and adjusted associated text and examples for level
upgrade and asymmetry.
 End of changes. 42 change blocks. 
141 lines changed or deleted 280 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/