draft-ietf-avt-rtp-rfc3984bis-04.txt   draft-ietf-avt-rtp-rfc3984bis-05.txt 
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: September 2009 Self-employed Expires: October 2009 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
March 6, 2009 April 22, 2009
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-04.txt draft-ietf-avt-rtp-rfc3984bis-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain 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-Drafts. other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in 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 September 6, 2009. This Internet-Draft will expire on October 22, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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
skipping to change at page 2, line 31 skipping to change at page 2, line 42
discussed in section 17. discussed in section 17.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1. The H.264 Codec...........................................4 1.1. The H.264 Codec...........................................4
1.2. Parameter Set Concept.....................................5 1.2. Parameter Set Concept.....................................5
1.3. Network Abstraction Layer Unit Types......................6 1.3. Network Abstraction Layer Unit Types......................6
2. Conventions....................................................7 2. Conventions....................................................7
3. Scope..........................................................7 3. Scope..........................................................7
4. Definitions and Abbreviations..................................7 4. Definitions and Abbreviations..................................8
4.1. Definitions...............................................7 4.1. Definitions...............................................8
4.2. Abbreviations.............................................9 4.2. Abbreviations............................................10
5. RTP Payload Format............................................10 5. RTP Payload Format............................................10
5.1. RTP Header Usage.........................................10 5.1. RTP Header Usage.........................................10
5.2. Payload Structures.......................................12 5.2. Payload Structures.......................................13
5.3. NAL Unit Header Usage....................................14 5.3. NAL Unit Header Usage....................................14
5.4. Packetization Modes......................................16 5.4. Packetization Modes......................................17
5.5. Decoding Order Number (DON)..............................17 5.5. Decoding Order Number (DON)..............................18
5.6. Single NAL Unit Packet...................................20 5.6. Single NAL Unit Packet...................................20
5.7. Aggregation Packets......................................21 5.7. Aggregation Packets......................................21
5.7.1. Single-Time Aggregation Packet......................23 5.7.1. Single-Time Aggregation Packet......................23
5.7.2. Multi-Time Aggregation Packets (MTAPs)..............25 5.7.2. Multi-Time Aggregation Packets (MTAPs)..............25
5.7.3. Fragmentation Units (FUs)...........................29 5.7.3. Fragmentation Units (FUs)...........................29
6. Packetization Rules...........................................33 6. Packetization Rules...........................................33
6.1. Common Packetization Rules...............................33 6.1. Common Packetization Rules...............................33
6.2. Single NAL Unit Mode.....................................34 6.2. Single NAL Unit Mode.....................................34
6.3. Non-Interleaved Mode.....................................34 6.3. Non-Interleaved Mode.....................................34
6.4. Interleaved Mode.........................................34 6.4. Interleaved Mode.........................................34
skipping to change at page 5, line 37 skipping to change at page 5, line 47
standards). Also, there are NAL units that affect many pictures and standards). Also, there are NAL units that affect many pictures and
that are, therefore, inherently timeless. For this reason, the that are, therefore, inherently timeless. For this reason, the
handling of the RTP timestamp requires some special considerations handling of the RTP timestamp requires some special considerations
for NAL units for which the sampling or presentation time is not for NAL units for which the sampling or presentation time is not
defined or, at transmission time, unknown. defined or, at transmission time, unknown.
1.2. 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 duplication contained packets, to make mechanisms such as the header duplication
of RFC 2429 [11] or MPEG-4's Header Extension Code (HEC) [12] of RFC 2429 [11] or MPEG-4 Visual's Header Extension Code (HEC) [12]
unnecessary. This was achieved by decoupling information relevant to unnecessary. This was achieved by decoupling information relevant to
more than one slice from the media stream. This higher layer meta more than one slice from the media stream. This higher layer meta
information should be sent reliably, asynchronously, and in advance information should be sent reliably, asynchronously, and in advance
from the RTP packet stream that contains the slice packets. from the RTP packet stream that contains the slice packets.
(Provisions for sending this information in-band are also available (Provisions for sending this information in-band are also available
for applications that do not have an out-of-band transport channel for applications that do not have an out-of-band transport channel
appropriate for the purpose.) The combination of the higher-level appropriate for the purpose.) The combination of the higher-level
parameters is called a parameter set. The H.264 specification parameters is called a parameter set. The H.264 specification
includes two types of parameter sets: sequence parameter set and includes two types of parameter sets: sequence parameter set and
picture parameter set. An active sequence parameter set remains picture parameter set. An active sequence parameter set remains
skipping to change at page 17, line 38 skipping to change at page 18, line 7
30-31 reserved ig ig ig 30-31 reserved ig ig ig
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", but allowed in "Single NAL Unit Mode" and in "Non-Interleaved Mode", but
disallowed in "Interleaved Mode". However, NAL units of NAL unit disallowed in "Interleaved Mode". However, NAL units of NAL unit
types 1-23 can be used in "Interleaved Mode" as aggregation units in 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 FU-A STAP-B, MTAP16 and MTAP14 packets as well as fragmented units in FU-A
and FU-B packets. Similarly, NAL units of NAL unit types 1-23 can and FU-B packets. Similarly, NAL units of NAL unit types 1-23 can
also be used in the "Non-Interleaved Mode" as aggregation units in also be used in the "Non-Interleaved Mode" as aggregation units in
STAP-A packets or fragmented units in FU-A packets, in addition to STAP-A packets or fragmented units in FU-A packets, in addition to
being directly used as packet payloads. 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 NAL In the interleaved packetization mode, the transmission order of NAL
units is allowed to differ from the decoding order of the NAL units. units is allowed to differ from the decoding order of the NAL units.
skipping to change at page 35, line 21 skipping to change at page 35, line 21
The same output means that the resulting NAL units, and their order, The same output means that the resulting NAL units, and their order,
are identical. Optimizations relative to the described algorithms are identical. Optimizations relative to the described algorithms
are likely possible. Section 7.1 presents the de-packetization are likely possible. Section 7.1 presents the de-packetization
process for the single NAL unit and non-interleaved packetization process for the single NAL unit and non-interleaved packetization
modes, whereas section 7.2 describes the process for the interleaved modes, whereas section 7.2 describes the process for the interleaved
mode. Section 7.3 includes additional de-packetization guidelines mode. Section 7.3 includes additional de-packetization guidelines
for intelligent receivers. for intelligent receivers.
All normal RTP mechanisms related to buffer management apply. In All normal RTP mechanisms related to buffer management apply. In
particular, duplicated or outdated RTP packets (as indicated by the particular, duplicated or outdated RTP packets (as indicated by the
RTP sequences number and the RTP timestamp) are removed. To RTP sequence number and the RTP timestamp) are removed. To determine
determine the exact time for decoding, factors such as a possible the exact time for decoding, factors such as a possible intentional
intentional delay to allow for proper inter-stream synchronization delay to allow for proper inter-stream synchronization must be
must be factored in. factored in.
7.1. Single NAL Unit and Non-Interleaved Mode 7.1. Single NAL Unit and Non-Interleaved Mode
The receiver includes a receiver buffer to compensate for The receiver includes a receiver buffer to compensate for
transmission delay jitter. The receiver stores incoming packets in transmission delay jitter. The receiver stores incoming packets in
reception order into the receiver buffer. Packets are de-packetized reception order into the receiver buffer. Packets are de-packetized
in RTP sequence number order. If a de-packetized packet is a single in RTP sequence number order. If a de-packetized packet is a single
NAL unit packet, the NAL unit contained in the packet is passed NAL unit packet, the NAL unit contained in the packet is passed
directly to the decoder. If a de-packetized packet is an STAP-A, the directly to the decoder. If a de-packetized packet is an STAP-A, the
NAL units contained in the packet are passed to the decoder in the NAL units contained in the packet are passed to the decoder in the
skipping to change at page 36, line 16 skipping to change at page 36, line 16
practical receiver buffer that is also used for compensation of practical receiver buffer that is also used for compensation of
transmission delay jitter, the receiver buffer is here after called transmission delay jitter, the receiver buffer is here after called
the de-interleaving buffer in this section. Receivers SHOULD also the de-interleaving buffer in this section. Receivers SHOULD also
prepare for transmission delay jitter; i.e., either reserve separate prepare for transmission delay jitter; i.e., either reserve separate
buffers for transmission delay jitter buffering and de-interleaving buffers for transmission delay jitter buffering and de-interleaving
buffering or use a receiver buffer for both transmission delay jitter buffering or use a receiver buffer for both transmission delay jitter
and de-interleaving. Moreover, receivers SHOULD take transmission and de-interleaving. Moreover, receivers SHOULD take transmission
delay jitter into account in the buffering operation; e.g., by delay jitter into account in the buffering operation; e.g., by
additional initial buffering before starting of decoding and playback. additional initial buffering before starting of decoding and playback.
This section is organized as follows: subsection 7.2.1 presents how o This section is organized as follows: subsection 7.2.1 presents how
calculate the size of the de-interleaving buffer. Subsection 7.2.2 to calculate the size of the de-interleaving buffer. Subsection
specifies the receiver process how to organize received NAL units to 7.2.2 specifies the receiver process on how to organize received NAL
the NAL unit decoding order. units to the NAL unit decoding order.
7.2.1. Size of the De-interleaving Buffer 7.2.1. Size of the De-interleaving Buffer
In either Offer/Answer or declarative SDP usage, the sprop-deint-buf-
req media type parameter signals the requirement for the de-
interleaving buffer size. It is therefore RECOMMENDED to set the de-
interleaving buffer size, in terms of number of bytes, equal to or
greater than the value of sprop-deint-buf-req media type parameter.
When the SDP Offer/Answer model or any other capability exchange When the SDP Offer/Answer model or any other capability exchange
procedure is used in session setup, the properties of the received procedure is used in session setup, the properties of the received
stream SHOULD be such that the receiver capabilities are not exceeded. stream SHOULD be such that the receiver capabilities are not exceeded.
In the SDP Offer/Answer model, the receiver can indicate its In the SDP Offer/Answer model, the receiver can indicate its
capabilities to allocate a de-interleaving buffer with the deint-buf- capabilities to allocate a de-interleaving buffer with the deint-buf-
cap media type parameter. The sender indicates the requirement for cap media type parameter. See section 8.1 for further information on
the de-interleaving buffer size with the sprop-deint-buf-req media deint-buf-cap and sprop-deint-buf-req media type parameters and
type parameter. It is therefore RECOMMENDED to set the de- section 8.2.2 for further information on their use in the SDP
interleaving buffer size, in terms of number of bytes, equal to or Offer/Answer model.
greater than the value of sprop-deint-buf-req media type parameter.
See section 8.1 for further information on deint-buf-cap and sprop-
deint-buf-req media type parameters and section 8.2.2 for further
information on their use in the SDP Offer/Answer model.
When a declarative session description is used in session setup, the
sprop-deint-buf-req media type parameter signals the requirement for
the de-interleaving buffer size. It is therefore RECOMMENDED to set
the de-interleaving buffer size, in terms of number of bytes, equal
to or greater than the value of sprop-deint-buf-req media type
parameter.
7.2.2. De-interleaving Process 7.2.2. De-interleaving Process
There are two buffering states in the receiver: initial buffering and There are two buffering states in the receiver: initial buffering and
buffering while playing. Initial buffering occurs when the RTP buffering while playing. Initial buffering occurs when the RTP
session is initialized. After initial buffering, decoding and session is initialized. After initial buffering, decoding and
playback are started, and the buffering-while-playing mode is used. playback are started, and the buffering-while-playing mode is used.
Regardless of the buffering state, the receiver stores incoming NAL Regardless of the buffering state, the receiver stores incoming NAL
units, in reception order, in the de-interleaving buffer as follows. units, in reception order, in the de-interleaving buffer as follows.
skipping to change at page 38, line 31 skipping to change at page 38, line 25
o When a desired number of NAL units have been passed to the decoder, o When a desired number of NAL units have been passed to the decoder,
the value of PDON is set to the value of DON for the last NAL unit the value of PDON is set to the value of DON for the last NAL unit
passed to the decoder. passed to the decoder.
7.3. Additional De-Packetization Guidelines 7.3. Additional De-Packetization Guidelines
The following additional de-packetization rules may be used to The following additional de-packetization rules may be used to
implement an operational H.264 de-packetizer: implement an operational H.264 de-packetizer:
o Intelligent RTP receivers (e.g., in gateways) may identify lost o Intelligent RTP receivers (e.g., in gateways) may identify lost
coded slice data partitions A (DPAs). If a lost DPA is found, coded slice data partitions A (DPAs). If a lost DPA is detected,
after taking into account possible retransmission and FEC, a after taking into account possible retransmission and FEC, a
gateway may decide not to send the corresponding coded slice data gateway may decide not to send the corresponding coded slice data
partitions B and C, as their information is meaningless for H.264 partitions B and C, as their information is meaningless for H.264
decoders. In this way a MANE can reduce network load by decoders. In this way a MANE can reduce network load by
discarding useless packets without parsing a complex bitstream. discarding useless packets without parsing a complex bitstream.
o Intelligent RTP receivers (e.g., in gateways) may identify lost o Intelligent RTP receivers (e.g., in gateways) may identify lost
FUs. If a lost FU is found, a gateway may decide not to send the FUs. If a lost FU is found, a gateway may decide not to send the
following FUs of the same fragmented NAL unit, as their following FUs of the same fragmented NAL unit, as their
information is meaningless for H.264 decoders. In this way a MANE information is meaningless for H.264 decoders. In this way a MANE
skipping to change at page 40, line 19 skipping to change at page 40, line 9
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,
and 3) level_idc. Note that reserved_zero_4bits is required and 3) level_idc. Note that reserved_zero_4bits is required
to be equal to 0 in [1], but other values for it may be to be equal to 0 in [1], but other values for it may be
specified in the future by ITU-T or ISO/IEC. specified in the future by ITU-T or ISO/IEC.
The profile-level-id parameter indicates the default sub- The profile-level-id parameter indicates the default sub-
profile, i.e. the subset of coding tools that may have been profile, i.e. the subset of coding tools that may have been
used to generate the stream or the receiver supports, and the used to generate the stream or that the receiver supports, and
default level of the stream or the receiver supports. the default level of the stream or the receiver supports.
The default sub-profile is indicated collectively by the The default sub-profile is indicated collectively by the
profile_idc byte and some fields in the profile-iop byte. profile_idc byte and some fields in the profile-iop byte.
Depending on the values of the fields in the profile-iop byte, Depending on the values of the fields in the profile-iop byte,
the default sub-profile may be the same set of coding tools the default sub-profile may be the set of coding tools
supported by one profile, or a common subset of coding tools supported by one profile, or a common subset of coding tools
of multiple profiles, as specified in subsection 7.4.2.1.1 of of multiple profiles, as specified in subsection 7.4.2.1.1 of
[1]. The default level is indicated by the level_idc byte, [1]. The default level is indicated by the level_idc byte,
and, when profile_idc is equal to 66, 77 or 88 (the Baseline, and, when profile_idc is equal to 66, 77 or 88 (the Baseline,
Main, or Extended profile) and level_idc is equal to 11, Main, or Extended profile) and level_idc is equal to 11,
additionally by bit 4 (constraint_set3_flag) of the profile- additionally by bit 4 (constraint_set3_flag) of the profile-
iop byte. When profile_idc is equal to 66, 77 or 88 (the iop byte. When profile_idc is equal to 66, 77 or 88 (the
Baseline, Main, or Extended profile) and level_idc is equal to Baseline, Main, or Extended profile) and level_idc is equal to
11, and bit 4 (constraint_set3_flag) of the profile-iop byte 11, and bit 4 (constraint_set3_flag) of the profile-iop byte
is equal to 1, the default level is level 1b. is equal to 1, the default level is level 1b.
skipping to change at page 41, line 43 skipping to change at page 41, line 43
H44 F4 00000000 H44 F4 00000000
H10I 64 00010000 H10I 64 00010000
H42I 7A 00010000 H42I 7A 00010000
H44I F4 00010000 H44I F4 00010000
C44I 2C 00010000 C44I 2C 00010000
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 (note 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. Note common subset of coding tools for more than one profile. Note
also that a decoder conforming to a certain profile may be also that a decoder conforming to a certain profile may be
able to decode bitstreams conforming to other profiles. For able to decode bitstreams conforming to other profiles. For
example, a decoder conforming to the High 4:4:4 profile at example, a decoder conforming to the High 4:4:4 profile at
certain level must be able to decode bitstreams confirming to certain level must be able to decode bitstreams confirming to
the Constrained Baseline, Main, High, High 10 or High 4:2:2 the Constrained Baseline, Main, High, High 10 or High 4:2:2
profile at the same or a lower level. 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
skipping to change at page 42, line 36 skipping to change at page 42, line 36
many different combinations of profile_idc and profile-iop many different combinations of profile_idc and profile-iop
that represent the same sub-profile, using the one-of-N that represent the same sub-profile, using the one-of-N
codec selection procedure may result into a fairly large codec selection procedure may result into a fairly large
SDP message. Therefore, a receiver should understand the SDP message. Therefore, a receiver should understand the
different equivalent combinations of profile_idc and different equivalent combinations of profile_idc and
profile-iop that represent the same sub-profile, and be profile-iop that represent the same sub-profile, and be
ready to accept an offer using any of the equivalent ready to accept an offer using any of the equivalent
combinations. combinations.
If no profile-level-id is present, the Baseline Profile If no profile-level-id is present, the Baseline Profile
without additional constraints at Level 1 MUST be implied. without additional constraints at Level 1 MUST be inferred.
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br:
These parameters MAY be used to signal the capabilities of a These parameters MAY be used to signal the capabilities of a
receiver implementation. These parameters MUST NOT be used for receiver implementation. These parameters MUST NOT be used for
any other purpose. The profile-level-id parameter MUST be any other purpose. The profile-level-id parameter MUST be
present in the same receiver capability description that present in the same receiver capability description that
contains any of these parameters. The level conveyed in the contains any of these parameters. The level conveyed in the
value of the profile-level-id parameter MUST be such that the value of the profile-level-id parameter MUST be such that the
receiver is fully capable of supporting. max-mbps, max-smbps, receiver is fully capable of supporting. max-mbps, max-smbps,
max-fs, max-cpb, max-dpb, and max-br MAY be used to indicate max-fs, max-cpb, max-dpb, and max-br MAY be used to indicate
skipping to change at page 43, line 19 skipping to change at page 43, line 19
rate is up to max-mbps (inclusive), the bit rate is up to max- rate is up to max-mbps (inclusive), the bit rate is up to max-
br (inclusive), the coded picture buffer size is derived as br (inclusive), the coded picture buffer size is derived as
specified in the semantics of the max-br parameter below, and specified in the semantics of the max-br parameter below, and
other properties comply with the level specified in the value other properties comply with the level specified in the value
of the profile-level-id parameter. of the profile-level-id parameter.
If a receiver can support all the properties of level A, the If a receiver can support all the properties of level A, the
level specified in the value of the profile-level-id MUST be level specified in the value of the profile-level-id MUST be
level A (i.e. MUST NOT be lower than level A). In other words, level A (i.e. MUST NOT be lower than level A). In other words,
a sender or receiver MUST NOT signal values of max-mbps, max- a sender or receiver MUST NOT signal values of max-mbps, max-
fs, max-cpb, max-dpb, and max-br that meet the requirements of fs, max-cpb, max-dpb, and max-br that taken together meet the
a higher level compared to the level specified in the value of requirements of a higher level compared to the level specified
the profile-level-id parameter. in the value of the profile-level-id parameter.
Informative note: When the OPTIONAL media type parameters Informative note: When the OPTIONAL media type parameters
are used to signal the properties of a NAL unit stream, are used to signal the properties of a NAL unit stream,
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br
are not present, and the value of profile-level-id must are not present, and the value of profile-level-id must
always be such that the NAL unit stream complies fully with always be such that the NAL unit stream complies fully with
the specified profile and level. the specified profile and level.
max-mbps: The value of max-mbps is an integer indicating the max-mbps: The value of max-mbps is an integer indicating the
maximum macroblock processing rate in units of macroblocks per maximum macroblock processing rate in units of macroblocks per
skipping to change at page 77, line 19 skipping to change at page 77, line 19
10. Congestion Control 10. Congestion Control
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[5], and with any applicable RTP profile; e.g., RFC 3551 [16]. An [5], and with any applicable RTP profile; e.g., RFC 3551 [16]. An
additional requirement if best-effort service is being used is: users additional requirement if best-effort service is being used is: users
of this payload format MUST monitor packet loss to ensure that the of this payload format MUST monitor packet loss to ensure that the
packet loss rate is within acceptable parameters. Packet loss is packet loss rate is within acceptable parameters. Packet loss is
considered acceptable if a TCP flow across the same network path, and considered acceptable if a TCP flow across the same network path, and
experiencing the same network conditions, would achieve an average experiencing the same network conditions, would achieve an average
throughput, measured on a reasonable timescale that is not less than throughput, measured on a reasonable timescale, that is not less than
the RTP flow is achieving. This condition can be satisfied by the RTP flow is achieving. This condition can be satisfied by
implementing congestion control mechanisms to adapt the transmission implementing congestion control mechanisms to adapt the transmission
rate (or the number of layers subscribed for a layered multicast rate (or the number of layers subscribed for a layered multicast
session), or by arranging for a receiver to leave the session if the session), or by arranging for a receiver to leave the session if the
loss rate is unacceptably high. loss rate is unacceptably high.
The bit rate adaptation necessary for obeying the congestion control The bit rate adaptation necessary for obeying the congestion control
principle is easily achievable when real-time encoding is used. principle is easily achievable when real-time encoding is used.
However, when pre-encoded content is being transmitted, bandwidth However, when pre-encoded content is being transmitted, bandwidth
adaptation requires the availability of more than one coded adaptation requires the availability of more than one coded
skipping to change at page 91, line 18 skipping to change at page 91, line 18
the multi-picture slice interleaving technique (see section 12.6) for the multi-picture slice interleaving technique (see section 12.6) for
improved error resilience cannot be used. improved error resilience cannot be used.
14. Acknowledgements 14. 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. Randell Jesup, Stephen Botzko, Magnus
Westerlund, Alex Eleftheriadis, and Thomas Schierl are thanked for Westerlund, Alex Eleftheriadis, Thomas Schierl, and Tom Taylor are
their valuable comments and inputs during the development of this thanked for their valuable comments and inputs during the development
memo. 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 15. References
15.1. Normative References 15.1. Normative References
[1] ITU-T Recommendation H.264, "Advanced video coding for generic [1] ITU-T Recommendation H.264, "Advanced video coding for generic
audiovisual services", November 2007. audiovisual services", November 2007.
skipping to change at page 91, line 43 skipping to change at page 91, line 43
[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 Requirement [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. 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 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[6] Handley, M. and V. Jacobson, "SDP: Session Description [6] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Protocol", RFC 2327, April 1998. Description Protocol", RFC 4566, July 2006.
[7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003. 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", draft-ietf- Attributes in the Session Description Protocol", draft-ietf-
mmusic-sdp-source-attributes-02 (work in progress), October mmusic-sdp-source-attributes-02 (work in progress), October
skipping to change at page 93, line 35 skipping to change at page 93, line 35
[26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[27] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming [27] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[28] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [28] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[29] Westerlund, M. and Wenger, S., "RTP Topologies", RFC 5117, [29] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008. January 2008.
[30] Wenger, S., Chandra, U., and Westerlund, M., "Codec Control [30] Wenger, S., Chandra, U., and M. Westerlund, "Codec Control
Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", Messages in the RTP Audio-Visual Profile with Feedback (AVPF)",
RFC 5104, February 2008. RFC 5104, February 2008.
16. Authors' Addresses 16. Authors' Addresses
Ye-Kui Wang Ye-Kui Wang
Huawei Technologies Huawei Technologies
400 Somerset Corporate Blvd 400 Somerset Corporate Blvd
Bridgewater, NJ 08807 Bridgewater, NJ 08807
USA USA
 End of changes. 26 change blocks. 
58 lines changed or deleted 62 lines changed or added

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