draft-ietf-avt-rtp-rfc3984bis-06.txt   draft-ietf-avt-rtp-rfc3984bis-07.txt 
Obsoletes RFC 3984 Obsoletes RFC 3984
Audio/Video Transport WG Y.-K. Wang Audio/Video Transport WG Y.-K. Wang
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Standards track R. Even Intended status: Standards track R. Even
Expires: October 2009 Self-employed Expires: March 2010 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
April 30, 2009 R. Jesup
WorldGate Communications
September 10, 2009
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-06.txt draft-ietf-avt-rtp-rfc3984bis-07.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. This document may contain
material from IETF Documents or IETF Contributions published or material from IETF Documents or IETF Contributions published or
made publicly available before November 10, 2008. The person(s) made publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an material outside the IETF Standards Process. Without obtaining an
skipping to change at page 2, line 5 skipping to change at page 2, line 8
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress". progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 30, 2009. This Internet-Draft will expire on January 10, 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
skipping to change at page 2, line 38 skipping to change at page 2, line 41
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 18. Issues on backward compatibility to RFC 3984 are
discussed in section 17. discussed in section 17.
Table of Contents Table of Contents
Abstract.........................................................2
1. Introduction..................................................4 1. Introduction..................................................4
1.1. The H.264 Codec..........................................4 1.1. The H.264 Codec..........................................5
1.2. Parameter Set Concept....................................6 1.2. Parameter Set Concept....................................6
1.3. Network Abstraction Layer Unit Types.....................6 1.3. Network Abstraction Layer Unit Types.....................7
2. Conventions...................................................7 2. Conventions...................................................8
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.....................................17
5.5. Decoding Order Number (DON).............................18 5.5. Decoding Order Number (DON).............................18
5.6. Single NAL Unit Packet..................................21 5.6. Single NAL Unit Packet..................................21
5.7. Aggregation Packets.....................................22 5.7. Aggregation Packets.....................................22
5.7.1. Single-Time Aggregation Packet.....................24 Table 4. Type field for STAPs and MTAPs........................23
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)..........................30
6. Packetization Rules..........................................34 6. Packetization Rules..........................................34
6.1. Common Packetization Rules..............................34 6.1. Common Packetization Rules..............................34
6.2. Single NAL Unit Mode....................................35 6.2. Single NAL Unit Mode....................................35
6.3. Non-Interleaved Mode....................................35 6.3. Non-Interleaved Mode....................................35
6.4. Interleaved Mode........................................36 6.4. Interleaved Mode........................................36
7. De-Packetization Process.....................................36 7. De-Packetization Process.....................................36
7.1. Single NAL Unit and Non-Interleaved Mode................36 7.1. Single NAL Unit and Non-Interleaved Mode................36
7.2. Interleaved Mode........................................37 7.2. Interleaved Mode........................................37
7.2.1. Size of the De-interleaving Buffer.................37 7.2.1. Size of the De-interleaving Buffer.................37
7.2.2. De-interleaving Process............................38 7.2.2. De-interleaving Process............................38
7.3. Additional De-Packetization Guidelines..................39 7.3. Additional De-Packetization Guidelines..................39
8. Payload Format Parameters....................................40 8. Payload Format Parameters....................................40
8.1. Media Type Registration.................................40 8.1. Media Type Registration.................................40
8.2. SDP Parameters..........................................58 8.2. SDP Parameters..........................................59
8.2.1. Mapping of Payload Type Parameters to SDP..........58 8.2.1. Mapping of Payload Type Parameters to SDP..........59
8.2.2. Usage with the SDP Offer/Answer Model..............59 8.2.2. Usage with the SDP Offer/Answer Model..............60
8.2.3. Usage in Declarative Session Descriptions..........66 8.2.3. Usage in Declarative Session Descriptions..........69
8.3. Examples................................................67 8.3. Examples................................................70
8.4. Parameter Set Considerations............................74 Offer SDP:......................................................76
Answer SDP:.....................................................76
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).................................76 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.............................................77 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...................................77 a Decoder Refresh Point...................................81
9. Security Considerations......................................78 9. Security Considerations......................................82
10. Congestion Control..........................................79 10. Congestion Control..........................................82
11. IANA Consideration..........................................80 11. IANA Consideration..........................................83
12. Informative Appendix: Application Examples..................80 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......................................................80 Annex A......................................................84
12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit 12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit
Aggregation..................................................80 Aggregation..................................................84
12.3. Video Telephony, Interleaved Packetization Using NAL Unit 12.3. Video Telephony, Interleaved Packetization Using NAL Unit
Aggregation..................................................81 Aggregation..................................................84
12.4. Video Telephony with Data Partitioning.................82 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...................................................82 Correction...................................................86
12.6. Low Bit-Rate Streaming.................................85 12.6. Low Bit-Rate Streaming.................................88
12.7. Robust Packet Scheduling in Video Streaming............85 12.7. Robust Packet Scheduling in Video Streaming............89
13. Informative Appendix: Rationale for Decoding Order Number...86 13. Informative Appendix: Rationale for Decoding Order Number...90
13.1. Introduction...........................................86 13.1. Introduction...........................................90
13.2. Example of Multi-Picture Slice Interleaving............86 13.2. Example of Multi-Picture Slice Interleaving............90
13.3. Example of Robust Packet Scheduling....................88 13.3. Example of Robust Packet Scheduling....................91
13.4. Robust Transmission Scheduling of Redundant Coded Slices92 13.4. Robust Transmission Scheduling of Redundant Coded Slices95
13.5. Remarks on Other Design Possibilities..................93 13.5. Remarks on Other Design Possibilities..................96
14. Acknowledgements............................................93 14. Acknowledgements............................................97
15. References..................................................94 15. References..................................................97
15.1. Normative References...................................94 15.1. Normative References...................................97
15.2. Informative References.................................94 15.2. Informative References.................................98
16. Authors' Addresses..........................................96 16. Authors' Addresses.........................................100
17. Backward Compatibility to RFC 3984..........................97 Phone: +1-908-541-3518.........................................100
18. Changes from RFC 3984.......................................98 Phone: +972-545481099..........................................100
Tom Kristensen.................................................100
Phone: +47 67125125............................................100
Phone: +1-215-354-5166.........................................100
Email: rjesup@wgate.com........................................100
17. Backward Compatibility to RFC 3984.........................100
18. Changes from RFC 3984......................................102
1. Introduction 1. Introduction
This memo specifies an RTP payload specification for the video This memo specifies an RTP payload specification for the video
coding standard known as ITU-T Recommendation H.264 [1] and ISO/IEC coding standard known as ITU-T Recommendation H.264 [1] and ISO/IEC
International Standard 14496 Part 10 [2] (both also known as International Standard 14496 Part 10 [2] (both also known as
Advanced Video Coding, or AVC). In this memo the name H.264 is Advanced Video Coding, or AVC). In this memo the name H.264 is
used for the codec and the standard, but the memo is equally used for the codec and the standard, but the memo is equally
applicable to the ISO/IEC counterpart of the coding standard. applicable to the ISO/IEC counterpart of the coding standard.
skipping to change at page 10, line 18 skipping to change at page 10, line 34
default sub-profile: The subset of coding tools, which may be default sub-profile: The subset of coding tools, which may be
all coding tools of one profile or the common subset of coding all coding tools of one profile or the common subset of coding
tools of more than one profile, indicated by the profile-level- tools of more than one profile, indicated by the profile-level-
id parameter. id parameter.
default level: The level indicated by the profile-level-id default level: The level indicated by the profile-level-id
parameter, which consists of three octets, profile_idc, profile- parameter, which consists of three octets, profile_idc, profile-
iop, and level_idc. The default level is indicated by level_idc iop, and level_idc. The default level is indicated by level_idc
in most cases, and, in some cases, additionally by profile-iop. in most cases, and, in some cases, additionally by profile-iop.
maximum receive level: The higher of the default level (from
profile-level-id) and max-recv-level (if specified).
4.2. Abbreviations 4.2. Abbreviations
DON: Decoding Order Number DON: Decoding Order Number
DONB: Decoding Order Number Base DONB: Decoding Order Number Base
DOND: Decoding Order Number Difference DOND: Decoding Order Number Difference
FEC: Forward Error Correction FEC: Forward Error Correction
FU: Fragmentation Unit FU: Fragmentation Unit
IDR: Instantaneous Decoding Refresh IDR: Instantaneous Decoding Refresh
IEC: International Electrotechnical Commission IEC: International Electrotechnical Commission
ISO: International Organization for Standardization ISO: International Organization for Standardization
skipping to change at page 12, line 36 skipping to change at page 13, line 5
7.4.1.2 of [1]. 7.4.1.2 of [1].
The setting of the RTP Timestamp for MTAPs is defined in section The setting of the RTP Timestamp for MTAPs is defined in section
5.7.2. 5.7.2.
Receivers SHOULD ignore any picture timing SEI messages included Receivers SHOULD ignore any picture timing SEI messages included
in access units that have only one display timestamp. Instead, in access units that have only one display timestamp. Instead,
receivers SHOULD use the RTP timestamp for synchronizing the receivers SHOULD use the RTP timestamp for synchronizing the
display process. display process.
RTP senders SHOULD NOT transmit picture timing SEI messages for
pictures that are not supposed to be displayed as multiple
fields.
If one access unit has more than one display timestamp carried If one access unit has more than one display timestamp carried
in a picture timing SEI message, then the information in the SEI in a picture timing SEI message, then the information in the SEI
message SHOULD be treated as relative to the RTP timestamp, with message SHOULD be treated as relative to the RTP timestamp, with
the earliest event occurring at the time given by the RTP the earliest event occurring at the time given by the RTP
timestamp, and subsequent events later, as given by the timestamp, and subsequent events later, as given by the
difference in SEI message picture timing values. Let tSEI1, difference in SEI message picture timing values. Let tSEI1,
tSEI2, ..., tSEIn be the display timestamps carried in the SEI tSEI2, ..., tSEIn be the display timestamps carried in the SEI
message of an access unit, where tSEI1 is the earliest of all message of an access unit, where tSEI1 is the earliest of all
such timestamps. Let tmadjst() be a function that adjusts the such timestamps. Let tmadjst() be a function that adjusts the
SEI messages time scale to a 90-kHz time scale. Let TS be the SEI messages time scale to a 90-kHz time scale. Let TS be the
skipping to change at page 13, line 18 skipping to change at page 13, line 29
Informative note: Displaying coded frames as fields is needed Informative note: Displaying coded frames as fields is needed
commonly in an operation known as 3:2 pulldown, in which film commonly in an operation known as 3:2 pulldown, in which film
content that consists of coded frames is displayed on a content that consists of coded frames is displayed on a
display using interlaced scanning. The picture timing SEI display using interlaced scanning. The picture timing SEI
message enables carriage of multiple timestamps for the same message enables carriage of multiple timestamps for the same
coded picture, and therefore the 3:2 pulldown process is coded picture, and therefore the 3:2 pulldown process is
perfectly controlled. The picture timing SEI message perfectly controlled. The picture timing SEI message
mechanism is necessary because only one timestamp per coded mechanism is necessary because only one timestamp per coded
frame can be conveyed in the RTP timestamp. frame can be conveyed in the RTP timestamp.
Informative note: Because H.264 allows the decoding order to
be different from the display order, values of RTP timestamps
may not be monotonically non-decreasing as a function of RTP
sequence numbers. Furthermore, the value for inter-arrival
jitter reported in the RTCP reports may not be a trustworthy
indication of the network performance, as the calculation
rules for inter-arrival jitter (section 6.4.1 of RFC 3550)
assume that the RTP timestamp of a packet is directly
proportional to its transmission time.
5.2. Payload Structures 5.2. Payload Structures
The payload format defines three different basic payload structures. The payload format defines three different basic payload structures.
A receiver can identify the payload structure by the first byte of A receiver can identify the payload structure by the first byte of
the RTP packet payload, which co-serves as the RTP payload header the RTP packet payload, which co-serves as the RTP payload header
and, in some cases, as the first byte of the payload. This byte is and, in some cases, as the first byte of the payload. This byte is
always structured as a NAL unit header. The NAL unit type field always structured as a NAL unit header. The NAL unit type field
indicates which structure is present. The possible structures are indicates which structure is present. The possible structures are
as follows: as follows:
skipping to change at page 18, line 39 skipping to change at page 18, line 25
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", 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 MTAP14 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
skipping to change at page 43, line 16 skipping to change at page 43, line 16
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
exchange or session setup procedure, it indicates the subset exchange or session setup procedure, it indicates the subset
of coding tools, which is equal to the default sub-profile, of coding tools, which is equal to the default sub-profile,
and the highest level, which is equal to the default level, that the codec supports for both receiving and sending. If
that the codec supports. All levels lower than the default max-recv-level is not present, the default level from
level are also supported by the codec. profile-level-id indicates the highest level the codec wishes
to support. If max-recv-level is present it indicates the
highest level the codec supports for receiving, for use in
asymmetric exchanges. For either receiving or sending, all
levels that are lower than the highest level supported MUST
also be supported.
Informative note: Capability exchange and session setup Informative note: Capability exchange and session setup
procedures should provide means to list the capabilities procedures should provide means to list the capabilities
for each supported sub-profile separately. For example, for each supported sub-profile separately. For example,
the one-of-N codec selection procedure of the SDP the one-of-N codec selection procedure of the SDP
Offer/Answer model can be used (section 10.2 of [8]). Offer/Answer model can be used (section 10.2 of [8]).
The one-of-N codec selection procedure may also be used The one-of-N codec selection procedure may also be used
to provide different combinations of profile_idc and to provide different combinations of profile_idc and
profile-iop that represent the same sub-profile. When profile-iop that represent the same sub-profile. When
there are many different combinations of profile_idc and there are many different combinations of profile_idc and
skipping to change at page 43, line 40 skipping to change at page 43, line 45
the one-of-N codec selection procedure may result into a the one-of-N codec selection procedure may result into a
fairly large SDP message. Therefore, a receiver should fairly large SDP message. Therefore, a receiver should
understand the different equivalent combinations of understand the different equivalent combinations of
profile_idc and profile-iop that represent the same sub- profile_idc and profile-iop that represent the same sub-
profile, and be ready to accept an offer using any of the profile, and be ready to accept an offer using any of the
equivalent combinations. equivalent 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 inferred. without additional constraints at Level 1 MUST be inferred.
max-recv-level:
This parameter MAY be used to indicate the highest level a
receiver supports when the highest level is higher than the
default level (the level indicated by profile-level-id). The
value of max-recv-level is a base16 (hexadecimal)
representation of the two bytes after the syntax element
profile_idc in the sequence parameter set NAL unit specified
in [1]: profile-iop (as defined above) and level_idc. If the
level_idc byte of max-recv-level is equal to 11, and bit 4 of
the profile-iop byte of max-recv-level is equal to 1, the
highest level the receiver supports is level 1b. If bit 4 of
the profile-iop byte of max-recv-level is equal to 0, the
highest level the receiver supports is equal to the level_idc
byte of max-recv-level divided by 10.
max-recv-level MUST NOT be present if the highest level the
receiver supports is not higher than the default level.
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 receiver implementation. These parameters MUST NOT be used
for any other purpose. The profile-level-id parameter MUST for any other purpose. The highest level conveyed in the
be present in the same receiver capability description that value of the profile-level-id parameter or the max-recv-level
contains any of these parameters. The level conveyed in the parameter MUST be such that the receiver is fully capable of
value of the profile-level-id parameter MUST be such that the supporting. max-mbps, max-smbps, max-fs, max-cpb, max-dpb,
receiver is fully capable of supporting. max-mbps, max-smbps, and max-br MAY be used to indicate capabilities of the
max-fs, max-cpb, max-dpb, and max-br MAY be used to indicate receiver that extend the required capabilities of the
capabilities of the receiver that extend the required signaled highest level, as specified below.
capabilities of the signaled level, as specified below.
When more than one parameter from the set (max-mbps, max- When more than one parameter from the set (max-mbps, max-
smbps , max-fs, max-cpb, max-dpb, max-br) is present, the smbps , max-fs, max-cpb, max-dpb, max-br) is present, the
receiver MUST support all signaled capabilities receiver MUST support all signaled capabilities
simultaneously. For example, if both max-mbps and max-br are simultaneously. For example, if both max-mbps and max-br are
present, the signaled level with the extension of both the present, the signaled highest level with the extension of
frame rate and bit rate is supported. That is, the receiver both the frame rate and bit rate is supported. That is, the
is able to decode NAL unit streams in which the macroblock receiver is able to decode NAL unit streams in which the
processing rate is up to max-mbps (inclusive), the bit rate macroblock processing rate is up to max-mbps (inclusive), the
is up to max-br (inclusive), the coded picture buffer size is bit rate is up to max-br (inclusive), the coded picture
derived as specified in the semantics of the max-br parameter buffer size is derived as specified in the semantics of the
below, and other properties comply with the level specified max-br parameter below, and other properties comply with the
in the value of the profile-level-id parameter. highest level specified in the value of the profile-level-id
parameter or the max-recv-level 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 highest level specified in the value of the profile-level-id
level A (i.e. MUST NOT be lower than level A). In other parameter or the max-recv-level parameter MUST be level A
words, a sender or receiver MUST NOT signal values of max- (i.e. MUST NOT be lower than level A). In other words, a
mbps, max-fs, max-cpb, max-dpb, and max-br that taken receiver MUST NOT signal values of max-mbps, max-fs, max-cpb,
together meet the requirements of a higher level compared to max-dpb, and max-br that taken together meet the requirements
the level specified in the value of the profile-level-id of a higher level compared to the highest level specified in
parameter. the value of the profile-level-id parameter or the max-recv-
level 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 always be such that the NAL unit stream complies fully
with the specified profile and level. with 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 maximum macroblock processing rate in units of macroblocks
per second. The max-mbps parameter signals that the receiver per second. The max-mbps parameter signals that the receiver
is capable of decoding video at a higher rate than is is capable of decoding video at a higher rate than is
required by the signaled level conveyed in the value of the required by the signaled highest level conveyed in the value
profile-level-id parameter. When max-mbps is signaled, the of the profile-level-id parameter or the max-recv-level
receiver MUST be able to decode NAL unit streams that conform parameter. When max-mbps is signaled, the receiver MUST be
to the signaled level, with the exception that the MaxMBPS able to decode NAL unit streams that conform to the signaled
value in Table A-1 of [1] for the signaled level is replaced highestlevel, with the exception that the MaxMBPS value in
Table A-1 of [1] for the signaled highest level is replaced
with the value of max-mbps. The value of max-mbps MUST be with the value of max-mbps. The value of max-mbps MUST be
greater than or equal to the value of MaxMBPS for the level greater than or equal to the value of MaxMBPS given in Table
given in Table A-1 of [1]. Senders MAY use this knowledge to A-1 of [1] for the highest level. Senders MAY use this
send pictures of a given size at a higher picture rate than knowledge to send pictures of a given size at a higher
is indicated in the signaled level. picture rate than is indicated in the signaled highest level.
max-smbps: The value of max-smbps is an integer indicating the max-smbps: The value of max-smbps is an integer indicating the
maximum static macroblock processing rate in units of static maximum static macroblock processing rate in units of static
macroblocks per second, under the hypothetical assumption macroblocks per second, under the hypothetical assumption
that all macroblocks are static macroblocks. When max-smbps that all macroblocks are static macroblocks. When max-smbps
is signalled the MaxMBPS value in Table A-1 of [1] should be is signalled the MaxMBPS value in Table A-1 of [1] should be
replaced with the result of the following computation: replaced with the result of the following computation:
o If the parameter max-mbps is signalled, set a variable o If the parameter max-mbps is signalled, set a variable
MaxMacroblocksPerSecond to the value of max-mbps. MaxMacroblocksPerSecond to the value of max-mbps.
Otherwise, set MaxMacroblocksPerSecond equal to the value Otherwise, set MaxMacroblocksPerSecond equal to the value
of MaxMBPS for the level in Table A-1 [1]. of MaxMBPS in Table A-1 [1] for the highest level.
o Set a variable P_non-static to the proportion of non- o Set a variable P_non-static to the proportion of non-
static macroblocks in picture n. static macroblocks in picture n.
o Set a variable P_static to the proportion of static o Set a variable P_static to the proportion of static
macroblocks in picture n. macroblocks in picture n.
o The value of MaxMBPS in Table A-1 of [1] should be o The value of MaxMBPS in Table A-1 of [1] should be
considered by the encoder to be equal to: considered by the encoder to be equal to:
MaxMacroblocksPerSecond * max-smbps / ( P_non-static * MaxMacroblocksPerSecond * max-smbps / ( P_non-static *
max-smbps + P_static * MaxMacroblocksPerSecond) max-smbps + P_static * MaxMacroblocksPerSecond)
The encoder should recompute this value for each picture. The The encoder should recompute this value for each picture. The
value of max-smbps MUST be greater than the value of MaxMBPS value of max-smbps MUST be greater than the value of MaxMBPS
for the level given in Table A-1 of [1]. Senders MAY use given in Table A-1 of [1] for the highest level. Senders MAY
this knowledge to send pictures of a given size at a higher use this knowledge to send pictures of a given size at a
picture rate than is indicated in the signalled level. higher picture rate than is indicated in the signaled highest
level.
max-fs: The value of max-fs is an integer indicating the maximum max-fs: The value of max-fs is an integer indicating the maximum
frame size in units of macroblocks. The max-fs parameter frame size in units of macroblocks. The max-fs parameter
signals that the receiver is capable of decoding larger signals that the receiver is capable of decoding larger
picture sizes than are required by the signaled level picture sizes than are required by the signaled highest level
conveyed in the value of the profile-level-id parameter. conveyed in the value of the profile-level-id parameter or
When max-fs is signaled, the receiver MUST be able to decode the max-recv-level parameter. When max-fs is signaled, the
NAL unit streams that conform to the signaled level, with the receiver MUST be able to decode NAL unit streams that conform
exception that the MaxFS value in Table A-1 of [1] for the to the signaled highest level, with the exception that the
signaled level is replaced with the value of max-fs. The MaxFS value in Table A-1 of [1] for the signaled highest
value of max-fs MUST be greater than or equal to the value of level is replaced with the value of max-fs. The value of
MaxFS for the level given in Table A-1 of [1]. Senders MAY max-fs MUST be greater than or equal to the value of MaxFS
given in Table A-1 of [1] for the highest level. Senders MAY
use this knowledge to send larger pictures at a use this knowledge to send larger pictures at a
proportionally lower frame rate than is indicated in the proportionally lower frame rate than is indicated in the
signaled level. signaled highest level.
max-cpb: The value of max-cpb is an integer indicating the max-cpb: The value of max-cpb is an integer indicating the
maximum coded picture buffer size in units of 1000 bits for maximum coded picture buffer size in units of 1000 bits for
the VCL HRD parameters (see A.3.1 item i of [1]) and in units the VCL HRD parameters (see A.3.1 item i of [1]) and in units
of 1200 bits for the NAL HRD parameters (see A.3.1 item j of of 1200 bits for the NAL HRD parameters (see A.3.1 item j of
[1]). The max-cpb parameter signals that the receiver has [1]). The max-cpb parameter signals that the receiver has
more memory than the minimum amount of coded picture buffer more memory than the minimum amount of coded picture buffer
memory required by the signaled level conveyed in the value memory required by the signaled highest level conveyed in the
of the profile-level-id parameter. When max-cpb is signaled, value of the profile-level-id parameter or the max-recv-level
the receiver MUST be able to decode NAL unit streams that parameter. When max-cpb is signaled, the receiver MUST be
conform to the signaled level, with the exception that the able to decode NAL unit streams that conform to the signaled
MaxCPB value in Table A-1 of [1] for the signaled level is highest level, with the exception that the MaxCPB value in
replaced with the value of max-cpb. The value of max-cpb Table A-1 of [1] for the signaled highest level is replaced
MUST be greater than or equal to the value of MaxCPB for the with the value of max-cpb. The value of max-cpb MUST be
level given in Table A-1 of [1]. Senders MAY use this greater than or equal to the value of MaxCPB given in Table
A-1 of [1] for the highest level. Senders MAY use this
knowledge to construct coded video streams with greater knowledge to construct coded video streams with greater
variation of bit rate than can be achieved with the MaxCPB variation of bit rate than can be achieved with the MaxCPB
value in Table A-1 of [1]. value in Table A-1 of [1].
Informative note: The coded picture buffer is used in the Informative note: The coded picture buffer is used in the
hypothetical reference decoder (Annex C) of H.264. The hypothetical reference decoder (Annex C) of H.264. The
use of the hypothetical reference decoder is recommended use of the hypothetical reference decoder is recommended
in H.264 encoders to verify that the produced bitstream in H.264 encoders to verify that the produced bitstream
conforms to the standard and to control the output conforms to the standard and to control the output
bitrate. Thus, the coded picture buffer is conceptually bitrate. Thus, the coded picture buffer is conceptually
skipping to change at page 46, line 43 skipping to change at page 47, line 25
standard-compliant decoders can have any buffering standard-compliant decoders can have any buffering
arrangements provided that they can decode standard- arrangements provided that they can decode standard-
compliant bitstreams. Thus, in practice, the input compliant bitstreams. Thus, in practice, the input
buffer for video decoder can be integrated with de- buffer for video decoder can be integrated with de-
interleaving and de-jitter buffers of the receiver. interleaving and de-jitter buffers of the receiver.
max-dpb: The value of max-dpb is an integer indicating the max-dpb: The value of max-dpb is an integer indicating the
maximum decoded picture buffer size in units of 1024 bytes. maximum decoded picture buffer size in units of 1024 bytes.
The max-dpb parameter signals that the receiver has more The max-dpb parameter signals that the receiver has more
memory than the minimum amount of decoded picture buffer memory than the minimum amount of decoded picture buffer
memory required by the signaled level conveyed in the value memory required by the signaled highest level conveyed in the
of the profile-level-id parameter. When max-dpb is signaled, value of the profile-level-id parameter or the max-recv-level
the receiver MUST be able to decode NAL unit streams that parameter. When max-dpb is signaled, the receiver MUST be
conform to the signaled level, with the exception that the able to decode NAL unit streams that conform to the signaled
MaxDPB value in Table A-1 of [1] for the signaled level is highest level, with the exception that the MaxDPB value in
replaced with the value of max-dpb. Consequently, a receiver Table A-1 of [1] for the signaled highest level is replaced
that signals max-dpb MUST be capable of storing the following with the value of max-dpb. Consequently, a receiver that
signals max-dpb MUST be capable of storing the following
number of decoded frames, complementary field pairs, and non- number of decoded frames, complementary field pairs, and non-
paired fields in its decoded picture buffer: paired fields in its decoded picture buffer:
Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs *
256 * ChromaFormatFactor ), 16) 256 * ChromaFormatFactor ), 16)
PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are
defined in [1]. defined in [1].
The value of max-dpb MUST be greater than or equal to the The value of max-dpb MUST be greater than or equal to the
value of MaxDPB for the level given in Table A-1 of [1]. value of MaxDPB given in Table A-1 of [1] for the highest
Senders MAY use this knowledge to construct coded video level. Senders MAY use this knowledge to construct coded
streams with improved compression. video streams with improved compression.
Informative note: This parameter was added primarily to Informative note: This parameter was added primarily to
complement a similar codepoint in the ITU-T complement a similar codepoint in the ITU-T
Recommendation H.245, so as to facilitate signaling Recommendation H.245, so as to facilitate signaling
gateway designs. The decoded picture buffer stores gateway designs. The decoded picture buffer stores
reconstructed samples. There is no relationship between reconstructed samples. There is no relationship between
the size of the decoded picture buffer and the buffers the size of the decoded picture buffer and the buffers
used in RTP, especially de-interleaving and de-jitter used in RTP, especially de-interleaving and de-jitter
buffers. buffers.
max-br: The value of max-br is an integer indicating the maximum max-br: The value of max-br is an integer indicating the maximum
video bit rate in units of 1000 bits per second for the VCL video bit rate in units of 1000 bits per second for the VCL
HRD parameters (see A.3.1 item i of [1]) and in units of 1200 HRD parameters (see A.3.1 item i of [1]) and in units of 1200
bits per second for the NAL HRD parameters (see A.3.1 item j bits per second for the NAL HRD parameters (see A.3.1 item j
of [1]). of [1]).
The max-br parameter signals that the video decoder of the The max-br parameter signals that the video decoder of the
receiver is capable of decoding video at a higher bit rate receiver is capable of decoding video at a higher bit rate
than is required by the signaled level conveyed in the value than is required by the signaled highest level conveyed in
of the profile-level-id parameter. the value of the profile-level-id parameter or the max-recv-
level parameter.
When max-br is signaled, the video codec of the receiver MUST When max-br is signaled, the video codec of the receiver MUST
be able to decode NAL unit streams that conform to the be able to decode NAL unit streams that conform to the
signaled level, conveyed in the profile-level-id parameter, signaled highest level, with the following exceptions in the
with the following exceptions in the limits specified by the limits specified by the highest level:
level:
o The value of max-br replaces the MaxBR value of the o The value of max-br replaces the MaxBR value n Table A-1
signaled level (in Table A-1 of [1]). of [1] for the highest level.
o When the max-cpb parameter is not present, the result of o When the max-cpb parameter is not present, the result of
the following formula replaces the value of MaxCPB in the following formula replaces the value of MaxCPB in
Table A-1 of [1]: (MaxCPB of the signaled level) * max-br Table A-1 of [1]: (MaxCPB of the signaled level) * max-br
/ (MaxBR of the signaled level). / (MaxBR of the signaled highest level).
For example, if a receiver signals capability for Level 1.2 For example, if a receiver signals capability for Level 1.2
with max-br equal to 1550, this indicates a maximum video with max-br equal to 1550, this indicates a maximum video
bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum
video bitrate of 1860 kbits/sec for NAL HRD parameters, and a video bitrate of 1860 kbits/sec for NAL HRD parameters, and a
CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000).
The value of max-br MUST be greater than or equal to the The value of max-br MUST be greater than or equal to the
value MaxBR for the signaled level given in Table A-1 of [1]. value MaxBR given in Table A-1 of [1] for the signaled
highest level.
Senders MAY use this knowledge to send higher bitrate video Senders MAY use this knowledge to send higher bitrate video
as allowed in the level definition of Annex A of H.264, to as allowed in the level definition of Annex A of H.264, to
achieve improved video quality. achieve improved video quality.
Informative note: This parameter was added primarily to Informative note: This parameter was added primarily to
complement a similar codepoint in the ITU-T complement a similar codepoint in the ITU-T
Recommendation H.245, so as to facilitate signaling Recommendation H.245, so as to facilitate signaling
gateway designs. No assumption can be made from the gateway designs. No assumption can be made from the
value of this parameter that the network is capable of value of this parameter that the network is capable of
skipping to change at page 50, line 10 skipping to change at page 50, line 34
i.e., the subset of coding tools indicated by any of the i.e., the subset of coding tools indicated by any of the
parameter sets MUST be equal to the default sub-profile, and parameter sets MUST be equal to the default sub-profile, and
the level indicated by any of the parameter sets MUST be the level indicated by any of the parameter sets MUST be
equal to the default level. equal to the default level.
sprop-level-parameter-sets: sprop-level-parameter-sets:
This parameter MAY be used to convey any sequence and picture This parameter MAY be used to convey any sequence and picture
parameter set NAL units (herein referred to as the initial parameter set NAL units (herein referred to as the initial
parameter set NAL units) that can be placed in the NAL unit parameter set NAL units) that can be placed in the NAL unit
stream to precede any other NAL units in decoding order and stream to precede any other NAL units in decoding order and
that are associated with one or more levels lower than the that are associated with one or more levels different than
default level. The parameter MUST NOT be used to indicate the default level. The parameter MUST NOT be used to
codec capability in any capability exchange procedure. indicate codec capability in any capability exchange
procedure.
The sprop-level-parameter-sets parameter contains parameter The sprop-level-parameter-sets parameter contains parameter
sets for one or more levels which are lower than the default sets for one or more levels which are different than the
level. All parameter sets associated with one level are default level. All parameter sets associated with one level
clustered and prefixed with a three-byte field which has the are clustered and prefixed with a three-byte field which has
same syntax as profile-level-id. This enables the receiver the same syntax as profile-level-id. This enables the
to install the parameter sets for one level and discard the receiver to install the parameter sets for one level and
rest. The three-byte field is named PLId, and all parameter discard the rest. The three-byte field is named PLId, and
sets associated with one level are named PSL, which has the all parameter sets associated with one level are named PSL,
same syntax as sprop-parameter-sets. Parameter sets for each which has the same syntax as sprop-parameter-sets. Parameter
level are represented in the form of PLId:PSL, i.e., PLId sets for each level are represented in the form of PLId:PSL,
followed by a colon (':') and the base64 [7] representation i.e., PLId followed by a colon (':') and the base64 [7]
of the initial parameter set NAL units for the level. Each representation of the initial parameter set NAL units for the
pair of PLId:PSL is also separated by a colon. Note that a level. Each pair of PLId:PSL is also separated by a colon.
PSL can contain multiple parameter sets for that level, Note that a PSL can contain multiple parameter sets for that
separated with commas (','). level, separated with commas (',').
The subset of coding tools indicated by each PLId field MUST The subset of coding tools indicated by each PLId field MUST
be equal to the default sub-profile, and the level indicated be equal to the default sub-profile, and the level indicated
by each PLId field MUST be lower than the default level. All by each PLId field MUST be different than the default level.
sequence parameter sets contained in each PSL MUST have the All sequence parameter sets contained in each PSL MUST have
three bytes from profile_idc to level_idc, inclusive, equal the three bytes from profile_idc to level_idc, inclusive,
to the preceding PLId. equal to the preceding PLId.
Informative note: This parameter allows for efficient Informative note: This parameter allows for efficient
level downgrade in SDP Offer/Answer and out-of-band level downgrade or upgrade in SDP Offer/Answer and out-
transport of parameter sets, simultaneously. of-band transport of parameter sets, simultaneously.
use-level-src-parameter-sets: use-level-src-parameter-sets:
This parameter MAY be used to indicate a receiver capability. This parameter MAY be used to indicate a receiver capability.
The value MAY be equal to either 0 or 1. When the parameter The value MAY be equal to either 0 or 1. When the parameter
is not present, the value MUST be inferred to be equal to 0. is not present, the value MUST be inferred to be equal to 0.
The value 0 indicates that the receiver does not understand The value 0 indicates that the receiver does not understand
the sprop-level-parameter-sets parameter, and does not the sprop-level-parameter-sets parameter, and does not
understand the "fmtp" source attribute as specified in understand the "fmtp" source attribute as specified in
section 6.3 of [9], and will ignore sprop-level-parameter- section 6.3 of [9], and will ignore sprop-level-parameter-
sets when present, and will ignore sprop-parameter-sets when sets when present, and will ignore sprop-parameter-sets when
skipping to change at page 51, line 17 skipping to change at page 51, line 43
of using parameter sets contained in the sprop-level- of using parameter sets contained in the sprop-level-
parameter-sets or contained in the sprop-parameter-sets that parameter-sets or contained in the sprop-parameter-sets that
is conveyed using the "fmtp" source attribute. is conveyed using the "fmtp" source attribute.
Informative note: An RFC 3984 receiver does not Informative note: An RFC 3984 receiver does not
understand sprop-level-parameter-sets, use-level-src- understand sprop-level-parameter-sets, use-level-src-
parameter-sets, or the "fmtp" source attribute as parameter-sets, or the "fmtp" source attribute as
specified in section 6.3 of [9]. Therefore, during SDP specified in section 6.3 of [9]. Therefore, during SDP
Offer/Answer, an RFC 3984 receiver as the answerer will Offer/Answer, an RFC 3984 receiver as the answerer will
simply ignore sprop-level-parameter-sets, when present in simply ignore sprop-level-parameter-sets, when present in
an offer, and sprop-parameter-sets, when conveyed using an offer, and sprop-parameter-sets conveyed using the
the "fmtp" source attribute as specified in section 6.3 "fmtp" source attribute as specified in section 6.3 of
of [9]. Assume that the offered payload type was [9]. Assume that the offered payload type was accepted
accepted at a level lower than the default level. If the at a level lower than the default level. If the offered
offered payload type included sprop-level-parameter-sets payload type included sprop-level-parameter-sets or
or included sprop-parameter-sets conveyed using the included sprop-parameter-sets conveyed using the "fmtp"
"fmtp" source attribute, and the offerer sees that the source attribute, and the offerer sees that the answerer
answerer has not included use-level-src-parameter-sets has not included use-level-src-parameter-sets equal to 1
equal to 1 in the answer, the offerer gets to know that in the answer, the offerer knows that in-band transport
in-band transport of parameter sets is needed. of parameter sets is needed.
in-band-parameter-sets: in-band-parameter-sets:
This parameter MAY be used to indicate a receiver capability. This parameter MAY be used to indicate a receiver capability.
The value MAY be equal to either 0 or 1. The value 1 The value MAY be equal to either 0 or 1. The value 1
indicates that receiver discards out-of-band parameter sets indicates that the receiver discards out-of-band parameter
in sprop-parameter-sets and sprop-level-parameter-sets, sets in sprop-parameter-sets and sprop-level-parameter-sets,
therefore the sender MUST transmit all parameter sets in-band. therefore the sender MUST transmit all parameter sets in-band.
The value 0 indicates that the receiver utilizes out-of-band The value 0 indicates that the receiver utilizes out-of-band
parameter sets included in sprop-parameter-sets and sprop- parameter sets included in sprop-parameter-sets and/or sprop-
level-parameter-sets. However, in this case, the sender MAY level-parameter-sets. However, in this case, the sender MAY
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:
This parameter MAY be used in SDP Offer/Answer to indicate
whether level asymmetry, i.e., using a different level in the
offerer-to-answerer direction than the level in the answerer-
to-offerer direction, is allowed. The value MAY be equal to
either 0 or 1. When the parameter is not present, the value
MUST be inferred to be equal to 0. The value 1 in both the
offer and the answer indicates that level asymmetry is
allowed. The value of 0 in either the offer or the answer
indicates the level asymmetry is not allowed.
If "level-asymmetry-allowed" is equal to 0 (or not present)
in either the offer or the answer, level asymmetry is not
allowed. In this case, the level to use in the direction
from the offerer to the answerer MUST be the same as the
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, as
skipping to change at page 58, line 22 skipping to change at page 59, line 19
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).
o The clock rate in the "a=rtpmap" line MUST be 90000. o The clock rate in the "a=rtpmap" line MUST be 90000.
o The OPTIONAL parameters "profile-level-id", "max-mbps", "max- o The OPTIONAL parameters "profile-level-id", "max-recv-level",
smbps", "max-fs", "max-cpb", "max-dpb", "max-br", "redundant- "max-mbps", "max-smbps", "max-fs", "max-cpb", "max-dpb", "max-
pic-cap", "use-level-src-parameter-sets", "in-band-parameter- br", "redundant-pic-cap", "use-level-src-parameter-sets", "in-
sets", "packetization-mode", "sprop-interleaving-depth", "sprop- band-parameter-sets", "level-asymmetry-allowed", "packetization-
deint-buf-req", "deint-buf-cap", "sprop-init-buf-time", "sprop- mode", "sprop-interleaving-depth", "sprop-deint-buf-req",
max-don-diff", "max-rcmd-nalu-size", "sar-understood", and "sar- "deint-buf-cap", "sprop-init-buf-time", "sprop-max-don-diff",
supported", when present, MUST be included in the "a=fmtp" line "max-rcmd-nalu-size", "sar-understood", and "sar-supported",
of SDP. These parameters are expressed as a media type string, when present, MUST be included in the "a=fmtp" line of SDP.
in the form of a semicolon separated list of parameter=value These parameters are expressed as a media type string, in the
pairs. form of a semicolon separated list of parameter=value pairs.
o The OPTIONAL parameters "sprop-parameter-sets" and "sprop-level- o The OPTIONAL parameters "sprop-parameter-sets" and "sprop-level-
parameter-sets", when present, MUST be included in the "a=fmtp" parameter-sets", when present, MUST be included in the "a=fmtp"
line of SDP or conveyed using the "fmtp" source attribute as line of SDP or conveyed using the "fmtp" source attribute as
specified in section 6.3 of [9]. For a particular media format specified in section 6.3 of [9]. For a particular media format
(i.e., RTP payload type), a "sprop-parameter-sets" or "sprop- (i.e., RTP payload type), a "sprop-parameter-sets" or "sprop-
level-parameter-sets" MUST NOT be both included in the "a=fmtp" level-parameter-sets" MUST NOT be both included in the "a=fmtp"
line of SDP and conveyed using the "fmtp" source attribute. line of SDP and conveyed using the "fmtp" source attribute.
When included in the "a=fmtp" line of SDP, these parameters are When included in the "a=fmtp" line of SDP, these parameters are
expressed as a media type string, in the form of a semicolon expressed as a media type string, in the form of a semicolon
skipping to change at page 59, line 24 skipping to change at page 60, line 22
packetization-mode=1; packetization-mode=1;
sprop-parameter-sets=<parameter sets data> sprop-parameter-sets=<parameter sets data>
8.2.2. Usage with the SDP Offer/Answer Model 8.2.2. Usage with the SDP Offer/Answer Model
When H.264 is offered over RTP using SDP in an Offer/Answer model When H.264 is offered over RTP using SDP in an Offer/Answer model
[8] for negotiation for unicast usage, the following limitations [8] for negotiation for unicast usage, the following limitations
and rules apply: and rules apply:
o The parameters identifying a media format configuration for o The parameters identifying a media format configuration for
H.264 are "profile-level-id" and "packetization-mode", when H.264 are "profile-level-id" and "packetization-mode". These
present. These media format configuration parameters (except media format configuration parameters (except for the level part
for the level part of "profile-level-id") MUST be used of "profile-level-id") MUST be used symmetrically; i.e., the
symmetrically; i.e., the answerer MUST either maintain all answerer MUST either maintain all configuration parameters or
configuration parameters or remove the media format (payload remove the media format (payload type) completely, if one or
type) completely, if one or more of the parameter values are not more of the parameter values are not supported. Note that the
supported. Note that the level part of "profile-level-id" level part of "profile-level-id" includes level_idc, and, for
includes level_idc, and, for indication of level 1b when indication of level 1b when profile_idc is equal to 66, 77 or 88,
profile_idc is equal to 66, 77 or 88, bit 4 bit 4 (constraint_set3_flag) of profile-iop. The level part of
(constraint_set3_flag) of profile-iop. The level part of "profile-level-id" is changeable.
"profile-level-id" is downgradable, i.e. the answerer MUST
maintain the same or a lower level or remove the media format
(payload type) completely.
Informative note: The requirement for symmetric use applies Informative note: The requirement for symmetric use does not
only for the above media format configuration parameters apply for the level part of "profile-level-id", and does not
excluding the level part of "profile-level-id", and not for apply for the other stream properties and capability
the other stream properties and capability parameters. parameters.
Informative note: In H.264 [1], all the levels except for Informative note: In H.264 [1], all the levels except for
level 1b are equal to the value of level_idc divided by 10. level 1b are equal to the value of level_idc divided by 10.
Level 1b is a level higher than level 1.0 but lower than Level 1b is a level higher than level 1.0 but lower than
level 1.1, and is signaled in an ad-hoc manner, due to that level 1.1, and is signaled in an ad-hoc manner, due to that
the level was specified after level 1.0 and level 1.1. For the level was specified after level 1.0 and level 1.1. For
the Baseline, Main and Extended profiles (with profile_idc the Baseline, Main and Extended profiles (with profile_idc
equal to 66, 77 and 88, respectively), level 1b is indicated equal to 66, 77 and 88, respectively), level 1b is indicated
by level_idc equal to 11 (i.e. same as level 1.1) and by level_idc equal to 11 (i.e. same as level 1.1) and
constraint_set3_flag equal to 1. For other profiles, level constraint_set3_flag equal to 1. For other profiles, level
skipping to change at page 60, line 21 skipping to change at page 61, line 15
to the ad-hoc indication of level 1b, offerers and answerers to the ad-hoc indication of level 1b, offerers and answerers
must check the value of bit 4 (constraint_set3_flag) of the must check the value of bit 4 (constraint_set3_flag) of the
middle octet of the parameter "profile-level-id", when middle octet of the parameter "profile-level-id", when
profile_idc is equal to 66, 77 or 88 and level_idc is equal profile_idc is equal to 66, 77 or 88 and level_idc is equal
to 11. to 11.
To simplify handling and matching of these configurations, the To simplify handling and matching of these configurations, the
same RTP payload type number used in the offer SHOULD also be same RTP payload type number used in the offer SHOULD also be
used in the answer, as specified in [8]. An answer MUST NOT used in the answer, as specified in [8]. An answer MUST NOT
contain a payload type number used in the offer unless the contain a payload type number used in the offer unless the
configuration is exactly the same as in the offer or the configuration is exactly the same as in the offer.
configuration in the answer only differs from that in the offer
with a level lower than the default level offered.
Informative note: When an offerer receives an answer, it has Informative note: When an offerer receives an answer, it has
to compare payload types not declared in the offer based on to compare payload types not declared in the offer based on
the media type (i.e., video/H264) and the above media the media type (i.e., video/H264) and the above media
configuration parameters with any payload types it has configuration parameters with any payload types it has
already declared. This will enable it to determine whether already declared. This will enable it to determine whether
the configuration in question is new or if it is equivalent the configuration in question is new or if it is equivalent
to configuration already offered, since a different payload to configuration already offered, since a different payload
type number may be used in the answer. type number may be used in the answer.
o The parameter "max-recv-level", when present, declares the
highest level supported for receiving. In case "max-recv-level"
is not present, the highest level supported for receiving is
equal to the default level indicated by the level part of
"profile-level-id". "max-recv-level" MUST be higher than the
default level.
o The parameter "level-asymmetry-allowed" indicates whether level
asymmetry is allowed.
If "level-asymmetry-allowed" is equal to 0 (or not present) in
either the offer or the answer, level asymmetry is not allowed.
In this case, the level to use in the direction from the offerer
to the answerer MUST be the same as the level to use in the
opposite direction, and the common level to use is equal to the
lower value of the default level in the offer and the default
level in the answer.
Otherwise ("level-asymmetry-allowed" equals to 1 in both the
offer and the answer), level asymmetry is allowed. In this case,
the level to use in the offerer-to-answerer direction MUST be
equal to the highest level the answerer supports for receiving,
and the level to use in the answerer-to-offerer direction MUST
be equal to the highest level the offerer supports for receiving.
When level asymmetry is not allowed, level upgrade is not
allowed, i.e. the default level in the answer MUST be equal to
or lower than the default level in the offer.
o The parameters "sprop-deint-buf-req", "sprop-interleaving-depth", o The parameters "sprop-deint-buf-req", "sprop-interleaving-depth",
"sprop-max-don-diff", and "sprop-init-buf-time" describe the "sprop-max-don-diff", and "sprop-init-buf-time" describe the
properties of the RTP packet stream that the offerer or answerer properties of the RTP packet stream that the offerer or answerer
is sending for the media format configuration. This differs is sending for the media format configuration. This differs
from the normal usage of the Offer/Answer parameters: normally from the normal usage of the Offer/Answer parameters: normally
such parameters declare the properties of the stream that the such parameters declare the properties of the stream that the
offerer or the answerer is able to receive. When dealing with offerer or the answerer is able to receive. When dealing with
H.264, the offerer assumes that the answerer will be able to H.264, the offerer assumes that the answerer will be able to
receive media encoded using the configuration being offered. receive media encoded using the configuration being offered.
Informative note: The above parameters apply for any stream Informative note: The above parameters apply for any stream
sent by the declaring entity with the same configuration; sent by the declaring entity with the same configuration;
i.e., they are dependent on their source. Rather than being i.e., they are dependent on their source. Rather than being
bound to the payload type, the values may have to be applied bound to the payload type, the values may have to be applied
to another payload type when being sent, as they apply for to another payload type when being sent, as they apply for
the configuration. the configuration.
o The capability parameters ("max-mbps", "max-smbps", "max-fs", o The capability parameters "max-mbps", "max-smbps", "max-fs",
"max-cpb", "max-dpb", "max-br", ,"redundant-pic-cap", "max-rcmd- "max-cpb", "max-dpb", "max-br", ,"redundant-pic-cap", "max-rcmd-
nalu-size", "sar-understood", "sar-supported") MAY be used to nalu-size", "sar-understood", "sar-supported" MAY be used to
declare further capabilities of the offerer or answerer for declare further capabilities of the offerer or answerer for
receiving. These parameters can only be present when the receiving. These parameters MUST NOT be present when the
direction attribute is sendrecv or recvonly, and the parameters direction attribute is sendonly, and the parameters describe the
describe the limitations of what the offerer or answerer accepts limitations of what the offerer or answerer accepts for
for receiving streams. receiving streams.
o An offerer has to include the size of the de-interleaving buffer, o An offerer has to include the size of the de-interleaving buffer,
"sprop-deint-buf-req", in the offer for an interleaved H.264 "sprop-deint-buf-req", in the offer for an interleaved H.264
stream. To enable the offerer and answerer to inform each other stream. To enable the offerer and answerer to inform each other
about their capabilities for de-interleaving buffering in about their capabilities for de-interleaving buffering in
receiving streams, both parties are RECOMMENDED to include receiving streams, both parties are RECOMMENDED to include
"deint-buf-cap". For interleaved streams, it is also "deint-buf-cap". For interleaved streams, it is also
RECOMMENDED to consider offering multiple payload types with RECOMMENDED to consider offering multiple payload types with
different buffering requirements when the capabilities of the different buffering requirements when the capabilities of the
receiver are unknown. receiver are unknown.
o The "sprop-parameter-sets" or "sprop-level-parameter-sets" o The "sprop-parameter-sets" or "sprop-level-parameter-sets"
parameter, when present (included in the "a=fmtp" line of SDP or parameter, when present (included in the "a=fmtp" line of SDP or
conveyed using the "fmtp" source attribute as specified in conveyed using the "fmtp" source attribute as specified in
section 6.3 of [9]), is used for out-of-band transport of section 6.3 of [9]), is used for out-of-band transport of
parameter sets. However, when out-of-band transport of parameter sets. However, when out-of-band transport of
parameter sets is used, parameter sets MAY still be additionally parameter sets is used, parameter sets MAY still be additionally
transported in-band. If neither "sprop-parameter-sets" nor transported in-band.
"sprop-level-parameter-sets" is present, then only in-band
transport of parameter sets is used.
An offer MAY include either or both of "sprop-parameter-sets" The answerer MAY use either out-of-band or in-band transport of
and "sprop-level-parameter-sets". An answer MAY include "sprop- parameter sets for the stream it is sending, regardless of
parameter-sets", and MUST NOT include "sprop-level-parameter- whether out-of-band parameter sets transport has been used in
sets". the offerer-to-answerer direction. Parameter sets included in
an answer are independent of those parameter sets included in
the offer, as they are used for decoding two different video
streams, one from the answerer to the offerer, and the other in
the opposite direction.
If the answer includes "in-band-parameter-sets" equal to 1, then The following rules apply to transport of parameter sets in the
the sender MUST transmit parameter sets in-band. offerer-to-answerer direction.
o An offer MAY include either or both of "sprop-parameter-
sets" and "sprop-level-parameter-sets". If neither "sprop-
parameter-sets" nor "sprop-level-parameter-sets" is present
in the offer, then only in-band transport of parameter sets
is used.
o If the answer includes "in-band-parameter-sets" equal to 1,
then the offerer MUST transmit parameter sets in-band.
Otherwise, the following applies. Otherwise, the following applies.
o When an offered payload type is accepted without level o If the level to use in the offerer-to-answerer
downgrade, i.e. the default level is accepted, the direction is equal to the default level in the offer,
following applies. the following applies.
o When there is a "sprop-parameter-sets" included in the When there is a "sprop-parameter-sets" included
"a=fmtp" line of SDP, the answerer MUST be prepared to in the "a=fmtp" line in the offer, the answerer
use the parameter sets included in "sprop-parameter- MUST be prepared to use the parameter sets
sets" for decoding the incoming NAL unit stream. included in the "sprop-parameter-sets" for
decoding the incoming NAL unit stream.
o When there is a "sprop-parameter-sets" conveyed using When there is a "sprop-parameter-sets" conveyed
the "fmtp" source attribute as specified in section using the "fmtp" source attribute in the offer,
6.3 of [9], and the answerer understands the "fmtp" the following applies. If the answer includes
source attribute, it MUST be prepared to use the "use-level-src-parameter-sets" equal to 1 or the
parameter sets included in "sprop-parameter-sets" for "fmtp" source attribute, the answerer MUST be
decoding the incoming NAL unit stream, and it MUST prepared to use the parameter sets included in
include either "use-level-src-parameter-sets" equal to the "sprop-parameter-sets" for decoding the
1 or the "fmtp" source attribute in the answer. incoming NAL unit stream; Otherwise, the offerer
MUST transmit parameter sets in-band.
o When there is a "sprop-parameter-sets" conveyed using When "sprop-parameter-sets" is not present in the
the "fmtp" source attribute as specified in section offer, the offerer MUST transmit parameter sets
6.3 of [9], and the answerer does not understand the in-band.
"fmtp" source attribute, the sender MUST transmit
parameter sets in-band, and the answerer MUST NOT
include "use-level-src-parameter-sets" equal to 1 or
the "fmtp" source attribute in the answer.
o When "sprop-parameter-sets" is not present, the sender The answerer MUST ignore "sprop-level-parameter-
MUST transmit parameter sets in-band. sets", when present (either included in the
"a=fmtp" line or conveyed using the "fmtp" source
attribute) in the offer.
o The answerer MUST ignore "sprop-level-parameter-sets", o Otherwise (the level to use in the offerer-to-answerer
when present (either included in the "a=fmtp" line of direction is not equal to the default level in the
SDP or conveyed using the "fmtp" source attribute). offer, the following applies.
o When level downgrade is in use, i.e., a level lower than The answerer MUST ignore "sprop-parameter-sets",
the default level offered is accepted, the following when present (either included in the "a=fmtp"
line or conveyed using the "fmtp" source
attribute) in the offer.
When neither "use-level-src-parameter-sets" equal
to 1 nor the "fmtp" source attribute is present
in the answer, the answerer MUST ignore "sprop-
level-parameter-sets", when present in the offer,
and the offerer MUST transmit parameter sets in-
band.
When either "use-level-src-parameter-sets" equal
to 1 or the "fmtp" source attribute is present in
the answer, the answerer MUST be prepared to use
the parameter sets that are included in "sprop-
level-parameter-sets" for the accepted level (i.e.
the default level in the answer), when present in
the offer, for decoding the incoming NAL unit
stream, and ignore all other parameter sets
included in "sprop-level-parameter-sets".
When no parameter sets for the level to use in
the offerer-to-answerer direction are present in
"sprop-level-parameter-sets" in the offer, the
offerer MUST transmit parameter sets in-band.
The following rules apply to transport of parameter sets in the
answerer-to-offerer direction.
o An answer MAY include either "sprop-parameter-sets" or
"sprop-level-parameter-sets", but MUST NOT include both of
the two. If neither "sprop-parameter-sets" nor "sprop-
level-parameter-sets" is present in the answer, then only
in-band transport of parameter sets is used.
o If the offer includes "in-band-parameter-sets" equal to 1,
the answerer MUST NOT include "sprop-parameter-sets" or
"sprop-level-parameter-sets" in the answer and MUST
transmit parameter sets in-band. Otherwise, the following
applies. applies.
o The answerer MUST ignore "sprop-parameter-sets", when o If the level to use in the answerer-to-offerer
present (either included in the "a=fmtp" line of SDP direction is equal to the default level in the answer,
or conveyed using the "fmtp" source attribute). the following applies.
o When "use-level-src-parameter-sets" equal to 1 and the When there is a "sprop-parameter-sets" included
"fmtp" source attribute are not present in the answer in the "a=fmtp" line in the answer, the offerer
for the accepted payload type, the answerer MUST MUST be prepared to use the parameter sets
ignore "sprop-level-parameter-sets", when present, and included in the "sprop-parameter-sets" for
the sender MUST transmit parameter sets in-band. decoding the incoming NAL unit stream.
o When "use-level-src-parameter-sets" equal to 1 or the When there is a "sprop-parameter-sets" conveyed
"fmtp" source attribute is present in the answer for using the "fmtp" source attribute in the answer,
the accepted payload type, the answerer MUST be the following applies. If the offer includes
prepared to use the parameter sets that are included "use-level-src-parameter-sets" equal to 1 or the
in "sprop-level-parameter-sets" for the accepted level, "fmtp" source attribute, the offerer MUST be
when present, for decoding the incoming NAL unit prepared to use the parameter sets included in
stream, and ignore all other parameter sets included the "sprop-parameter-sets" for decoding the
in "sprop-level-parameter-sets". incoming NAL unit stream; Otherwise, the
answerer MUST transmit parameter sets in-band.
o When no parameter sets for the accepted level are When "sprop-parameter-sets" is not present in the
present in the "sprop-level-parameter-sets", the answer, the answerer MUST transmit parameter sets
sender MUST transmit parameter sets in-band. in-band.
The answerer MAY or MAY not include "sprop-parameter-sets", i.e., The offerer MUST ignore "sprop-level-parameter-
the answerer MAY use either out-of-band or in-band transport of sets", when present (either included in the
parameter sets for the stream it is sending, regardless of "a=fmtp" line or conveyed using the "fmtp" source
whether out-of-band parameter sets transport has been used in attribute) in the answer.
the offerer-to-answerer direction. When the offer includes "in-
band-parameter-sets" equal to 1, the answerer MUST NOT include
"sprop-parameter-sets" and MUST transmit parameter sets in-band.
All parameter sets included in the "sprop-parameter-sets", when
present, for the accepted payload type in an answer MUST be
associated with the accepted level, as indicated by the profile-
level-id in the answer for the accepted payload type.
Parameter sets included in "sprop-parameter-sets" in an answer o Otherwise (the level to use in the answerer-to-offerer
are independent of those parameter sets included in the offer, direction is not equal to the default level in the
as they are used for decoding two different video streams, one answer, the following applies.
from the answerer to the offerer, and the other in the opposite
direction. The offerer MUST be prepared to use the parameter The offerer MUST ignore "sprop-parameter-sets",
sets included in the answer's "sprop-parameter-sets", when when present (either included in the "a=fmtp"
present, for decoding the incoming NAL unit stream. line of SDP or conveyed using the "fmtp" source
attribute) in the answer.
When neither "use-level-src-parameter-sets" equal
to 1 nor the "fmtp" source attribute is present
in the offer, the offerer MUST ignore "sprop-
level-parameter-sets", when present, and the
answerer MUST transmit parameter sets in-band.
When either "use-level-src-parameter-sets" equal
to 1 or the "fmtp" source attribute is present in
the offer, the offerer MUST be prepared to use
the parameter sets that are included in "sprop-
level-parameter-sets" for the level to use in the
answerer-to-offerer direction, when present in
the answer, for decoding the incoming NAL unit
stream, and ignore all other parameter sets
included in "sprop-level-parameter-sets" in the
answer.
When no parameter sets for the level to use in
the answerer-to-offerer direction are present in
"sprop-level-parameter-sets" in the answer, the
answerer MUST transmit parameter sets in-band.
When "sprop-parameter-sets" or "sprop-level-parameter-sets" is When "sprop-parameter-sets" or "sprop-level-parameter-sets" is
conveyed using the "fmtp" source attribute in as specified in conveyed using the "fmtp" source attribute in as specified in
section 6.3 of [9], the receiver of the parameters MUST store section 6.3 of [9], the receiver of the parameters MUST store
the parameter sets included in the "sprop-parameter-sets" or the parameter sets included in the "sprop-parameter-sets" or
"sprop-level-parameter-sets" for the accepted level and "sprop-level-parameter-sets" for the accepted level and
associate them to the source given as a part of the "fmtp" associate them to the source given as a part of the "fmtp"
source attribute. Parameter sets associated with one source source attribute. Parameter sets associated with one source
MUST only be used to decode NAL units conveyed in RTP packets MUST only be used to decode NAL units conveyed in RTP packets
from the same source. When this mechanism is in use, SSRC from the same source. When this mechanism is in use, SSRC
skipping to change at page 64, line 8 skipping to change at page 67, line 5
specified in [9]. specified in [9].
Informative note: Conveyance of "sprop-parameter-sets" and Informative note: Conveyance of "sprop-parameter-sets" and
"sprop-level-parameter-sets" using the "fmtp" source "sprop-level-parameter-sets" using the "fmtp" source
attribute may be used in topologies like Topo-Video-switch- attribute may be used in topologies like Topo-Video-switch-
MCU [29] to enable out-of-band transport of parameter sets. MCU [29] to enable out-of-band transport of parameter sets.
For streams being delivered over multicast, the following rules For streams being delivered over multicast, the following rules
apply: apply:
o The media format configuration is identified by the same o The media format configuration is identified by "profile-level-
parameters as above for unicast (i.e. "profile-level-id" and id", including the level part, and "packetization-mode". These
"packetization-mode", when present). These media format media format configuration parameters (including the level part
configuration parameters (including the level part of "profile- of "profile-level-id") MUST be used symmetrically; i.e., the
level-id") MUST be used symmetrically; i.e., the answerer MUST answerer MUST either maintain all configuration parameters or
either maintain all configuration parameters or remove the media remove the media format (payload type) completely. Note that
format (payload type) completely. Note that this implies that this implies that the level part of "profile-level-id" for
the level part of "profile-level-id" for Offer/Answer in Offer/Answer in multicast is not changeable.
multicast is not downgradable.
To simplify handling and matching of these configurations, the To simplify handling and matching of these configurations, the
same RTP payload type number used in the offer SHOULD also be same RTP payload type number used in the offer SHOULD also be
used in the answer, as specified in [8]. An answer MUST NOT used in the answer, as specified in [8]. An answer MUST NOT
contain a payload type number used in the offer unless the contain a payload type number used in the offer unless the
configuration is the same as in the offer. configuration is the same as in the offer.
o Parameter sets received MUST be associated with the originating o Parameter sets received MUST be associated with the originating
source, and MUST be only used in decoding the incoming NAL unit source, and MUST be only used in decoding the incoming NAL unit
stream from the same source. stream from the same source.
o The rules for other parameters are the same as above for unicast. o The rules for other parameters are the same as above for unicast
as long as the above rules are obeyed.
Table 6 lists the interpretation of all the 20 media type Table 6 lists the interpretation of all the media type parameters
parameters that MUST be used for the different direction attributes. that MUST be used for the different direction attributes.
Table 6. Interpretation of parameters for different direction Table 6. Interpretation of parameters for different direction
attributes. attributes.
sendonly --+ sendonly --+
recvonly --+ | recvonly --+ |
sendrecv --+ | | sendrecv --+ | |
| | | | | |
profile-level-id C C P profile-level-id C C P
max-recv-level R R -
packetization-mode C C P packetization-mode C C P
sprop-deint-buf-req P - P sprop-deint-buf-req P - P
sprop-interleaving-depth P - P sprop-interleaving-depth P - P
sprop-max-don-diff P - P sprop-max-don-diff P - P
sprop-init-buf-time P - P sprop-init-buf-time P - P
max-mbps R R - max-mbps R R -
max-smbps R R - max-smbps R R -
max-fs R R - max-fs R R -
max-cpb R R - max-cpb R R -
max-dpb R R - max-dpb R R -
max-br R R - max-br R R -
redundant-pic-cap R R - redundant-pic-cap R R -
deint-buf-cap R R - deint-buf-cap R R -
max-rcmd-nalu-size R R - max-rcmd-nalu-size R R -
sar-understood R R - sar-understood R R -
sar-supported R R - sar-supported R R -
in-band-parameter-sets R R - in-band-parameter-sets R R -
use-level-src-parameter-sets R R - use-level-src-parameter-sets R R -
level-asymmetry-allowed O - -
sprop-parameter-sets S - S sprop-parameter-sets S - S
sprop-level-parameter-sets S - S sprop-level-parameter-sets S - S
Legend: Legend:
C: configuration for sending and receiving streams C: configuration for sending and receiving streams
O: offer/answer mode
P: properties of the stream to be sent P: properties of the stream to be sent
R: receiver capabilities R: receiver capabilities
S: out-of-band parameter sets S: out-of-band parameter sets
-: not usable, when present SHOULD be ignored -: not usable, when present SHOULD be ignored
Parameters used for declaring receiver capabilities are in general Parameters used for declaring receiver capabilities are in general
downgradable; i.e., they express the upper limit for a sender's downgradable; i.e., they express the upper limit for a sender's
possible behavior. Thus a sender MAY select to set its encoder possible behavior. Thus a sender MAY select to set its encoder
using only lower/less or equal values of these parameters. using only lower/less or equal values of these parameters.
Parameters declaring a configuration point are not downgradable, Parameters declaring a configuration point are not changeable, with
with the exception of the level part of the "profile-level-id" the exception of the level part of the "profile-level-id" parameter
parameter for unicast usage. This expresses values a receiver for unicast usage. This expresses values a receiver expects to be
expects to be used and must be used verbatim on the sender side. used and must be used verbatim on the sender side.
When a sender's capabilities are declared, and non-downgradable When a sender's capabilities are declared, and non-downgradable
parameters are used in this declaration, then these parameters parameters are used in this declaration, then these parameters
express a configuration that is acceptable for the sender to express a configuration that is acceptable for the sender to
receive streams. In order to achieve high interoperability levels, receive streams. In order to achieve high interoperability levels,
it is often advisable to offer multiple alternative configurations; it is often advisable to offer multiple alternative configurations;
e.g., for the packetization mode. It is impossible to offer e.g., for the packetization mode. It is impossible to offer
multiple configurations in a single payload type. Thus, when multiple configurations in a single payload type. Thus, when
multiple configuration offers are made, each offer requires its own multiple configuration offers are made, each offer requires its own
RTP payload type associated with the offer. RTP payload type associated with the offer.
skipping to change at page 66, line 13 skipping to change at page 69, line 13
receiver of the offer. receiver of the offer.
An answerer MAY extend the offer with additional media format An answerer MAY extend the offer with additional media format
configurations. However, to enable their usage, in most cases a configurations. However, to enable their usage, in most cases a
second offer is required from the offerer to provide the stream second offer is required from the offerer to provide the stream
property parameters that the media sender will use. This also has property parameters that the media sender will use. This also has
the effect that the offerer has to be able to receive this media the effect that the offerer has to be able to receive this media
format configuration, not only to send it. format configuration, not only to send it.
If an offerer wishes to have non-symmetric capabilities between If an offerer wishes to have non-symmetric capabilities between
sending and receiving, the offerer should offer different RTP sending and receiving, the offerer can allow asymmetric levels via
sessions; i.e., different media lines declared as "recvonly" and "level-asymmetry-allowed" equal to 1. Alternatively, the offerer
"sendonly", respectively. This may have further implications on could offer different RTP sessions; i.e., different media lines
the system. declared as "recvonly" and "sendonly", respectively. This may have
further implications on the system, and may require additional
external semantics to associate the two media lines.
8.2.3. Usage in Declarative Session Descriptions 8.2.3. Usage in Declarative Session Descriptions
When H.264 over RTP is offered with SDP in a declarative style, as When H.264 over RTP is offered with SDP in a declarative style, as
in RTSP [27] or SAP [28], the following considerations are in RTSP [27] or SAP [28], the following considerations are
necessary. necessary.
o All parameters capable of indicating both stream properties and o All parameters capable of indicating both stream properties and
receiver capabilities are used to indicate only stream receiver capabilities are used to indicate only stream
properties. For example, in this case, the parameter "profile- properties. For example, in this case, the parameter "profile-
skipping to change at page 67, line 6 skipping to change at page 70, line 8
- sprop-level-parameter-sets - sprop-level-parameter-sets
Not usable(when present, they SHOULD be ignored): Not usable(when present, they SHOULD be ignored):
- max-mbps - max-mbps
- max-smbps - max-smbps
- max-fs - max-fs
- max-cpb - max-cpb
- max-dpb - max-dpb
- max-br - max-br
- max-recv-level
- redundant-pic-cap - redundant-pic-cap
- max-rcmd-nalu-size - max-rcmd-nalu-size
- deint-buf-cap - deint-buf-cap
- sar-understood - sar-understood
- sar-supported - sar-supported
- in-band-parameter-sets - in-band-parameter-sets
- level-asymmetry-allowed
- use-level-src-parameter-sets - use-level-src-parameter-sets
o A receiver of the SDP is required to support all parameters and o A receiver of the SDP is required to support all parameters and
values of the parameters provided; otherwise, the receiver MUST values of the parameters provided; otherwise, the receiver MUST
reject (RTSP) or not participate in (SAP) the session. It falls reject (RTSP) or not participate in (SAP) the session. It falls
on the creator of the session to use values that are expected to on the creator of the session to use values that are expected to
be supported by the receiving application. be supported by the receiving application.
8.3. Examples 8.3. Examples
skipping to change at page 72, line 44 skipping to change at page 76, line 4
parameter-sets" is present in the offer, meaning that there is no parameter-sets" is present in the offer, meaning that there is no
out-of-band transmission of parameter sets, which then have to be out-of-band transmission of parameter sets, which then have to be
transported in-band. transported in-band.
Offer SDP: Offer SDP:
m=video 49170 RTP/AVP 98 m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0 a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
packetization-mode=1 packetization-mode=1
Answer SDP: Answer SDP:
m=video 49170 RTP/AVP 98 m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000 a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0 a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0
packetization-mode=1 packetization-mode=1
In the following example, the offer is accepted with level
upgrading, and neither "sprop-parameter-sets" nor "sprop-level-
parameter-sets" is present in the offer or the answer, meaning that
there is no out-of-band transmission of parameter sets, which then
have to be transported in-band. The level to use in the offerer-
to-answerer direction is Level 3.0, and the level to use in the
answerer-to-offerer direction is Level 2.0. The answerer is
allowed to send at any level up to and including level 2.0, and the
offerer is allowed to send at any level up to and including level
3.0.
Offer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0
packetization-mode=1; level-asymmetry-allowed=1
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
packetization-mode=1; level-asymmetry-allowed=1
In the following example, the offerer is a Multipoint Control Unit In the following example, the offerer is a Multipoint Control Unit
(MCU) in a Topo-Video-switch-MCU like topology [29], offering (MCU) in a Topo-Video-switch-MCU like topology [29], offering
parameter sets received (using out-of-band transport) from three parameter sets received (using out-of-band transport) from three
other participants B, C, and D, and receiving parameter sets from other participants B, C, and D, and receiving parameter sets from
the participant A, which is the answerer. The participants are the participant A, which is the answerer. The participants are
identified by their values of CNAME, which are mapped to different identified by their values of CNAME, which are mapped to different
SSRC values. The same codec configuration is used by all the four SSRC values. The same codec configuration is used by all the four
participants. The participant A stores and associates the participants. The participant A stores and associates the
parameter sets included in <parameter sets data#B>, <parameter sets parameter sets included in <parameter sets data#B>, <parameter sets
data#C>, and <parameter sets data#D> to participants B, C, and D, data#C>, and <parameter sets data#D> to participants B, C, and D,
skipping to change at page 93, line 42 skipping to change at page 97, line 21
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. 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, Thomas Schierl, and Tom Taylor are Westerlund, Alex Eleftheriadis, Thomas Schierl, Tom Taylor, Ali
thanked for their valuable comments and inputs during the Begen, and Aaron Wells are thanked for their valuable comments and
development of this memo. 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 15. References
15.1. Normative References 15.1. Normative References
[1] ITU-T Recommendation H.264, "Advanced video coding for [1] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services", November 2007. generic audiovisual services", November 2007.
skipping to change at page 97, line 4 skipping to change at page 100, line 23
Phone: +1-908-541-3518 Phone: +1-908-541-3518
EMail: yekuiwang@huawei.com EMail: yekuiwang@huawei.com
Roni Even Roni Even
14 David Hamelech 14 David Hamelech
Tel Aviv 64953 Tel Aviv 64953
Israel Israel
Phone: +972-545481099 Phone: +972-545481099
Email: ron.even.tlv@gmail.com Email: ron.even.tlv@gmail.com
Tom Kristensen Tom Kristensen
TANDBERG TANDBERG
Philip Pedersens vei 22 Philip Pedersens vei 22
N-1366 Lysaker N-1366 Lysaker
Norway Norway
Phone: +47 67125125 Phone: +47 67125125
Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no
Randell Jesup
WorldGate Communications
3190 Tremont Ave
Trevose, PA 19053
USA
Phone: +1-215-354-5166
Email: rjesup@wgate.com
17. Backward Compatibility to RFC 3984 17. Backward Compatibility to RFC 3984
The current document is a revision of RFC 3984 and intends to The current document is a revision of RFC 3984 and intends to
obsolete it. This section addresses the backward compatibility obsolete it. This section addresses the backward compatibility
issues. issues.
The technical changes are listed in section 18. The technical changes are listed in section 18.
Items 1), 2), 3), 7), 9), 10), 12), 13) are bug-fix type of changes, Items 1), 2), 3), 7), 9), 10), 12), 13) are bug-fix type of changes,
and do not incur any backward compatibility issues. and do not incur any backward compatibility issues.
skipping to change at page 98, line 37 skipping to change at page 102, line 21
receivers according to this memo. receivers according to this memo.
Item 14) removed that use of out-of-band transport of parameter Item 14) removed that use of out-of-band transport of parameter
sets is recommended. As out-of-band transport of parameter sets is sets is recommended. As out-of-band transport of parameter sets is
still allowed, this change does not incur any backward still allowed, this change does not incur any backward
compatibility issues. compatibility issues.
Item 15) does not incur any backward compatibility issues as the Item 15) does not incur any backward compatibility issues as the
added subsection 8.5 is informative. 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 18. Changes from RFC 3984
Following is the list of technical changes (including bug fixes) Following is the list of technical changes (including bug fixes)
from RFC 3984. Besides this list of technical changes, numerous from RFC 3984. Besides this list of technical changes, numerous
editorial changes have been made, but not documented in this memo. 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 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. packetization mode in use may be signaled by external means.
2) In subsection 7.2.2, changed the sentence 2) In subsection 7.2.2, changed the sentence
skipping to change at page 99, line 26 skipping to change at page 103, line 15
arrives. arrives.
to to
The parameter is the maximum value of (decoding time of the NAL The parameter is the maximum value of (decoding time of the NAL
unit - transmission time of a NAL unit), assuming reliable and unit - transmission time of a NAL unit), assuming reliable and
instantaneous transmission, the same timeline for transmission instantaneous transmission, the same timeline for transmission
and decoding, and that decoding starts when the first packet and decoding, and that decoding starts when the first packet
arrives. arrives.
4) Added six new media type parameters, namely max-smbps, sprop- 4) Added media type parameters max-smbps, sprop-level-parameter-
level-parameter-sets, use-level-src-parameter-sets, in-band- sets, use-level-src-parameter-sets, in-band-parameter-sets, sar-
parameter-sets, sar-understood and sar-supported. understood and sar-supported.
5) In subsection 8.1, removed the specification of parameter-add. 5) In subsection 8.1, removed the specification of parameter-add.
Other descriptions of parameter-add (in subsections 8.2 and 8.4) Other descriptions of parameter-add (in subsections 8.2 and 8.4)
are also removed. are also removed.
6) In subsection 8.1, added a constraint to sprop-parameter-sets 6) In subsection 8.1, added a constraint to sprop-parameter-sets
such that it can only contain parameter sets for the same such that it can only contain parameter sets for the same
profile and level as indicated by profile-level-id. profile and level as indicated by profile-level-id.
7) In subsection 8.2.1, added that sprop-parameter-sets and sprop- 7) In subsection 8.2.1, added that sprop-parameter-sets and sprop-
skipping to change at line 4463 skipping to change at page 104, line 19
different media type parameters shall be interpreted in the different media type parameters shall be interpreted in the
different combinations of offer or answer and direction different combinations of offer or answer and direction
attribute. attribute.
14)In subsection 8.4, changed the text such that both out-of-band 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 and in-band transport of parameter sets are allowed and neither
is recommended or required. is recommended or required.
15)Added subsection 8.5 (informative) providing example methods for 15)Added subsection 8.5 (informative) providing example methods for
decoder refresh to handle parameter set losses. 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. 91 change blocks. 
306 lines changed or deleted 491 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/