draft-ietf-avt-rtp-rfc3984bis-00.txt   draft-ietf-avt-rtp-rfc3984bis-01.txt 
Audio/Video Transport WG Y.-K. Wang Audio/Video Transport WG Y.-K. Wang
Internet Draft Nokia Internet Draft Nokia
Intended status: Standards track R. Even Intended status: Standards track R. Even
Expires: April 2009 Self-employed Expires: May 2009 Self-employed
T. Kristensen T. Kristensen
Tanberg Tandberg
October 6, 2008 November 3, 2008
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-00.txt draft-ietf-avt-rtp-rfc3984bis-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 6, 2009. This Internet-Draft will expire on May 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo describes an RTP Payload format for the ITU-T This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec. The RTP payload ISO/IEC International Standard 14496-10 video codec, excluding the
format allows for packetization of one or more Network Abstraction Scalable Video Coding (SVC) extension and the Multivew Video Coding
Layer Units (NALUs), produced by an H.264 video encoder, in each RTP extension, for which the RTP payload formats are defined elsewhere.
payload. The payload format has wide applicability, as it supports
applications from simple low bit-rate conversational usage, to
Internet video streaming with interleaved transmission, to high bit-
rate video-on-demand.
This memo intends to obsolete RFC 3984. The RTP payload format allows for packetization of one or more
Network Abstraction Layer Units (NALUs), produced by an H.264 video
encoder, in each RTP payload. The payload format has wide
applicability, as it supports applications from simple low bit-rate
conversational usage, to Internet video streaming with interleaved
transmission, to high bit-rate video-on-demand.
This memo intends to obsolete RFC 3984. Changes from RFC 3984 are
summarized in section 17. Issues on backward compatibility to RFC
3984 are discussed in section 16.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1. The H.264 Codec...........................................4 1.1. The H.264 Codec...........................................4
1.2. Parameter Set Concept.....................................5 1.2. Parameter Set Concept.....................................5
1.3. Network Abstraction Layer Unit Types......................6 1.3. Network Abstraction Layer Unit Types......................6
2. Conventions....................................................7 2. Conventions....................................................7
3. Scope..........................................................7 3. Scope..........................................................7
4. Definitions and Abbreviations..................................7 4. Definitions and Abbreviations..................................7
4.1. Definitions...............................................7 4.1. Definitions...............................................7
4.2. Abbreviations.............................................9 4.2. Abbreviations.............................................9
5. RTP Payload Format............................................10 5. RTP Payload Format............................................10
5.1. RTP Header Usage.........................................10 5.1. RTP Header Usage.........................................10
5.2. Payload Structures.......................................12 5.2. Payload Structures.......................................13
5.3. NAL Unit Header Usage....................................13 5.3. NAL Unit Header Usage....................................14
5.4. Packetization Modes......................................16 5.4. Packetization Modes......................................16
5.5. Decoding Order Number (DON)..............................17 5.5. Decoding Order Number (DON)..............................17
5.6. Single NAL Unit Packet...................................19 5.6. Single NAL Unit Packet...................................20
5.7. Aggregation Packets......................................20 5.7. Aggregation Packets......................................21
5.7.1. Single-Time Aggregation Packet......................22 5.7.1. Single-Time Aggregation Packet......................23
5.7.2. Multi-Time Aggregation Packets (MTAPs)..............24 5.7.2. Multi-Time Aggregation Packets (MTAPs)..............25
5.7.3. Fragmentation Units (FUs)...........................28 5.7.3. Fragmentation Units (FUs)...........................29
6. Packetization Rules...........................................32 6. Packetization Rules...........................................33
6.1. Common Packetization Rules...............................32 6.1. Common Packetization Rules...............................33
6.2. Single NAL Unit Mode.....................................33 6.2. Single NAL Unit Mode.....................................34
6.3. Non-Interleaved Mode.....................................33 6.3. Non-Interleaved Mode.....................................34
6.4. Interleaved Mode.........................................33 6.4. Interleaved Mode.........................................34
7. De-Packetization Process......................................34 7. De-Packetization Process......................................35
7.1. Single NAL Unit and Non-Interleaved Mode.................34 7.1. Single NAL Unit and Non-Interleaved Mode.................35
7.2. Interleaved Mode.........................................34 7.2. Interleaved Mode.........................................35
7.2.1. Size of the Deinterleaving Buffer...................35 7.2.1. Size of the De-interleaving Buffer..................36
7.2.2. Deinterleaving Process..............................35 7.2.2. De-interleaving Process.............................36
7.3. Additional De-Packetization Guidelines...................37 7.3. Additional De-Packetization Guidelines...................38
8. Payload Format Parameters.....................................38 8. Payload Format Parameters.....................................39
8.1. Media Type Registration..................................38 8.1. Media Type Registration..................................39
8.2. SDP Parameters...........................................56 8.2. SDP Parameters...........................................55
8.2.1. Mapping of Payload Type Parameters to SDP...........56 8.2.1. Mapping of Payload Type Parameters to SDP...........55
8.2.2. Usage with the SDP Offer/Answer Model...............56 8.2.2. Usage with the SDP Offer/Answer Model...............56
8.2.3. Usage in Declarative Session Descriptions...........64 8.2.3. Usage in Declarative Session Descriptions...........64
8.3. Examples.................................................65 8.3. Examples.................................................65
8.4. Parameter Set Considerations.............................69 8.4. Parameter Set Considerations.............................70
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)..................................72 Parameter Sets (Informative)..................................73
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..............................................72 Refresh Point..............................................73
8.5.2. Gradual Recovery Procedure to Respond to a Request for a 8.5.2. Gradual Recovery Procedure to Respond to a Request for a
Decoder Refresh Point......................................72 Decoder Refresh Point......................................74
9. Security Considerations.......................................73 9. Security Considerations.......................................74
10. Congestion Control...........................................74 10. Congestion Control...........................................75
11. IANA Consideration...........................................75 11. IANA Consideration...........................................76
12. Informative Appendix: Application Examples...................75 12. Informative Appendix: Application Examples...................76
12.1. Video Telephony according to ITU-T Recommendation H.241 12.1. Video Telephony according to ITU-T Recommendation H.241
Annex A.......................................................75 Annex A.......................................................76
12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit 12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit
Aggregation...................................................75 Aggregation...................................................77
12.3. Video Telephony, Interleaved Packetization Using NAL Unit 12.3. Video Telephony, Interleaved Packetization Using NAL Unit
Aggregation...................................................76 Aggregation...................................................77
12.4. Video Telephony with Data Partitioning..................77 12.4. Video Telephony with Data Partitioning..................78
12.5. Video Telephony or Streaming with FUs and Forward Error 12.5. Video Telephony or Streaming with FUs and Forward Error
Correction....................................................77 Correction....................................................78
12.6. Low Bit-Rate Streaming..................................80 12.6. Low Bit-Rate Streaming..................................81
12.7. Robust Packet Scheduling in Video Streaming.............80 12.7. Robust Packet Scheduling in Video Streaming.............81
13. Informative Appendix: Rationale for Decoding Order Number....81 13. Informative Appendix: Rationale for Decoding Order Number....82
13.1. Introduction............................................81 13.1. Introduction............................................82
13.2. Example of Multi-Picture Slice Interleaving.............81 13.2. Example of Multi-Picture Slice Interleaving.............83
13.3. Example of Robust Packet Scheduling.....................83 13.3. Example of Robust Packet Scheduling.....................84
13.4. Robust Transmission Scheduling of Redundant Coded Slices87 13.4. Robust Transmission Scheduling of Redundant Coded Slices88
13.5. Remarks on Other Design Possibilities...................87 13.5. Remarks on Other Design Possibilities...................89
14. Acknowledgements.............................................88 14. Acknowledgements.............................................89
15. References...................................................88 15. References...................................................90
15.1. Normative References....................................88 15.1. Normative References....................................90
15.2. Informative References..................................89 15.2. Informative References..................................90
Authors' Addresses...............................................91 Authors' Addresses...............................................92
Intellectual Property Statement..................................91 Intellectual Property Statement..................................93
Disclaimer of Validity...........................................92 Disclaimer of Validity...........................................93
Acknowledgement..................................................92 Acknowledgement..................................................93
16. Backward compatibility to RFC 3984...........................92 16. Backward Compatibility to RFC 3984...........................94
17. Changes from RFC 3984........................................92 17. Changes from RFC 3984........................................95
17.1. Technical changes.......................................92 18. Open issues..................................................96
17.2. Editorial changes.......................................95
18. Open issues.................................................106
19. Changes Log.................................................107
1. Introduction 1. Introduction
This memo intends to obsolete RFC 3984. [Ed. (YkW): Add a brief This memo intends to obsolete RFC 3984. Changes from RFC 3984 are
summary of the changes to RFC 3984.] summarized in section 17. Issues on backward compatibility to RFC
3984 are discussed in section 16.
1.1. The H.264 Codec 1.1. The H.264 Codec
This memo specifies an RTP payload specification for the video coding This memo specifies an RTP payload specification for the video coding
standard known as ITU-T Recommendation H.264 [1] and ISO/IEC standard known as ITU-T Recommendation H.264 [1] and ISO/IEC
International Standard 14496 Part 10 [2] (both also known as Advanced International Standard 14496 Part 10 [2] (both also known as Advanced
Video Coding, or AVC). In this memo the H.264 acronym is used for Video Coding, or AVC). In this memo the H.264 acronym is used for
the codec and the standard, but the memo is equally applicable to the the codec and the standard, but the memo is equally applicable to the
ISO/IEC counterpart of the coding standard. ISO/IEC counterpart of the coding standard.
skipping to change at page 9, line 30 skipping to change at page 9, line 35
and/or keep the delay low. and/or keep the delay low.
static macroblock: A certain amount of macroblocks in the video static macroblock: A certain amount of macroblocks in the video
stream can be defined as static, as defined in section 8.3.2.8 in stream can be defined as static, as defined in section 8.3.2.8 in
[3]. Static macroblocks free up additional processing cycles for [3]. Static macroblocks free up additional processing cycles for
the handling of non-static macroblocks. Based on a given amount the handling of non-static macroblocks. Based on a given amount
of video processing resources and a given resolution, a higher of video processing resources and a given resolution, a higher
number of static macroblocks enables a correspondingly higher number of static macroblocks enables a correspondingly higher
frame rate. frame rate.
default sub-profile: The subset of coding tools, which may be all
coding tools of one profile or the common subset of coding tools
of more than one profile, indicated by the profile-level-id
parameter. In SDP Offer/Answer, the default sub-profile must be
used in a symmetric manner, i.e. the answer must either use the
same sub-profile as the offer or reject the offer.
default level: The level indicated by the profile-level-id
parameter. In SDP Offer/Answer, level is downgradable, i.e., the
answer may either use the default level or a lower level.
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 22 skipping to change at page 13, line 8
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 Informative note: Because H.264 allows the decoding order to
be different from the display order, values of RTP timestamps be different from the display order, values of RTP timestamps
may not be monotonically non-decreasing as a function of RTP may not be monotonically non-decreasing as a function of RTP
sequence numbers. Furthermore, the value for interarrival sequence numbers. Furthermore, the value for inter-arrival
jitter reported in the RTCP reports may not be a trustworthy jitter reported in the RTCP reports may not be a trustworthy
indication of the network performance, as the calculation indication of the network performance, as the calculation
rules for interarrival jitter (section 6.4.1 of RFC 3550) rules for inter-arrival jitter (section 6.4.1 of RFC 3550)
assume that the RTP timestamp of a packet is directly assume that the RTP timestamp of a packet is directly
proportional to its transmission time. 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
skipping to change at page 16, line 51 skipping to change at page 17, line 34
26 MTAP16 no no yes 26 MTAP16 no no yes
27 MTAP24 no no yes 27 MTAP24 no no yes
28 FU-A no yes yes 28 FU-A no yes yes
29 FU-B no no yes 29 FU-B no no yes
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 SHOULD be ignored by a receiver. For example, the in FU packets) and MUST be ignored by a receiver. For example, the
payload types 1-23, with the associated packet type "NAL unit", are payload types 1-23, with the associated packet type "NAL unit", are
allowed in "Single NAL Unit Mode" and in "Non-Interleaved Mode", but allowed in "Single NAL Unit Mode" and in "Non-Interleaved Mode", but
disallowed in "Interleaved Mode". However, NAL units of NAL unit disallowed in "Interleaved Mode". However, NAL units of NAL unit
types 1-23 can be used in "Interleaved Mode" as aggregation units in types 1-23 can be used in "Interleaved Mode" as aggregation units in
STAP-B, MTAP16 and MTAP14 packets as well as fragmented units in FU-A STAP-B, MTAP16 and MTAP14 packets as well as fragmented units in FU-A
and FU-B packets. Similarly, NAL units of NAL unit types 1-23 can and FU-B packets. Similarly, NAL units of NAL unit types 1-23 can
also be used in the "Non-Interleaved Mode" as aggregation units in also be used in the "Non-Interleaved Mode" as aggregation units in
STAP-A packets or fragmented units in FU-A packets, in addition to STAP-A packets or fragmented units in FU-A packets, in addition to
being directly used as packet payloads. being directly used as packet payloads.
skipping to change at page 17, line 34 skipping to change at page 18, line 19
OPTIONAL sprop-interleaving-depth media type parameter as follows. OPTIONAL sprop-interleaving-depth media type parameter as follows.
When the value of the OPTIONAL sprop-interleaving-depth media type When the value of the OPTIONAL sprop-interleaving-depth media type
parameter is equal to 0 (explicitly or per default), the transmission parameter is equal to 0 (explicitly or per default), the transmission
order of NAL units MUST conform to the NAL unit decoding order. When order of NAL units MUST conform to the NAL unit decoding order. When
the value of the OPTIONAL sprop-interleaving-depth media type the value of the OPTIONAL sprop-interleaving-depth media type
parameter is greater than 0, parameter is greater than 0,
o the order of NAL units in an MTAP16 and an MTAP24 is NOT REQUIRED o the order of NAL units in an MTAP16 and an MTAP24 is NOT REQUIRED
to be the NAL unit decoding order, and to be the NAL unit decoding order, and
o the order of NAL units generated by decapsulating STAP-Bs, MTAPs, o the order of NAL units generated by de-packetizing STAP-Bs, MTAPs,
and FUs in two consecutive packets is NOT REQUIRED to be the NAL and FUs in two consecutive packets is NOT REQUIRED to be the NAL
unit decoding order. unit decoding order.
The RTP payload structures for a single NAL unit packet, an STAP-A, The RTP payload structures for a single NAL unit packet, an STAP-A,
and an FU-A do not include DON. STAP-B and FU-B structures include and an FU-A do not include DON. STAP-B and FU-B structures include
DON, and the structure of MTAPs enables derivation of DON as DON, and the structure of MTAPs enables derivation of DON as
specified in section 5.7.2. specified in section 5.7.2.
Informative note: When an FU-A occurs in interleaved mode, it Informative note: When an FU-A occurs in interleaved mode, it
always follows an FU-B, which sets its DON. always follows an FU-B, which sets its DON.
skipping to change at page 19, line 24 skipping to change at page 20, line 5
order is allowed by the video coding profile in use, all the coded order is allowed by the video coding profile in use, all the coded
slice NAL units of a coded picture are allowed to have the same value slice NAL units of a coded picture are allowed to have the same value
of DON. Consequently, NAL units having the same value of DON can be of DON. Consequently, NAL units having the same value of DON can be
decoded in any order, and two NAL units having a different value of decoded in any order, and two NAL units having a different value of
DON should be passed to the decoder in the order specified above. DON should be passed to the decoder in the order specified above.
When two consecutive NAL units in the NAL unit decoding order have a When two consecutive NAL units in the NAL unit decoding order have a
different value of DON, the value of DON for the second NAL unit in different value of DON, the value of DON for the second NAL unit in
decoding order SHOULD be the value of DON for the first, incremented decoding order SHOULD be the value of DON for the first, incremented
by one. by one.
An example of the decapsulation process to recover the NAL unit An example of the de-packetization process to recover the NAL unit
decoding order is given in section 7. decoding order is given in section 7.
Informative note: Receivers should not expect that the absolute Informative note: Receivers should not expect that the absolute
difference of values of DON for two consecutive NAL units in the difference of values of DON for two consecutive NAL units in the
NAL unit decoding order will be equal to one, even in error-free NAL unit decoding order will be equal to one, even in error-free
transmission. An increment by one is not required, as at the transmission. An increment by one is not required, as at the
time of associating values of DON to NAL units, it may not be time of associating values of DON to NAL units, it may not be
known whether all NAL units are delivered to the receiver. For known whether all NAL units are delivered to the receiver. For
example, a gateway may not forward coded slice NAL units of non- example, a gateway may not forward coded slice NAL units of non-
reference pictures or SEI NAL units when there is a shortage of reference pictures or SEI NAL units when there is a shortage of
skipping to change at page 20, line 4 skipping to change at page 20, line 33
the pre-encoded clip follows in decoding order. Thus, the values the pre-encoded clip follows in decoding order. Thus, the values
of DON for the NAL units of the first intra picture of the pre- of DON for the NAL units of the first intra picture of the pre-
encoded clip have to be estimated when they are transmitted, and encoded clip have to be estimated when they are transmitted, and
gaps in values of DON may occur. gaps in values of DON may occur.
5.6. Single NAL Unit Packet 5.6. Single NAL Unit Packet
The single NAL unit packet defined here MUST contain only one NAL The single NAL unit packet defined here MUST contain only one NAL
unit, of the types defined in [1]. This means that neither an unit, of the types defined in [1]. This means that neither an
aggregation packet nor a fragmentation unit can be used within a aggregation packet nor a fragmentation unit can be used within a
single NAL unit packet. A NAL unit stream composed by decapsulating single NAL unit packet. A NAL unit stream composed by de-packetizing
single NAL unit packets in RTP sequence number order MUST conform to single NAL unit packets in RTP sequence number order MUST conform to
the NAL unit decoding order. The structure of the single NAL unit the NAL unit decoding order. The structure of the single NAL unit
packet is shown in Figure 2. packet is shown in Figure 2.
Informative note: The first byte of a NAL unit co-serves as the Informative note: The first byte of a NAL unit co-serves as the
RTP payload header. RTP payload header.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 31, line 13 skipping to change at page 32, line 13
zero. zero.
E: 1 bit E: 1 bit
When set to one, the End bit indicates the end of a fragmented When set to one, the End bit indicates the end of a fragmented
NAL unit, i.e., the last byte of the payload is also the last NAL unit, i.e., the last byte of the payload is also the last
byte of the fragmented NAL unit. When the following FU payload byte of the fragmented NAL unit. When the following FU payload
is not the last fragment of a fragmented NAL unit, the End bit is is not the last fragment of a fragmented NAL unit, the End bit is
set to zero. set to zero.
R: 1 bit R: 1 bit
The Reserved bit MUST be equal to 0 and SHOULD be ignored by the The Reserved bit MUST be equal to 0 and MUST be ignored by the
receiver. receiver.
Type: 5 bits Type: 5 bits
The NAL unit payload type as defined in Table 7-1 of [1]. The NAL unit payload type as defined in Table 7-1 of [1].
The value of DON in FU-Bs is selected as described in section 5.5. The value of DON in FU-Bs is selected as described in section 5.5.
Informative note: The DON field in FU-Bs allows gateways to Informative note: The DON field in FU-Bs allows gateways to
fragment NAL units to FU-Bs without organizing the incoming NAL fragment NAL units to FU-Bs without organizing the incoming NAL
units to the NAL unit decoding order. units to the NAL unit decoding order.
skipping to change at page 34, line 16 skipping to change at page 35, line 16
The de-packetization process is implementation dependent. Therefore, The de-packetization process is implementation dependent. Therefore,
the following description should be seen as an example of a suitable the following description should be seen as an example of a suitable
implementation. Other schemes may be used as well as long as the implementation. Other schemes may be used as well as long as the
output for the same input is the same as the process described below. output for the same input is the same as the process described below.
The output is the same meaning that the number of NAL units and their The output is the same meaning that the number of NAL units and their
order are both the identical. Optimizations relative to the order are both the identical. Optimizations relative to the
described algorithms are likely possible. Section 7.1 presents the described algorithms are likely possible. Section 7.1 presents the
de-packetization process for the single NAL unit and non-interleaved de-packetization process for the single NAL unit and non-interleaved
packetization modes, whereas section 7.2 describes the process for packetization modes, whereas section 7.2 describes the process for
the interleaved mode. Section 7.3 includes additional decapsulation the interleaved mode. Section 7.3 includes additional de-
guidelines for intelligent receivers. packetization guidelines for intelligent receivers.
All normal RTP mechanisms related to buffer management apply. In All normal RTP mechanisms related to buffer management apply. In
particular, duplicated or outdated RTP packets (as indicated by the particular, duplicated or outdated RTP packets (as indicated by the
RTP sequences number and the RTP timestamp) are removed. To RTP sequences number and the RTP timestamp) are removed. To
determine the exact time for decoding, factors such as a possible determine the exact time for decoding, factors such as a possible
intentional delay to allow for proper inter-stream synchronization intentional delay to allow for proper inter-stream synchronization
must be factored in. must be factored in.
7.1. Single NAL Unit and Non-Interleaved Mode 7.1. Single NAL Unit and Non-Interleaved Mode
The receiver includes a receiver buffer to compensate for The receiver includes a receiver buffer to compensate for
transmission delay jitter. The receiver stores incoming packets in transmission delay jitter. The receiver stores incoming packets in
reception order into the receiver buffer. Packets are decapsulated reception order into the receiver buffer. Packets are de-packetized
in RTP sequence number order. If a decapsulated packet is a single in RTP sequence number order. If a de-packetized packet is a single
NAL unit packet, the NAL unit contained in the packet is passed NAL unit packet, the NAL unit contained in the packet is passed
directly to the decoder. If a decapsulated packet is an STAP-A, the directly to the decoder. If a de-packetized packet is an STAP-A, the
NAL units contained in the packet are passed to the decoder in the NAL units contained in the packet are passed to the decoder in the
order in which they are encapsulated in the packet. For all the FU-A order in which they are encapsulated in the packet. For all the FU-A
packets containing fragments of a single NAL unit, the decapsulated packets containing fragments of a single NAL unit, the de-packetized
fragments are concatenated in their sending order to recover the NAL fragments are concatenated in their sending order to recover the NAL
unit, which is then passed to the decoder. unit, which is then passed to the decoder.
Informative note: If the decoder supports Arbitrary Slice Order, Informative note: If the decoder supports Arbitrary Slice Order,
coded slices of a picture can be passed to the decoder in any coded slices of a picture can be passed to the decoder in any
order regardless of their reception and transmission order. order regardless of their reception and transmission order.
7.2. Interleaved Mode 7.2. Interleaved Mode
The general concept behind these de-packetization rules is to reorder The general concept behind these de-packetization rules is to reorder
NAL units from transmission order to the NAL unit decoding order. NAL units from transmission order to the NAL unit decoding order.
The receiver includes a receiver buffer, which is used to compensate The receiver includes a receiver buffer, which is used to compensate
for transmission delay jitter and to reorder NAL units from for transmission delay jitter and to reorder NAL units from
transmission order to the NAL unit decoding order. In this section, transmission order to the NAL unit decoding order. In this section,
the receiver operation is described under the assumption that there the receiver operation is described under the assumption that there
is no transmission delay jitter. To make a difference from a is no transmission delay jitter. To make a difference from a
practical receiver buffer that is also used for compensation of practical receiver buffer that is also used for compensation of
transmission delay jitter, the receiver buffer is here after called transmission delay jitter, the receiver buffer is here after called
the deinterleaving buffer in this section. Receivers SHOULD also the de-interleaving buffer in this section. Receivers SHOULD also
prepare for transmission delay jitter; i.e., either reserve separate prepare for transmission delay jitter; i.e., either reserve separate
buffers for transmission delay jitter buffering and deinterleaving buffers for transmission delay jitter buffering and de-interleaving
buffering or use a receiver buffer for both transmission delay jitter buffering or use a receiver buffer for both transmission delay jitter
and deinterleaving. Moreover, receivers SHOULD take transmission and de-interleaving. Moreover, receivers SHOULD take transmission
delay jitter into account in the buffering operation; e.g., by delay jitter into account in the buffering operation; e.g., by
additional initial buffering before starting of decoding and additional initial buffering before starting of decoding and
playback. playback.
This section is organized as follows: subsection 7.2.1 presents how o This section is organized as follows: subsection 7.2.1 presents how o
calculate the size of the deinterleaving buffer. Subsection 7.2.2 calculate the size of the de-interleaving buffer. Subsection 7.2.2
specifies the receiver process how to organize received NAL units to specifies the receiver process how to organize received NAL units to
the NAL unit decoding order. the NAL unit decoding order.
7.2.1. Size of the Deinterleaving Buffer 7.2.1. Size of the De-interleaving Buffer
When SDP Offer/Answer model or any other capability exchange When the SDP Offer/Answer model or any other capability exchange
procedure is used in session setup, the properties of the received procedure is used in session setup, the properties of the received
stream SHOULD be such that the receiver capabilities are not stream SHOULD be such that the receiver capabilities are not
exceeded. In the SDP Offer/Answer model, the receiver can indicate exceeded. In the SDP Offer/Answer model, the receiver can indicate
its capabilities to allocate a deinterleaving buffer with the deint- its capabilities to allocate a de-interleaving buffer with the deint-
buf-cap media type parameter. The sender indicates the requirement buf-cap media type parameter. The sender indicates the requirement
for the deinterleaving buffer size with the sprop-deint-buf-req media for the de-interleaving buffer size with the sprop-deint-buf-req
type parameter. It is therefore RECOMMENDED to set the media type parameter. It is therefore RECOMMENDED to set the de-
deinterleaving buffer size, in terms of number of bytes, equal to or interleaving buffer size, in terms of number of bytes, equal to or
greater than the value of sprop-deint-buf-req media type parameter. greater than the value of sprop-deint-buf-req media type parameter.
See section 8.1 for further information on deint-buf-cap and sprop- See section 8.1 for further information on deint-buf-cap and sprop-
deint-buf-req media type parameters and section 8.2.2 for further deint-buf-req media type parameters and section 8.2.2 for further
information on their use in SDP Offer/Answer model. information on their use in the SDP Offer/Answer model.
When a declarative session description is used in session setup, the When a declarative session description is used in session setup, the
sprop-deint-buf-req media type parameter signals the requirement for sprop-deint-buf-req media type parameter signals the requirement for
the deinterleaving buffer size. It is therefore RECOMMENDED to set the de-interleaving buffer size. It is therefore RECOMMENDED to set
the deinterleaving buffer size, in terms of number of bytes, equal to the de-interleaving buffer size, in terms of number of bytes, equal
or greater than the value of sprop-deint-buf-req media type to or greater than the value of sprop-deint-buf-req media type
parameter. parameter.
7.2.2. Deinterleaving Process 7.2.2. De-interleaving Process
There are two buffering states in the receiver: initial buffering and There are two buffering states in the receiver: initial buffering and
buffering while playing. Initial buffering occurs when the RTP buffering while playing. Initial buffering occurs when the RTP
session is initialized. After initial buffering, decoding and session is initialized. After initial buffering, decoding and
playback are started, and the buffering-while-playing mode is used. playback are started, and the buffering-while-playing mode is used.
Regardless of the buffering state, the receiver stores incoming NAL Regardless of the buffering state, the receiver stores incoming NAL
units, in reception order, in the deinterleaving buffer as follows. units, in reception order, in the de-interleaving buffer as follows.
NAL units of aggregation packets are stored in the deinterleaving NAL units of aggregation packets are stored in the de-interleaving
buffer individually. The value of DON is calculated and stored for buffer individually. The value of DON is calculated and stored for
each NAL unit. each NAL unit.
The receiver operation is described below with the help of the The receiver operation is described below with the help of the
following functions and constants: following functions and constants:
o Function AbsDON is specified in section 8.1. o Function AbsDON is specified in section 8.1.
o Function don_diff is specified in section 5.5. o Function don_diff is specified in section 5.5.
o Constant N is the value of the OPTIONAL sprop-interleaving-depth o Constant N is the value of the OPTIONAL sprop-interleaving-depth
media type type parameter (see section 8.1) incremented by 1. media type type parameter (see section 8.1) incremented by 1.
Initial buffering lasts until one of the following conditions is Initial buffering lasts until one of the following conditions is
fulfilled: fulfilled:
o There are N or more VCL NAL units in the deinterleaving buffer. o There are N or more VCL NAL units in the de-interleaving buffer.
o If sprop-max-don-diff is present, don_diff(m,n) is greater than o If sprop-max-don-diff is present, don_diff(m,n) is greater than
the value of sprop-max-don-diff, in which n corresponds to the NAL the value of sprop-max-don-diff, in which n corresponds to the NAL
unit having the greatest value of AbsDON among the received NAL unit having the greatest value of AbsDON among the received NAL
units and m corresponds to the NAL unit having the smallest value units and m corresponds to the NAL unit having the smallest value
of AbsDON among the received NAL units. of AbsDON among the received NAL units.
o Initial buffering has lasted for the duration equal to or greater o Initial buffering has lasted for the duration equal to or greater
than the value of the OPTIONAL sprop-init-buf-time media type than the value of the OPTIONAL sprop-init-buf-time media type
parameter. parameter.
The NAL units to be removed from the deinterleaving buffer are The NAL units to be removed from the de-interleaving buffer are
determined as follows: determined as follows:
o If the deinterleaving buffer contains at least N VCL NAL units, o If the de-interleaving buffer contains at least N VCL NAL units,
NAL units are removed from the deinterleaving buffer and passed to NAL units are removed from the de-interleaving buffer and passed
the decoder in the order specified below until the buffer contains to the decoder in the order specified below until the buffer
N-1 VCL NAL units. contains N-1 VCL NAL units.
o If sprop-max-don-diff is present, all NAL units m for which o If sprop-max-don-diff is present, all NAL units m for which
don_diff(m,n) is greater than sprop-max-don-diff are removed from don_diff(m,n) is greater than sprop-max-don-diff are removed from
the deinterleaving buffer and passed to the decoder in the order the de-interleaving buffer and passed to the decoder in the order
specified below. Herein, n corresponds to the NAL unit having the specified below. Herein, n corresponds to the NAL unit having the
greatest value of AbsDON among the NAL units in the deinterleaving greatest value of AbsDON among the NAL units in the de-
buffer. interleaving buffer.
The order in which NAL units are passed to the decoder is specified The order in which NAL units are passed to the decoder is specified
as follows: as follows:
o Let PDON be a variable that is initialized to 0 at the beginning o Let PDON be a variable that is initialized to 0 at the beginning
of the RTP session. of the RTP session.
o For each NAL unit associated with a value of DON, a DON distance o For each NAL unit associated with a value of DON, a DON distance
is calculated as follows. If the value of DON of the NAL unit is is calculated as follows. If the value of DON of the NAL unit is
larger than the value of PDON, the DON distance is equal to DON - larger than the value of PDON, the DON distance is equal to DON -
skipping to change at page 38, line 42 skipping to change at page 39, line 42
parameters rather than the receiver. This uncommon characteristic of parameters rather than the receiver. This uncommon characteristic of
the "sprop" parameters may not be compatible with some signaling the "sprop" parameters may not be compatible with some signaling
protocol concepts, in which case the use of these parameters SHOULD protocol concepts, in which case the use of these parameters SHOULD
be avoided. be avoided.
8.1. Media Type Registration 8.1. Media Type Registration
The media subtype for the ITU-T H.264 | ISO/IEC 14496-10 codec is The media subtype for the ITU-T H.264 | ISO/IEC 14496-10 codec is
allocated from the IETF tree. allocated from the IETF tree.
The receiver SHOULD ignore any unspecified parameter. The receiver MUST ignore any unspecified parameter.
Media Type name: video Media Type name: video
Media subtype name: H264 Media subtype name: H264
Required parameters: none Required parameters: none
OPTIONAL parameters: OPTIONAL parameters:
profile-level-id: profile-level-id:
skipping to change at page 39, line 17 skipping to change at page 40, line 17
three bytes in the sequence parameter set NAL unit specified three bytes in the sequence parameter set NAL unit specified
in [1]: 1) profile_idc, 2) a byte herein referred to as in [1]: 1) profile_idc, 2) a byte herein referred to as
profile-iop, composed of the values of constraint_set0_flag, profile-iop, composed of the values of constraint_set0_flag,
constraint_set1_flag,constraint_set2_flag, constraint_set1_flag,constraint_set2_flag,
constraint_set3_flag, and reserved_zero_4bits in bit- constraint_set3_flag, and reserved_zero_4bits in bit-
significance order, starting from the most significant bit, significance order, starting from the most significant bit,
and 3) level_idc. Note that reserved_zero_4bits is required and 3) level_idc. Note that reserved_zero_4bits is required
to be equal to 0 in [1], but other values for it may be to be equal to 0 in [1], but other values for it may be
specified in the future by ITU-T or ISO/IEC. specified in the future by ITU-T or ISO/IEC.
If the profile-level-id parameter is used to indicate The profile-level-id parameter indicates the default sub-
properties of a NAL unit stream, it indicates the profile or a profile, i.e. the subset of coding tools that may have been
common subset of coding tools of more than one profile and the used to generate the stream or the receiver supports, and the
lowest level that a decoder has to support in order to comply default level of the stream or the receiver supports.
with [1] when it decodes the stream. Bit 7 (the most
significant bit, constraint_set0_flag), bit 6
(constraint_set1_flag), and bit 5 (constraint_set2_flag) of
the profile-iop byte indicate whether the NAL unit stream also
obeys all constraints of the indicated profiles as follows.
If bit 7, bit 6, or bit 5 of profile-iop is equal to 1, all
constraints of the Baseline profile (profile_idc equal to 66),
the Main profile (profile_idc equal to 77), or the Extended
profile (profile_idc equal to 88), respectively, are obeyed in
the NAL unit stream.
When profile_idc is equal to 66, 77 or 88 (the Baseline, Main, The default sub-profile is indicated collectively by the
or Extended profile) and level_idc is equal to 11, bit 4 profile_idc byte and some fields in the profile-iop byte.
(constraint_set3_flag) of the profile-iop byte equal to 1 Depending on the values of the fields in the profile-iop byte,
indicates that the level for the NAL unit stream is level 1b. the default sub-profile may be the same set of coding tools
When profile_idc is equal to 100 or 110 (the High or High 10 supported by one profile, or a common subset of coding tools
profile), constraint_set3_flag equal to 1 indicates that all of multiple profiles, as specified in subsection 7.4.2.1.1 of
constraints of the High 10 Intra profile (identified by [1]. The default level is indicated by the level_idc byte,
profile_idc equal to 110 and constraint_set3_flag equal to 1) and, when profile_idc is equal to 66, 77 or 88 (the Baseline,
are obeyed in the NAL unit stream. When profile_idc is equal Main, or Extended profile) and level_idc is equal to 11,
to 122 (the High 4:2:2 profile), constraint_set3_flag equal to additionally by bit 4 (constraint_set3_flag) of the profile-
1 indicates that all constraints of the High 4:2:2 Intra iop byte. When profile_idc is equal to 66, 77 or 88 (the
profile (identified by profile_idc equal to 122 and Baseline, Main, or Extended profile) and level_idc is equal to
constraint_set3_flag equal to 1) are obeyed in the NAL unit 11, and bit 4 (constraint_set3_flag) of the profile-iop byte
stream. When profile_idc is equal to 244 (the High 4:4:4 is equal to 1, the default level is level 1b.
Predictive profile), constraint_set3_flag equal to 1 indicates
that all constraints of the High 4:4:4 Intra profile
(identified by profile_idc equal to 244 and
constraint_set3_flag equal to 1) are obeyed in the NAL unit
stream.
If the profile-level-id parameter is used for capability Table 5 lists all profiles defined in Annex A of [1] and, for
exchange or session setup procedure, it indicates the profile
or a common subset of coding tools of more than one profile
that the codec supports and the highest level supported. Bit
7, bit 6, bit 5, and bit 4 of the profile-iop byte indicate
whether the codec has additional limitations whereby only the
common subset of the coding tools and limitations of the
profiles signaled with the profile-iop byte and of the profile
indicated by profile_idc is supported by the codec. For
example, if a codec supports only the common subset of the
coding tools of the Baseline profile, the Main profile, and
the Extended profile at level 2.1 and below, the profile-
level-id may become 42E015, in which 42 (hexadecimal) stands
for the Baseline profile, E0 (hexadecimal) indicates that only
the common subset for all the three profiles is supported, and
15 (hexadecimal) indicates level 2.1. The common subset of
the coding tools of the Baseline profile, the Main profile,
and the Extended profile is actually equivalent to the coding
tools of the Constrained Baseline profile, for which the
combination of profile_idc and profile-iop may be any of those
corresponding to the Constrained Baseline profile in Table 5,
which lists all profiles defined in Annex A of [1] and, for
each of the profiles, the possible combinations of profile_idc each of the profiles, the possible combinations of profile_idc
and profile-iop that represent the same set of coding tools and profile-iop that represent the same sub-profile.
supported by the profile.
Table 5. List of all profiles defined in Annex A of [1] Table 5. Combinations of profile_idc and profile-iop
and the possible combinations of profile_idc and profile- representing the same sub-profile corresponding to the full
iop representing the same set of coding tools. In the set of coding tools supported by one profile. In the
following, x may be either 0 or 1, and other notions as following, x may be either 0 or 1, and other notions as
follows. CB: Constrained Baseline profile, B: Baseline follows. CB: Constrained Baseline profile, B: Baseline
profile, M: Main profile, E: Extended profile, H: High profile, M: Main profile, E: Extended profile, H: High
profile, H10: High 10 profile, H42: High 4:2:2 profile, profile, H10: High 10 profile, H42: High 4:2:2 profile,
H44: High 4:4:4 Predictive profile, H10I: High 10 Intra H44: High 4:4:4 Predictive profile, H10I: High 10 Intra
profile, H42I: High 4:2:2 Intra profile, H44I: High 4:4:4 profile, H42I: High 4:2:2 Intra profile, H44I: High 4:4:4
Intra profile, and C44I: CAVLC 4:4:4 Intra profile. Intra profile, and C44I: CAVLC 4:4:4 Intra profile.
Profile profile_idc profile-iop Profile profile_idc profile-iop
(hexadecimal) (binary) (hexadecimal) (binary)
skipping to change at page 41, line 38 skipping to change at page 41, line 38
H 64 00000000 H 64 00000000
H10 6E 00000000 H10 6E 00000000
H42 7A 00000000 H42 7A 00000000
H44 F4 00000000 H44 F4 00000000
H10I 64 00010000 H10I 64 00010000
H42I 7A 00010000 H42I 7A 00010000
H44I F4 00010000 H44I F4 00010000
C44I 2C 00010000 C44I 2C 00010000
Note that other combinations of profile_idc and profile-iop Note that other combinations of profile_idc and profile-iop
(note listed in Table 5) may represent a common subset of (note listed in Table 13) may represent a sub-profile
coding tools for more than one profile. Note also that a equivalent to the common subset of coding tools for more than
decoder conforming to a certain profile may be able to decoder one profile. Note also that a decoder conforming to a certain
bitstreams conforming to other profiles. For example, a profile may be able to decode bitstreams conforming to other
decoder conforming to the High 4:4:4 profile at certain level profiles. For example, a decoder conforming to the High 4:4:4
must be able to decode bitstreams confirming to the profile at certain level must be able to decode bitstreams
Constrained Baseline, Main, High, High 10 or High 4:2:2 confirming to the Constrained Baseline, Main, High, High 10 or
profile at the same or a lower level. High 4:2:2 profile at the same or a lower level.
If the profile-level-id parameter is used to indicate
properties of a NAL unit stream, it indicates that, to decode
the stream, the minimum subset of coding tools a decoder has
to support is the default sub-profile, and the lowest level
the decoder has to support is the default level.
If the profile-level-id parameter is used for capability
exchange or session setup procedure, it indicates the subset
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. All levels lower than the default
level are also supported by the codec.
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 codec profile and each common subset of for each supported sub-profile separately. For example,
profiles that can be represented by profile_idc and the one-of-N codec selection procedure of the SDP
profile-iop separately. For example, the one-of-N codec Offer/Answer model can be used (section 10.2 of [8]). The
selection procedure of the SDP Offer/Answer model can be one-of-N codec selection procedure may also be used to
used (section 10.2 of [8]). However, in some cases the provide different combinations of profile_idc and profile-
value N in the one-of-N codec selection procedure may be iop that represent the same sub-profile. When there are a
too large for an acceptable size of the SDP message. lot of different combinations of profile_idc and profile-
Therefore, a receiver should understand the different iop that represent the same sub-profile, using the one-of-N
equivalent combinations of profile_id and profile-iop that codec selection procedure may result into large-sized SDP
represent the same set of coding tools the receiver message. Therefore, a receiver should understand the
supports, and be ready to accept an offer using any of the different equivalent combinations of profile_idc and
equivalent combinations. profile-iop that represent the same sub-profile, and be
ready to accept an offer using any of the 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 implied. without additional constraints at Level 1 MUST be implied.
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br: max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br:
These parameters MAY be used to signal the capabilities of a These parameters MAY be used to signal the capabilities of a
receiver implementation. These parameters MUST NOT be used for receiver implementation. These parameters MUST NOT be used for
any other purpose. The profile-level-id parameter MUST be any other purpose. The profile-level-id parameter MUST be
present in the same receiver capability description that present in the same receiver capability description that
contains any of these parameters. The level conveyed in the contains any of these parameters. The level conveyed in the
skipping to change at page 44, line 4 skipping to change at page 44, line 16
macroblocks in picture n. 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 * max- MaxMacroblocksPerSecond * max-smbps / ( P_non-static * max-
smbps + P_static * MaxMacroblocksPerSecond) 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 this for the level given in Table A-1 of [1]. Senders MAY use this
knowledge to send pictures of a given size at a higher picture knowledge to send pictures of a given size at a higher picture
rate than is indicated in the signalled level. rate than is indicated in the signalled level.
When rfc3984-compatible is equal to 1, max-smbps MUST NOT be
present.
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 conveyed picture sizes than are required by the signaled level conveyed
in the value of the profile-level-id parameter. When max-fs in the value of the profile-level-id parameter. When max-fs
is signaled, the receiver MUST be able to decode NAL unit is signaled, the receiver MUST be able to decode NAL unit
streams that conform to the signaled level, with the exception streams that conform to the signaled level, with the exception
that the MaxFS value in Table A-1 of [1] for the signaled that the MaxFS value in Table A-1 of [1] for the signaled
level is replaced with the value of max-fs. The value of max- level is replaced with the value of max-fs. The value of max-
fs MUST be greater than or equal to the value of MaxFS for the fs MUST be greater than or equal to the value of MaxFS for the
skipping to change at page 47, line 35 skipping to change at page 47, line 45
allowed. allowed.
Informative note: Even if redundant-pic-cap is equal to 1, Informative note: Even if redundant-pic-cap is equal to 1,
the receiver may also choose other error concealment the receiver may also choose other error concealment
strategies to replace or complement decoding of redundant strategies to replace or complement decoding of redundant
slices. slices.
sprop-parameter-sets: sprop-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 MUST precede any other NAL units parameter set NAL units) that can be placed in the NAL unit
in decoding order. The parameter MUST NOT be used to indicate stream to precede any other NAL units in decoding order. The
codec capability in any capability exchange procedure. The parameter MUST NOT be used to indicate codec capability in any
value of the parameter is the base64 [7] representation of the capability exchange procedure. The value of the parameter is
initial parameter set NAL units as specified in sections the base64 [7] representation of the initial parameter set NAL
7.3.2.1 and 7.3.2.2 of [1]. The parameter sets are conveyed units as specified in sections 7.3.2.1 and 7.3.2.2 of [1].
in decoding order, and no framing of the parameter set NAL
units takes place. A comma is used to separate any pair of The parameter sets are conveyed in decoding order, and no
parameter sets in the list. Note that the number of bytes in framing of the parameter set NAL units takes place. A comma
a parameter set NAL unit is typically less than 10, but a (',') is used to separate any pair of parameter sets in the
picture parameter set NAL unit can contain several hundreds of list. Note that the number of bytes in a parameter set NAL
bytes. unit is typically less than 10, but a picture parameter set
NAL unit can contain several hundreds of bytes.
Informative note: When several payload types are offered in Informative note: When several payload types are offered in
the SDP Offer/Answer model, each with its own sprop- the SDP Offer/Answer model, each with its own sprop-
parameter-sets parameter, then the receiver cannot assume parameter-sets parameter, then the receiver cannot assume
that those parameter sets do not use conflicting storage that those parameter sets do not use conflicting storage
locations (i.e., identical values of parameter set locations (i.e., identical values of parameter set
identifiers). Therefore, a receiver should double-buffer identifiers). Therefore, a receiver should double-buffer
all sprop-parameter-sets and make them available to the all sprop-parameter-sets and make them available to the
decoder instance that decodes a certain payload type. decoder instance that decodes a certain payload type.
The "sprop-parameter-sets" MUST contain only parameter sets The "sprop-parameter-sets" parameter MUST only contain
that are conforming to the profile-level-id, i.e. the profile parameter sets that are conforming to the profile-level-id,
or the used subset of coding tools indicated by the parameter i.e., the subset of coding tools indicated by any of the
sets is equivalent to that indicated by profile-level-id, and parameter sets MUST be equal to the default sub-profile, and
the level indicated by the parameter sets is the same as the the level indicated by any of the parameter sets MUST be equal
level indicated by profile-level-id. to the default level.
When the sprop-level-parameter-sets parameter is present,
sprop-parameter-sets MUST NOT be present. There MAY be zero
or one instance of "sprop-level-parameter-sets" present.
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 MUST precede any other NAL units parameter set NAL units) that can be placed in the NAL unit
in decoding order and that are associated with a particular stream to precede any other NAL units in decoding order and
level. The parameter MUST NOT be used to indicate codec that are associated with one or more levels lower than the
capability in any capability exchange procedure. The value of default level. The parameter MUST NOT be used to indicate
the parameter consists of a three-byte field followed by a codec capability in any capability exchange procedure.
comma and the base64 [7] representation of the initial
parameter set NAL units as specified in sections 7.3.2.1 and
7.3.2.2 of [1]. The parameter sets are conveyed in decoding
order, and no framing of the parameter set NAL units takes
place. A comma is used to separate any pair of parameter sets
in the list. The three-byte field MUST be equal to the three
bytes from profile_idc to level_idc, inclusive, in all
sequence parameter set NAL units contained in this media type
parameter. The profile_idc in all sequence parameter set NAL
units contained in this media type parameter MUST be equal to
the first byte in the media type parameter profile-level-id.
The level indicated by the three-byte field MUST be equal to
or lower than the level indicated by the media type parameter
profile-level-id.
Informative note: This parameter allows for efficient level The sprop-level-parameter-sets parameter contains parameter
down-gradable SDP offer/answer and out-of-band transport of sets for one or more levels which are lower than the default
parameter sets, with only one round of offer/answer. level. All parameter sets associated with one level are
clustered and prefixed with a three-byte field which has the
same syntax as profile-level-id. This enables the receiver to
install the parameter sets for one level and discard the rest.
The three-byte field is named PLId, and all parameter sets
associated with one level are named PSL, which has the same
syntax as sprop-parameter-sets. Parameter sets for each level
are represented in the form of PLId:PSL, i.e., PLId followed
by a colon (':') and the base64 [7] representation of the
initial parameter set NAL units for the level. Each pair of
PLId:PSL is also separated by a colon. Note that a PSL can
contain multiple parameter sets for that level, separated with
commas (',').
The "sprop-level-parameter-sets" MUST contain only parameter The subset of coding tools indicated by each PLId field MUST
sets that are conforming to the profile-level-id, i.e. the be equal to the default sub-profile, and the level indicated
profile or the used subset of coding tools indicated by the by each PLId field MUST be lower than the default level. All
parameter sets is equivalent to that indicated by profile- sequence parameter sets contained in each PSL MUST have the
level-id, and the level indicated by the parameter sets is the three bytes from profile_idc to level_idc, inclusive, equal to
same as the level indicated by profile-level-id. the preceding PLId.
When rfc3984-compatible is equal to 1 or sprop-parameter-sets Informative note: This parameter allows for efficient level
is present, sprop-level-parameter-sets MUST NOT be present. downgrade in SDP Offer/Answer and out-of-band transport of
parameter sets, simultaneously.
There MAY be zero or one or more than one instance of "sprop- use-level-parameter-sets:
level-parameter-sets" present. This parameter MAY be used to indicate a receiver capability.
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 0 indicates that the receiver does not understand
the sprop-level-parameter-sets parameter and will ignore
sprop-level-parameter-sets when present. The value 1
indicates that the receiver understands the sprop-level-
parameter-sets parameter and is capable of using parameter
sets contained therein.
Informative note: An RFC 3984 receiver does not understand
both sprop-level-parameter-sets and use-level-parameter-
sets. Therefore, during SDP Offer/Answer, an RFC 3984
receiver as the answerer will simply ignore sprop-level-
parameter-sets, when present in an offer. Assume that the
offered payload type was accepted at a level lower than the
default level. If the offered payload type included sprop-
level-parameter-sets, and the offerer sees that the
answerer has not included use-level-parameter-sets equal to
1 in the answer, the offerer gets to know that in-band
transport of parameter sets is needed.
sprop-ssrc: sprop-ssrc:
This parameter MAY be used to signal the properties of an RTP This parameter MAY be used to signal the properties of an RTP
packet stream. It specifies the SSRC values in the RTP header packet stream. It specifies the SSRC values in the RTP header
of all RTP packets in the RTP packet stream. The of all RTP packets in the RTP packet stream. The syntax of
representation of this parameter is the same as for the SSRC this parameter is the same as the syntax of the SSRC field in
field in the RTP header. the RTP header.
Informative note: This parameter allows for out-of-band Informative note: This parameter allows for out-of-band
transport of parameter sets in topologies like Topo-Video- transport of parameter sets in topologies like Topo-Video-
switch-MCU [28]. switch-MCU [28].
When rfc3984-compatible is equal to 1, sprop-ssrc MUST NOT be
present.
parameter-add:
This parameter MAY be used to signal whether the receiver of
this parameter is allowed to add parameter sets in its
signaling response using the sprop-parameter-sets media type
parameter. The value of this parameter is either 0 or 1. 0
is equal to false; i.e., it is not allowed to add parameter
sets. 1 is equal to true; i.e., it is allowed to add
parameter sets. If the parameter is not present, its value
MUST be 1.
The use of parameter-add is deprecated.
When rfc3984-compatible is equal to 0, parameter-add MUST NOT
be present.
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 50, line 41 skipping to change at page 50, line 46
The value of sprop-interleaving-depth MUST be an integer in The value of sprop-interleaving-depth MUST be an integer in
the range of 0 to 32767, inclusive. the range of 0 to 32767, inclusive.
sprop-deint-buf-req: sprop-deint-buf-req:
This parameter MUST NOT be present when packetization-mode is This parameter MUST NOT be present when packetization-mode is
not present or the value of packetization-mode is equal to 0 not present or the value of packetization-mode is equal to 0
or 1. It MUST be present when the value of packetization-mode or 1. It MUST be present when the value of packetization-mode
is equal to 2. is equal to 2.
sprop-deint-buf-req signals the required size of the sprop-deint-buf-req signals the required size of the de-
deinterleaving buffer for the RTP packet stream. The value of interleaving buffer for the RTP packet stream. The value of
the parameter MUST be greater than or equal to the maximum the parameter MUST be greater than or equal to the maximum
buffer occupancy (in units of bytes) required in such a buffer occupancy (in units of bytes) required in such a de-
deinterleaving buffer that is specified in section 7.2 of RFC interleaving buffer that is specified in section 7.2 of RFC
3984. It is guaranteed that receivers can perform the 3984. It is guaranteed that receivers can perform the de-
deinterleaving of interleaved NAL units into NAL unit decoding interleaving of interleaved NAL units into NAL unit decoding
order, when the deinterleaving buffer size is at least the order, when the de-interleaving buffer size is at least the
value of sprop-deint-buf-req in terms of bytes. value of sprop-deint-buf-req in terms of bytes.
The value of sprop-deint-buf-req MUST be an integer in the The value of sprop-deint-buf-req MUST be an integer in the
range of 0 to 4294967295, inclusive. range of 0 to 4294967295, inclusive.
Informative note: sprop-deint-buf-req indicates the Informative note: sprop-deint-buf-req indicates the
required size of the deinterleaving buffer only. When required size of the de-interleaving buffer only. When
network jitter can occur, an appropriately sized jitter network jitter can occur, an appropriately sized jitter
buffer has to be provisioned for as well. buffer has to be provisioned for as well.
deint-buf-cap: deint-buf-cap:
This parameter signals the capabilities of a receiver This parameter signals the capabilities of a receiver
implementation and indicates the amount of deinterleaving implementation and indicates the amount of de-interleaving
buffer space in units of bytes that the receiver has available buffer space in units of bytes that the receiver has available
for reconstructing the NAL unit decoding order. A receiver is for reconstructing the NAL unit decoding order. A receiver is
able to handle any stream for which the value of the sprop- able to handle any stream for which the value of the sprop-
deint-buf-req parameter is smaller than or equal to this deint-buf-req parameter is smaller than or equal to this
parameter. parameter.
If the parameter is not present, then a value of 0 MUST be If the parameter is not present, then a value of 0 MUST be
used for deint-buf-cap. The value of deint-buf-cap MUST be an used for deint-buf-cap. The value of deint-buf-cap MUST be an
integer in the range of 0 to 4294967295, inclusive. integer in the range of 0 to 4294967295, inclusive.
Informative note: deint-buf-cap indicates the maximum Informative note: deint-buf-cap indicates the maximum
possible size of the deinterleaving buffer of the receiver possible size of the de-interleaving buffer of the receiver
only. When network jitter can occur, an appropriately only. When network jitter can occur, an appropriately
sized jitter buffer has to be provisioned for as well. sized jitter buffer has to be provisioned for as well.
sprop-init-buf-time: sprop-init-buf-time:
This parameter MAY be used to signal the properties of an RTP This parameter MAY be used to signal the properties of an RTP
packet stream. The parameter MUST NOT be present, if the packet stream. The parameter MUST NOT be present, if the
value of packetization-mode is equal to 0 or 1. value of packetization-mode is equal to 0 or 1.
The parameter signals the initial buffering time that a The parameter signals the initial buffering time that a
receiver MUST wait before starting decoding to recover the NAL receiver MUST wait before starting decoding to recover the NAL
skipping to change at page 54, line 5 skipping to change at page 54, line 10
This parameter is motivated by, for example, an IP to H.223 This parameter is motivated by, for example, an IP to H.223
video telephony gateway, where NALUs smaller than the H.223 video telephony gateway, where NALUs smaller than the H.223
transport data unit will be more efficient. A gateway may transport data unit will be more efficient. A gateway may
terminate IP; thus, MTU discovery will normally not work terminate IP; thus, MTU discovery will normally not work
beyond the gateway. beyond the gateway.
Informative note: Setting this parameter to a lower than Informative note: Setting this parameter to a lower than
necessary value may have a negative impact. necessary value may have a negative impact.
sar: This parameter MAY be used to indicate a receiver preferene sar-understood:
or a stream property. When used to indicate a receiver This parameter MAY be used to indicate a receiver capability
preferene, the value of this parameter is an integer that and not anything else. The parameter indicates the maximum
indicates that the reciever supports all the sample aspect value of aspect_ratio_idc (specified in [1]) smaller than 255
ratios (SAR) corresponding to H.264 aspect_ratio_idc values in that the receiver understands. Table E-1 of [1] specifies
the range from 1 to N, inclusive, where N is the value of this aspect_ratio_idc equal to 0 as "unspecified", 1 to 16,
parameter (see Table E-1 of [1]), without geometric inclusive, as specific Sample Aspect Ratios (SARs), 17 to 254,
distortion. Therefore, the indicated range of SAR values is inclusive, as "reserved", and 255 as the Extended SAR, for
expressed as a preferene of the receiver. [Ed. (YkW): It is which SAR width and SAR height are explicitly signaled.
an open issue on the semantics of sar when it is used to Therefore, a receiver with a decoder according to [1]
indicate a stream property.] understands aspect_ratio_idc in the range of 1 to 16,
inclusive and aspect_ratio_idc equal to 255, in the sense that
H.264 compliant encoders SHOULD choose to send an SAR which the receiver knows what exactly the SAR is. For such a
can be displayed by receivers of the encoded bitstream without receiver, the value of sar-understood is 16. If in the future
geometric distortion. However, H.264 compliant encoders MAY Table E-1 of [1] is extended, e.g., such that the SAR for
choose to send pictures using any SAR. aspect_ratio_idc equal to 17 is specified, then for a receiver
with a decoder that understands the extension, the value of
When rfc3984-compatible is equal to 1, sar MUST NOT be sar-understood is 17. For a receiver with a decoder according
present. to the 2003 version of [1], the value of sar-understood is 13,
as the minimum reserved aspect_ratio_idc therein is 14.
esar: This parameter MAY be used only to indicate receiver When sar-understood is not present, the value MUST be inferred
capabilities. The value of this parameter is 1 or 0. 1 to be equal to 13.
indicates that the receiver supports all sample aspect ratios
which are expressible using the H.264 aspect_ratio_idc value
of 255 (Extended_SAR, see Table E-1 of [1]), without geometric
distortion. If the parameter esar does not exist, its value
MUST be inferred to be equal to 0.
The actual sample aspect ratio or extended sample aspect sar-supported:
ratio, when present, of the stream is conveyed in the Video This parameter MAY be used to indicate a receiver capability
Usability Information (VUI) part of a sequence parameter set. and not anything else. The value of this parameter is an
In the case where esar is signalled, the sar parameter can be integer in the range of 1 to sar-understood, inclusive, equal
used as well in order to signal the maximum index from Table to 255. The value of sar-supported equal to N smaller than
E-1 of [1] the receiver supports. 255 indicates that the reciever supports all the SARs
corresponding to H.264 aspect_ratio_idc values (see Table E-1
of [1]) in the range from 1 to N, inclusive, without geometric
distortion. The value of sar-supported equal to 255 indicates
that the receiver supports all sample aspect ratios which are
expressible using two 16-bit integer values as the numerator
and denominator, i.e., those that are expressible using the
H.264 aspect_ratio_idc value of 255 (Extended_SAR, see Table
E-1 of [1]), without geometric distortion.
When rfc3984-compatible is equal to 1, esar MUST NOT be H.264 compliant encoders SHOULD NOT send an aspect_ratio_idc
present. equal to 0, or an aspect_ratio_idc larger than sar-understood
and smaller than 255. H.264 compliant encoders SHOULD send an
aspect_ratio_idc that the receiver is able to display without
geometrical distortion. However, H.264 compliant encoders MAY
choose to send pictures using any SAR.
rfc3984-compatible: This parameter MAY be used in capability Note that the actual sample aspect ratio or extended sample
exchange or session setup procedure. When the parameter is not aspect ratio, when present, of the stream is conveyed in the
present, its value MUST be inferred to be equal to 1. If the Video Usability Information (VUI) part of the sequence
value is equal to 1, then the capability exchange or session parameter set.
setup procedure is backwards compatible to the procedure as
specified in RFC 3984. [Ed. (YkW): Add in section 16 that in
this case some ways of operations (i.e. level downgrade
together with out-of-band transport of parameter sets, and
out-of-band transport of parameter sets in video switching
topologies) cannot be applied and some newly-defined media
type parameters cannot be present. Check whether some newly-
defined media type parameters may be present and receivers can
ignore them. The list of such "some ways of operations"
should take into account both offer/answer and declarative
usages.] Otherwise (the value is equal to 0), the capability
exchange or session setup procedure is not backwards
compatible to the procedure as specified in RFC 3984. [Ed.
(YkW): Add in section 16 that in this case at least one of
some ways of operations (i.e. level downgrade together with
out-of-band transport of parameter sets, and out-of-band
transport of parameter sets in video switching topologies) is
applied and the needed newly-defined media type parameters are
present. This also implies that parameter-add is not present,
and there is no restriction to sprop-parameter-sets in
signaling responses. The list of such "some ways of
operations" should take into account both offer/answer and
declarative usages.]
Encoding considerations: Encoding considerations:
This type is only defined for transfer via RTP (RFC 3550). This type is only defined for transfer via RTP (RFC 3550).
Security considerations: Security considerations:
See section 9 of RFC xxxx. See section 9 of RFC xxxx.
Public specification: Public specification:
Please refer to RFC xxxx and its section 15. Please refer to RFC xxxx and its section 15.
skipping to change at page 56, line 24 skipping to change at page 56, line 14
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 (the o The encoding name in the "a=rtpmap" line of SDP MUST be H264 (the
media subtype). 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-mbps", "max-
smbps", "max-fs", "max-cpb", "max-dpb", "max-br", "redundant-pic- smbps", "max-fs", "max-cpb", "max-dpb", "max-br", "redundant-pic-
cap", "sprop-parameter-sets", "sprop-level-parameter-sets", cap", "sprop-parameter-sets", "sprop-level-parameter-sets", "use-
"sprop-ssrc", "parameter-add", "packetization-mode", "sprop- level-parameter-sets", "sprop-ssrc", "packetization-mode", "sprop-
interleaving-depth", "sprop-deint-buf-req", "deint-buf-cap", interleaving-depth", "sprop-deint-buf-req", "deint-buf-cap",
"sprop-init-buf-time", "sprop-max-don-diff", "max-rcmd-nalu-size", "sprop-init-buf-time", "sprop-max-don-diff", "max-rcmd-nalu-size",
"sar", "esar", and "rfc3984-compatible", when present, MUST be "sar-understood", and "sar-supported", when present, MUST be
included in the "a=fmtp" line of SDP. These parameters are 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
separated list of parameter=value pairs. separated list of parameter=value pairs.
An example of media representation in SDP is as follows (Baseline An example of media representation in SDP is as follows (Baseline
Profile, Level 3.0, some of the constraints of the Main profile may Profile, Level 3.0, some of the constraints of the Main profile may
not be obeyed): not be obeyed):
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; a=fmtp:98 profile-level-id=42A01E;
packetization-mode=1; packetization-mode=1;
sprop-parameter-sets=<base64 data> sprop-parameter-sets=<base64 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 [8] When H.264 is offered over RTP using SDP in an Offer/Answer model [8]
for negotiation for unicast usage, the following limitations and for negotiation for unicast usage, the following limitations and
rules apply: [Ed. (YkW): Add rule for "sar".] rules apply:
o The parameters identifying a media format configuration for H.264 o The parameters identifying a media format configuration for H.264
are "profile-level-id", "packetization-mode", "sprop-deint-buf- are "profile-level-id" and "packetization-mode", when present.
req", when present, and "rfc3984-compatible", when present. These These media format configuration parameters (except for the level
media format configuration parameters (except for the level part part of "profile-level-id") MUST be used symmetrically; i.e., the
of "profile-level-id") MUST be used symmetrically; i.e., the
answerer MUST either maintain all configuration parameters or answerer MUST either maintain all configuration parameters or
remove the media format (payload type) completely, if one or more remove the media format (payload type) completely, if one or more
of the parameter values are not supported. Note that the level of the parameter values are not supported. Note that the level
part of "profile-level-id" includes level_idc, and, for indication part of "profile-level-id" includes level_idc, and, for indication
of level 1b when profile_idc is equal to 66, 77 or 88, bit 4 of of level 1b when profile_idc is equal to 66, 77 or 88, bit 4
profile-iop. The level part of "profile-level-id" is (constraint_set3_flag) of profile-iop. The level part of
downgradable, i.e. the answerer MUST maintain the same or a lower "profile-level-id" is downgradable, i.e. the answerer MUST
level or remove the media format (payload type) completely. 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 applies
only for the above media format configuration parameters only for the above media format configuration parameters
excluding the level part of "profile-level-id", and not for excluding the level part of "profile-level-id", and not for
the other stream properties and capability parameters. the other stream properties and capability parameters.
Informative note: In H.264, all the levels except for level 1b Informative note: In H.264 [1], all the levels except for
are equal to the value of level_idc divided by 10. Level 1b level 1b are equal to the value of level_idc divided by 10.
is a level higher than level 1.0 but lower than level 1.1, and Level 1b is a level higher than level 1.0 but lower than level
is signaled in an ad-hoc manner, due to that the level was 1.1, and is signaled in an ad-hoc manner, due to that the
specified after level 1.0 and level 1.1. For the Baseline, level was specified after level 1.0 and level 1.1. For the
Main and Extended profiles (with profile_idc equal to 66, 77 Baseline, Main and Extended profiles (with profile_idc equal
and 88, respectively), level 1b is indicated by level_idc to 66, 77 and 88, respectively), level 1b is indicated by
equal to 11 (i.e. same as level 1.1) and constraint_set3_flag level_idc equal to 11 (i.e. same as level 1.1) and
equal to 1. For other profiles, level 1b is indicated by constraint_set3_flag equal to 1. For other profiles, level 1b
level_idc equal to 9 (but note that level 1b for these is indicated by level_idc equal to 9 (but note that level 1b
profiles are still higher than level 1, which has level_idc for these profiles are still higher than level 1, which has
equal to 10, and lower than level 1.1). In SDP offer/answer, level_idc equal to 10, and lower than level 1.1). In SDP
an answer to an offer may indicate a level value equal or Offer/Answer, an answer to an offer may indicate a level equal
lower than the level value indicated in the offer. Due to the to or lower than the level indicated in the offer. Due to the
ad-hoc indication of level 1b, offerers and answerers must ad-hoc indication of level 1b, offerers and answerers must
check the value of constraint_set3_flag, located in the middle check the value of bit 4 (constraint_set3_flag) of the middle
octet of the parameter "profile-level-id", when profile_idc is octet of the parameter "profile-level-id", when profile_idc is
equal to 66, 77 or 88 and level_idc is equal to 11. equal to 66, 77 or 88 and level_idc is equal 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 ("profile-level-id", "packetization-mode", and, if configuration is exactly the same as in the offer or the
present, "sprop-deint-buf-req") is the same as in the offer or configuration in the answer only differs from that in the offer
the configuration only differs from that in the offer with a with a level lower than the default level offered.
lower level indicated by "profile-level-id".
Informative note: An offerer, when receiving the answer, has Informative note: An offerer, when receiving the answer, has
to compare payload types not declared in the offer based on to compare payload types not declared in the offer based on
media type (i.e., video/H264) and the above media format media type (i.e., video/H264) and the above media format
configuration parameters with any payload types it has already configuration parameters with any payload types it has already
declared, in order to determine whether the configuration in declared, in order to determine whether the configuration in
question is new or equivalent to a configuration already question is new or equivalent to a configuration already
offered. offered.
o The parameters "packetization-mode", and if present, "sprop-deint- o The parameters "sprop-deint-buf-req", "sprop-interleaving-depth",
buf-req", "sprop-interleaving-depth", "sprop-max-don-diff", "sprop-max-don-diff", "sprop-init-buf-time", and "sprop-ssrc"
"sprop-init-buf-time", and "sprop-ssrc", describe the properties describe the properties of the RTP packet stream that the offerer
of the RTP packet stream that the offerer or answerer is sending or answerer is sending for the media format configuration. This
for this media format configuration. This differs from the normal differs from the normal usage of the Offer/Answer parameters:
usage of the Offer/Answer parameters: normally such parameters normally such parameters declare the properties of the stream that
declare the properties of the stream that the offerer or the the offerer or the answerer is able to receive. When dealing with
answerer is able to receive. When dealing with H.264, the offerer H.264, the offerer assumes that the answerer will be able to
assumes that the answerer will be able to receive media encoded receive media encoded using the configuration being offered.
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 the to another payload type when being sent, as they apply for the
configuration. 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", "esar") MAY be used to declare further capabilities of nalu-size", "sar-understood", "sar-supported") MAY be used to
the offerer or answerer for receiving. These parameters can only declare further capabilities of the offerer or answerer for
be present when the direction attribute is sendrecv or recvonly, receiving. These parameters can only be present when the
and the parameters describe the limitations of what the offerer or direction attribute is sendrecv or recvonly, and the parameters
answerer accepts for receiving streams. describe the limitations of what the offerer or answerer accepts
for receiving streams.
o As specified above, an offerer has to include the size of the o An offerer has to include the size of the de-interleaving buffer,
deinterleaving buffer, "sprop-deint-buf-req", in the offer for an "sprop-deint-buf-req", in the offer for an interleaved H.264
interleaved H.264 stream. To enable the offerer and answerer to stream. To enable the offerer and answerer to inform each other
inform each other about their capabilities for deinterleaving about their capabilities for de-interleaving buffering in
buffering in receiving streams, both parties are RECOMMENDED to receiving streams, both parties are RECOMMENDED to include "deint-
include "deint-buf-cap". This information MAY be used when the buf-cap". For interleaved streams, it is also RECOMMENDED to
value for "sprop-deint-buf-req" is selected in a second round of consider offering multiple payload types with different buffering
offer and answer. For interleaved streams, it is also RECOMMENDED requirements when the capabilities of the receiver are unknown.
to consider offering multiple payload types with different
buffering requirements when the capabilities of the 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, is used for out-of-band transport of parameter, when present, is used for out-of-band transport of
parameter sets. However, in this case, parameter sets MAY still parameter sets. However, when out-of-band transport of parameter
be additionally transported in-band. If neither "sprop-parameter- sets is used, parameter sets MAY still be additionally transported
sets" nor "sprop-level-parameter-sets" is present, then only in- in-band. If neither "sprop-parameter-sets" nor "sprop-level-
band transport of parameter sets is used. When accepting an parameter-sets" is present, then only in-band transport of
offered payload type, the answerer MUST be prepared to use the parameter sets is used.
parameter sets included in "sprop-parameter-sets" or "sprop-level-
parameter-sets", when present for the offered payload in the
offer, for decoding the incoming NAL unit stream. However, when
level downgrade is in use, i.e., the answerer accepts a level
lower than the level indicated by the offered profile-level-id,
the answerer SHOULD discard the parameter sets with a level higher
than the accepted level. The answerer MAY include "sprop-
parameter-sets" or "sprop-level-parameter-sets" in the answer for
an accepted payload type. The offerer MUST be prepared to use the
parameter sets included in "sprop-parameter-sets" or "sprop-level-
parameter-sets", when present for the accepted payload type in the
answer, for decoding the incoming NAL unit stream.
When the "sprop-parameter-sets" or "sprop-level-parameter-sets" An offer MAY include either or both of "sprop-parameter-sets" and
is present and the "sprop-ssrc" is present, the receiver of the "sprop-level-parameter-sets". An answer MAY include "sprop-
parameter-sets", and MUST NOT include "sprop-level-parameter-
sets".
When an offered payload type is accepted without level downgrade,
i.e. the default level is accepted, the following applies.
o The answerer MUST be prepared to use the parameter sets
included in "sprop-parameter-sets", when present, for
decoding the incoming NAL unit stream, and ignore "sprop-
level-parameter-sets", when present.
o When "sprop-parameter-sets" is not present, in-band
transport of parameter sets MUST be used.
When level downgrade is in use, i.e., a level lower than the
default level offered is accepted, the following applies.
o If "use-level-parameter-sets" is not present in the answer
for the accepted payload type or the value is equal to 0 in
the answer for the accepted payload type, the answerer MUST
ignore "sprop-parameter-sets" and "sprop-level-parameter-
sets", when present in the offer for the accepted payload
type.
o Otherwise (the "use-level-parameter-sets" is present in the
answer for the accepted payload type and the value is equal
to 1), the answerer MUST be prepared to use the parameter
sets that are included in "sprop-level-parameter-sets" for
the accepted level, when present, for decoding the incoming
NAL unit stream, and ignore all other parameter sets
included in "sprop-level-parameter-sets" and "sprop-
parameter-sets", when present.
o When no parameter sets for the accepted level are present in
the "sprop-level-parameter-sets", in-band transport of
parameter sets MUST be used.
The answerer MAY or MAY not include "sprop-parameter-sets", i.e.,
the answerer MAY use either out-of-band or in-band transport of
parameter sets for the stream it is sending, regardless of
whether out-of-band parameter sets transport has been used in the
offerer-to-answerer direction. 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
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. The offerer MUST be prepared to use the parameter
sets included in the answer's "sprop-parameter-sets", when
present, for decoding the incoming NAL unit stream.
When "sprop-parameter-sets" or "sprop-level-parameter-sets" is
present and "sprop-ssrc" is present, the receiver of the
parameters MUST store the parameter sets included in the "sprop- parameters MUST store the parameter sets included in the "sprop-
parameter-sets" or "sprop-level-parameter-sets" and associate parameter-sets" or "sprop-level-parameter-sets" for the accepted
them to "sprop-ssrc". These parameters MUST NOT be used to level and associate them to "sprop-ssrc". Parameter sets
decode NAL units conveyed in packets with SSRC not equal to the associated with one "sprop-ssrc" MUST only be used to decode NAL
associated "sprop-ssrc". units conveyed in packets with SSRC equal to the associated
"sprop-ssrc". The "sprop-ssrc" MAY be used in topologies like
Topo-Video-switch-MCU [28] to enable out-of-band transport of
parameter sets. When "sprop-ssrc" is used, and SSRC collision is
detected, the connection needs to be renegotiated using a new
random SSRC.
For streams being delivered over multicast, the following rules For streams being delivered over multicast, the following rules
apply: [Ed. (YkW): Add rules for "deint-buf-cap" and "sar". If apply:
"deint-buf-cap" MUST not be used in offer/answer for multicast, say
it. With the latest change, the rule for "deint-buf-cap" is the same
as for unicast above.]
o The media format configuration is identified by the same o The media format configuration is identified by the same
parameters as above for unicast (i.e. "profile-level-id", parameters as above for unicast (i.e. "profile-level-id" and
"packetization-mode", "sprop-deint-buf-req", when present, and "packetization-mode", when present). These media format
"rfc3984-compatible", when present). These media format
configuration parameters (including the level part of "profile- configuration parameters (including the level part of "profile-
level-id", i.e. the level part of "profile-level-id" is not level-id", i.e. the level part of "profile-level-id" is not
downgradable for offer/answer in multicast) MUST be used downgradable for Offer/Answer in multicast) MUST be used
symmetrically; i.e., the answerer MUST either maintain all symmetrically; i.e., the answerer MUST either maintain all
configuration parameters or remove the media format (payload type) configuration parameters or remove the media format (payload type)
completely. completely.
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 ("profile-level-id", "packetization-mode", "sprop- configuration is the same as in the offer.
deint-buf-req", when present, and "rfc3984-compatible") is the
same as in the offer. o Parameter sets received MUST be associated with the originating
source, and MUST be only used in decoding the incoming NAL unit
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.
Below are the complete lists of how the different parameters shall be Below are the complete lists of how the different parameters shall be
interpreted in the different combinations of offer or answer and interpreted in the different combinations of offer or answer and
direction attribute. direction attribute.
o In offers and answers for which "a=sendrecv" or no direction o In offers and answers for which "a=sendrecv" or no direction
attribute is used, the following interpretation of the parameters attribute is used, the following interpretation of the parameters
MUST be used. MUST be used.
Declaring actual configuration and properties for sending and Declaring actual configuration for sending and receiving streams:
receiving streams:
- profile-level-id - profile-level-id
- packetization-mode - packetization-mode
- rfc3984-compatible
Declaring actual properties of the stream to be sent: Declaring actual properties of the stream to be sent:
- sprop-deint-buf-req - sprop-deint-buf-req
- sprop-interleaving-depth - sprop-interleaving-depth
- sprop-max-don-diff - sprop-max-don-diff
- sprop-init-buf-time - sprop-init-buf-time
- sprop-ssrc - sprop-ssrc
Declaring receiver capabilities: Declaring receiver capabilities:
- max-mbps - max-mbps
- max-smbps - max-smbps
- max-fs - max-fs
- max-cpb - max-cpb
- max-dpb - max-dpb
- max-br - max-br
- redundant-pic-cap - redundant-pic-cap
- deint-buf-cap - deint-buf-cap
- max-rcmd-nalu-size - max-rcmd-nalu-size
- esar - sar-understood
- sar-supported
Declaring how Offer/Answer negotiation shall be performed: - use-level-parameter-sets
- parameter-add
Declaring receiver preferences:
- sar
Informative note: The interpretation of the optional parameter
"sar" depends on the direction attribute. When "a=sendonly",
it indicates the range of sample aspect ratios the stream will
contain. [Ed. (YkW): This is problematic as it is not common
to use multiple SARs in one stream. Better to remove this
informative note, as the use of each parameter for each
direction attribute is specified in the section.] When
"a=sendrecv" or "a=recvonly", the value of this parameter
indicates the range of sample ratios that the receiver is able
to display without geometric (shape) distortion. The receiver
shall still display pictures encoded at other sample aspect
ratios (though perhaps with geometric distortion).
Out-of-band transporting of parameter sets: Out-of-band transporting of parameter sets:
- sprop-parameter-sets - sprop-parameter-sets
- sprop-level-parameter-sets - sprop-level-parameter-sets
o In offers and answers for which "a=recvonly" is used, the o In offers and answers for which "a=recvonly" is used, the
following interpretation of the parameters MUST be used. following interpretation of the parameters MUST be used.
Declaring actual configuration and properties for receiving Declaring actual configuration for receiving streams:
streams:
- profile-level-id - profile-level-id
- packetization-mode - packetization-mode
- rfc3984-compatible
Declaring receiver capabilities: Declaring receiver capabilities:
- max-mbps - max-mbps
- max-smbps - max-smbps
- max-fs - max-fs
- max-cpb - max-cpb
- max-dpb - max-dpb
- max-br - max-br
- redundant-pic-cap - redundant-pic-cap
- deint-buf-cap - deint-buf-cap
- max-rcmd-nalu-size - max-rcmd-nalu-size
- esar - sar-understood
- sar-supported
Declaring receiver preferences: - use-level-parameter-sets
- sar
Not usable (when present, they SHOULD be ignored): Not usable (when present, they SHOULD be ignored):
- sprop-deint-buf-req - sprop-deint-buf-req
- sprop-interleaving-depth - sprop-interleaving-depth
- sprop-parameter-sets - sprop-parameter-sets
- sprop-level-parameter-sets - sprop-level-parameter-sets
- sprop-max-don-diff - sprop-max-don-diff
- sprop-init-buf-time - sprop-init-buf-time
- sprop-ssrc - sprop-ssrc
- parameter-add
o In offers or answers for which "a=sendonly" is used, the following o In offers or answers for which "a=sendonly" is used, the following
interpretation of the parameters MUST be used. interpretation of the parameters MUST be used.
Declaring actual configuration and properties for sending Declaring actual configuration or properties for sending streams:
streams:
- profile-level-id - profile-level-id
- packetization-mode - packetization-mode
- rfc3984-compatible
- sprop-deint-buf-req - sprop-deint-buf-req
- sprop-max-don-diff - sprop-max-don-diff
- sprop-init-buf-time - sprop-init-buf-time
- sprop-interleaving-depth - sprop-interleaving-depth
- sprop-ssrc - sprop-ssrc
Out-of-band transporting of parameter sets: Out-of-band transporting of parameter sets:
- sprop-parameter-sets - sprop-parameter-sets
- sprop-level-parameter-sets - sprop-level-parameter-sets
skipping to change at page 62, line 49 skipping to change at page 63, line 9
- max-mbps - max-mbps
- max-smbps - max-smbps
- max-fs - max-fs
- max-cpb - max-cpb
- max-dpb - max-dpb
- max-br - max-br
- redundant-pic-cap - redundant-pic-cap
- deint-buf-cap - deint-buf-cap
- max-rcmd-nalu-size - max-rcmd-nalu-size
- parameter-add - sar-understood
- sar - sar-supported
- esar - use-level-parameter-sets
Furthermore, the following considerations are necessary: Furthermore, the following considerations are necessary:
o Parameters used for declaring receiver capabilities are in general o 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.
"sprop-parameter-sets" MUST NOT be used in a sender's declaration
of its receiving capabilities, as the limits of the values that
are carried inside the parameter sets are implicit with the
profile and level used.
o Parameters declaring a configuration point are not downgradable, o Parameters declaring a configuration point are not downgradable,
with the exception of the level part of the "profile-level-id" with the exception of the level part of the "profile-level-id"
parameter for unicast usage. This expresses values a receiver parameter for unicast usage. This expresses values a receiver
expects to be used and must be used verbatim on the sender side. expects to be used and must be used verbatim on the sender side.
o When a sender's capabilities are declared, and non-downgradable o 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 receive streams. In order to achieve high interoperability
skipping to change at page 64, line 10 skipping to change at page 64, line 16
sending and receiving, the offerer should offer different RTP sending and receiving, the offerer should offer different RTP
sessions; i.e., different media lines declared as "recvonly" and sessions; i.e., different media lines declared as "recvonly" and
"sendonly", respectively. This may have further implications on "sendonly", respectively. This may have further implications on
the system. the system.
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 in When H.264 over RTP is offered with SDP in a declarative style, as in
RTSP [26] or SAP [27], the following considerations are necessary. RTSP [26] or SAP [27], the following considerations are necessary.
o All parameters capable of indicating both an RTP packet stream's o All parameters capable of indicating both stream properties and
properties and a receiver's capabilities are used to indicate only receiver capabilities are used to indicate only stream properties.
the properties of an RTP packet stream. For example, in this For example, in this case, the parameter "profile-level-id"
case, the parameter "profile-level-id" declares only the values declares only the values used by the stream, not the capabilities
used by the stream, not the capabilities for receiving streams. for receiving streams. This results in that the following
This results in that the following interpretation of the interpretation of the parameters MUST be used:
parameters MUST be used:
Declaring actual configuration or stream properties: Declaring actual configuration or stream properties:
- profile-level-id - profile-level-id
- packetization-mode - packetization-mode
- rfc3984-compatible
- sprop-parameter-sets
- sprop-level-parameter-sets
- sprop-interleaving-depth - sprop-interleaving-depth
- sprop-deint-buf-req - sprop-deint-buf-req
- sprop-max-don-diff - sprop-max-don-diff
- sprop-init-buf-time - sprop-init-buf-time
- sprop-ssrc - sprop-ssrc
Out-of-band transporting of parameter sets:
- sprop-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
- redundant-pic-cap - redundant-pic-cap
- max-rcmd-nalu-size - max-rcmd-nalu-size
- parameter-add
- deint-buf-cap - deint-buf-cap
- sar - sar-understood
- esar - sar-supported
- use-level-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
An SDP Offer/Answer exchange wherein both parties are expected to An SDP Offer/Answer exchange wherein both parties are expected to
both send and receive could look like the following. Only the media both send and receive could look like the following. Only the media
skipping to change at page 65, line 35 skipping to change at page 65, line 40
sprop-init-buf-time=102478; deint-buf-cap=128000 sprop-init-buf-time=102478; deint-buf-cap=128000
The above offer presents the same codec configuration in three The above offer presents the same codec configuration in three
different packetization formats. PT 98 represents single NALU mode, different packetization formats. PT 98 represents single NALU mode,
PT 99 represents non-interleaved mode, and PT 100 indicates the PT 99 represents non-interleaved mode, and PT 100 indicates the
interleaved mode. In the interleaved mode case, the interleaving interleaved mode. In the interleaved mode case, the interleaving
parameters that the offerer would use if the answer indicates support parameters that the offerer would use if the answer indicates support
for PT 100 are also included. In all three cases the parameter for PT 100 are also included. In all three cases the parameter
"sprop-parameter-sets" conveys the initial parameter sets that are "sprop-parameter-sets" conveys the initial parameter sets that are
required by the answerer when receiving a stream from the offerer required by the answerer when receiving a stream from the offerer
when this configuration (profile-level-id and packetization mode) is when this configuration is accepted. Note that the value for "sprop-
accepted. Note that the value for "sprop-parameter-sets" could be parameter-sets" could be different for each payload type.
different for each payload type.
Answerer -> Offerer SDP message: Answerer -> Offerer SDP message:
m=video 49170 RTP/AVP 100 99 97 m=video 49170 RTP/AVP 100 99 97
a=rtpmap:97 H264/90000 a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42A01E; packetization-mode=0; a=fmtp:97 profile-level-id=42A01E; packetization-mode=0;
sprop-parameter-sets=<base64 data#3> sprop-parameter-sets=<base64 data#3>
a=rtpmap:99 H264/90000 a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42A01E; packetization-mode=1; a=fmtp:99 profile-level-id=42A01E; packetization-mode=1;
sprop-parameter-sets=<base64 data#4>; sprop-parameter-sets=<base64 data#4>;
skipping to change at page 66, line 34 skipping to change at page 66, line 39
The answerer also accepts the reception of the two configurations The answerer also accepts the reception of the two configurations
that payload types 99 and 100 represent. Again, the answerer needs that payload types 99 and 100 represent. Again, the answerer needs
to store parameter sets included in sprop-parameter-sets=<base64 to store parameter sets included in sprop-parameter-sets=<base64
data#1> and sprop-parameter-sets=<base64 data#2> in case the offer data#1> and sprop-parameter-sets=<base64 data#2> in case the offer
finally decides to use either of these two configurations. The finally decides to use either of these two configurations. The
answerer provides the initial parameter sets for the answerer-to- answerer provides the initial parameter sets for the answerer-to-
offerer direction, i.e. the parameter sets in sprop-parameter- offerer direction, i.e. the parameter sets in sprop-parameter-
sets=<base64 data#4> and sprop-parameter-sets=<base64 data#5>, for sets=<base64 data#4> and sprop-parameter-sets=<base64 data#5>, for
payload types 99 and 100, respectively, that it will use to send the payload types 99 and 100, respectively, that it will use to send the
payload types. The answerer also provides the offerer with its payload types. The answerer also provides the offerer with its
memory limit for deinterleaving operations by providing a "deint-buf- memory limit for de-interleaving operations by providing a "deint-
cap" parameter. This is only useful if the offerer decides on making buf-cap" parameter. This is only useful if the offerer decides on
a second offer, where it can take the new value into account. The making a second offer, where it can take the new value into account.
"max-rcmd-nalu-size" indicates that the answerer can efficiently The "max-rcmd-nalu-size" indicates that the answerer can efficiently
process NALUs up to the size of 3980 bytes. However, there is no process NALUs up to the size of 3980 bytes. However, there is no
guarantee that the network supports this size. guarantee that the network supports this size.
Below are some more examples. In the following example, the offer is accepted without level
downgrading (i.e. the default level, 3.0, is accepted), and both
In the following example, the original offer is accepted without "sprop-parameter-sets" and "sprop-level-parameter-sets" are present
downgrading the level part of "profile-level-id", and "sprop- in the offer. The answerer must ignore sprop-level-parameter-
parameter-sets" is present (i.e. there is out-of-band transmission of sets=<base-64 data#1> and store parameter sets in sprop-parameter-
parameter sets). This case needs only one round of offer/answer. sets=<base-64 data#0> for decoding the incoming NAL unit stream. The
Note that sprop-parameter-sets=<base-64 data#0> is basically offerer must store the parameter sets in sprop-parameter-sets=<base-
independent of sprop-parameter-sets=<base-64 data#1>. The former is 64 data#2> in the answer for decoding the incoming NAL unit stream.
to be used by the encoder of the offerer and the decoder of the Note that in this example, parameter sets in sprop-parameter-
answerer. The latter is to be used by the encoder of the answerer sets=<base-64 data#2> must be associated with level 3.0.
and the decoder of the offerer. Note that requiring them (including
both sequence parameter sets and picture parameter sets) to be
identical or the former to be a subset of the latter would seriously
limit independent encoding optimizations by the independent encoders.
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;
sprop-parameter-sets=<base-64 data#0> sprop-parameter-sets=<base-64 data#0>;
sprop-level-parameter-sets=<base-64 data#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=42A01E; //Baseline profile, Level 3.0 a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
packetization-mode=1; packetization-mode=1;
sprop-parameter-sets=<base-64 data#1> sprop-parameter-sets=<base-64 data#2>
In the following example, the original offer is also accepted without In the following example, the offer (Baseline profile, level 1.1) is
downgrading the level part of "profile-level-id", but "sprop- accepted with level downgrading (the accepted level is 1b), and both
parameter-sets" is not present, meaning that there is no out-of-band "sprop-parameter-sets" and "sprop-level-parameter-sets" are present
transmission of parameter sets, which then have to be transmitted in- in the offer. The answerer must ignore sprop-parameter-sets=<base-64
band. This case also needs only one round of offer/answer. data#0> and all parameter sets not for the accepted level (level 1b)
in sprop-level-parameter-sets=<base-64 data#1>, and must store
parameter sets for the accepted level (level 1b) in sprop-level-
parameter-sets=<base-64 data#1> for decoding the incoming NAL unit
stream. The offerer must store the parameter sets in sprop-
parameter-sets=<base-64 data#2> in the answer for decoding the
incoming NAL unit stream. Note that in this example, parameter sets
in sprop-parameter-sets=<base-64 data#2> must be associated with
level 1b.
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=42A00B; //Baseline profile, Level 1.1
packetization-mode=1 packetization-mode=1;
sprop-parameter-sets=<base-64 data#0>;
sprop-level-parameter-sets=<base-64 data#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=42A01E; //Baseline profile, Level 3.0 a=fmtp:98 profile-level-id=42B00B; //Baseline profile, Level 1b
packetization-mode=1 packetization-mode=1;
sprop-parameter-sets=<base-64 data#2>;
use-level-parameter-sets=1
In the following example, the original offer is accepted with In the following example, the offer (Baseline profile, level 1.1) is
downgrading the level part of "profile-level-id", and "sprop- accepted with level downgrading (the accepted level is 1b), and both
parameter-sets" is present (i.e. there is out-of-band transmission of "sprop-parameter-sets" and "sprop-level-parameter-sets" are present
parameter sets). This case needs at least two rounds of offer/answer in the offer. However, the answerer is a legacy RFC 3984
unless the offer includes multiple payload types for different implementation and does not understand "sprop-level-parameter-sets",
levels, which makes the SDP message larger. The reason for the need hence it does not include "use-level-parameter-sets" (which the
of more than one offer/answer round is because the "sprop-parameter- answerer does not understand, either) in the answer. Therefore, the
sets" in the original offer is not applicable to any level lower than answerer must ignore both sprop-parameter-sets=<base-64 data#0> and
the one indicated by the level part of "profile-level-id". sprop-level-parameter-sets=<base-64 data#1>, and the offerer must
transport parameter sets in-band.
Note that sprop-parameter-sets=<base-64 data#0> contains level_idc Offer SDP:
indicating Level 3.0, therefore cannot be used as the answerer wants
Level 2.0 and does not need to be stored by the answerer. The sprop- m=video 49170 RTP/AVP 98
parameter-sets=<base-64 data#2> is to be used by the encoder of the a=rtpmap:98 H264/90000
offerer and the decoder of the answerer. The sprop-parameter- a=fmtp:98 profile-level-id=42A00B; //Baseline profile, Level 1.1
sets=<base-64 data#1> is to be used by the encoder of the answerer packetization-mode=1;
and the decoder of the offerer. sprop-parameter-sets=<base-64 data#0>;
sprop-level-parameter-sets=<base-64 data#1>
Answer SDP:
m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42B00B; //Baseline profile, Level 1b
packetization-mode=1
In the following example, the offer is accepted without level
downgrading, and "sprop-parameter-sets" is present in the offer.
Parameter sets in sprop-parameter-sets=<base-64 data#0> must be
stored and used used by the encoder of the offerer and the decoder of
the answerer, and parameter sets in sprop-parameter-sets=<base-64
data#1>must be used by the encoder of the answerer and the decoder of
the offerer. Note that sprop-parameter-sets=<base-64 data#0> is
basically independent of sprop-parameter-sets=<base-64 data#1>.
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;
sprop-parameter-sets=<base-64 data#0> sprop-parameter-sets=<base-64 data#0>
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=42A01E; //Baseline profile, Level 3.0
packetization-mode=1; packetization-mode=1;
sprop-parameter-sets=<base-64 data#1> sprop-parameter-sets=<base-64 data#1>
In the following example, the offer is accepted without level
downgrading, and neither "sprop-parameter-sets" nor "sprop-level-
parameter-sets" is present in the offer, meaning that there is no
out-of-band transmission of parameter sets, which then have to be
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:97 profile-level-id=42A014; //Baseline profile, Level 2.0 a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
packetization-mode=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
In the following example, the offer is accepted with level
downgrading and "sprop-parameter-sets" is present in the offer. As
sprop-parameter-sets=<base-64 data#0> contains level_idc indicating
Level 3.0, therefore cannot be used as the answerer wants Level 2.0
and must be ignored by the answerer, and in-band parameter sets must
be used.
Offer 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; packetization-mode=1;
sprop-parameter-sets=<base-64 data#2> sprop-parameter-sets=<base-64 data#0>
Answer SDP: //This SDP is identical to previous 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
sprop-parameter-sets=<base-64 data#1>
In the following example, the original offer is also accepted with In the following example, the offer is also accepted with level
downgrading the level part of "profile-level-id", but "sprop- downgrading, and neither "sprop-parameter-sets" nor "sprop-level-
parameter-sets" is not present, meaning that there is no out-of-band parameter-sets" is present in the offer, meaning that there is no
transmission of parameter sets, which then have to be transmitted in- out-of-band transmission of parameter sets, which then have to be
band. This case also needs only one round of offer/answer. 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:
skipping to change at page 69, line 30 skipping to change at page 70, line 43
8.4. Parameter Set Considerations 8.4. Parameter Set Considerations
The H.264 parameter sets are a fundamental part of the video codec The H.264 parameter sets are a fundamental part of the video codec
and vital to its operation; see section 1.2. Due to their and vital to its operation; see section 1.2. Due to their
characteristics and their importance for the decoding process, lost characteristics and their importance for the decoding process, lost
or erroneously transmitted parameter sets can hardly be concealed or erroneously transmitted parameter sets can hardly be concealed
locally at the receiver. A reference to a corrupt parameter set has locally at the receiver. A reference to a corrupt parameter set has
normally fatal results to the decoding process. Corruption could normally fatal results to the decoding process. Corruption could
occur, for example, due to the erroneous transmission or loss of a occur, for example, due to the erroneous transmission or loss of a
parameter set data structure, but also due to the untimely parameter set NAL unit, but also due to the untimely transmission of
transmission of a parameter set update. Therefore, the following a parameter set update. A parameter set update refers to a change of
at least one parameter in a picture parameter set or sequence
parameter set for which the picture parameter set or sequence
parameter set identifier remains unchanged. Therefore, the following
recommendations are provided as a guideline for the implementer of recommendations are provided as a guideline for the implementer of
the RTP sender. the RTP sender.
Parameter set NALUs can be transported using three different Parameter set NALUs can be transported using three different
principles: principles:
A. Using a session control protocol (out-of-band) prior to the actual A. Using a session control protocol (out-of-band) prior to the actual
RTP session. RTP session.
B. Using a session control protocol (out-of-band) during an ongoing B. Using a session control protocol (out-of-band) during an ongoing
skipping to change at page 70, line 7 skipping to change at page 71, line 24
C. Within the RTP packet stream in the payload (in-band) during an C. Within the RTP packet stream in the payload (in-band) during an
ongoing RTP session. ongoing RTP session.
It is recommended to implement principles A and B within a session It is recommended to implement principles A and B within a session
control protocol. SIP and SDP can be used as described in the SDP control protocol. SIP and SDP can be used as described in the SDP
Offer/Answer model and in the previous sections of this memo. This Offer/Answer model and in the previous sections of this memo. This
section contains guidelines on how principles A and B should be section contains guidelines on how principles A and B should be
implemented within session control protocols. It is independent of implemented within session control protocols. It is independent of
the particular protocol used. Principle C is supported by the RTP the particular protocol used. Principle C is supported by the RTP
payload format defined in this specification. There are topologies payload format defined in this specification. There are topologies
like Topo-Video-switch-MCU [28] that require the use of principle C. like Topo-Video-switch-MCU [28] for which the use of principle C may
be desirable.
If in-band signaling of parameter sets is used, the picture and If in-band signaling of parameter sets is used, the picture and
sequence parameter set NALUs SHOULD be transmitted in the RTP payload sequence parameter set NALUs SHOULD be transmitted in the RTP payload
using a reliable method of delivering of RTP, as a loss of a using a reliable method of delivering of RTP (see below), as a loss
parameter set of either type will likely prevent decoding of a of a parameter set of either type will likely prevent decoding of a
considerable portion of the corresponding RTP packet stream. considerable portion of the corresponding RTP packet stream.
If in-band signaling of parameter sets is used, the sender SHOULD If in-band signaling of parameter sets is used, the sender SHOULD
take the error characteristics into account and use mechanisms to take the error characteristics into account and use mechanisms to
provide a high probability for delivering the parameter sets provide a high probability for delivering the parameter sets
correctly. Mechanisms that increase the probability for a correct correctly. Mechanisms that increase the probability for a correct
reception include packet repetition, FEC, and retransmission. The reception include packet repetition, FEC, and retransmission. The
use of an unreliable, out-of-band control protocol has similar use of an unreliable, out-of-band control protocol has similar
disadvantages as the in-band signaling (possible loss) and, in disadvantages as the in-band signaling (possible loss) and, in
addition, may also lead to difficulties in the synchronization (see addition, may also lead to difficulties in the synchronization (see
below). Therefore, it is NOT RECOMMENDED. below). Therefore, it is NOT RECOMMENDED.
Parameter sets MAY be added or updated during the lifetime of a Parameter sets MAY be added or updated during the lifetime of a
session using principles B and C. It is required that parameter sets session using principles B and C. It is required that parameter sets
are present at the decoder prior to the NAL units that refer to them. are present at the decoder prior to the NAL units that refer to them.
Updating or adding of parameter sets can result in further problems, Updating or adding of parameter sets can result in further problems,
and therefore the following recommendations should be considered. and therefore the following recommendations should be considered.
- When parameter sets are added or updated, care SHOULD be taken to - When parameter sets are added or updated, care SHOULD be taken to
ensure that any parameter set is delivered prior to its usage. It ensure that any parameter set is delivered prior to its usage.
is common that no synchronization is present between out-of-band When new parameter sets are added, previously unused parameter set
signaling and in-band traffic. If out-of-band signaling is used, identifiers are used. It is common that no synchronization is
it is RECOMMENDED that a sender does not start sending NALUs present between out-of-band signaling and in-band traffic. If
requiring the updated parameter sets prior to acknowledgement of out-of-band signaling is used, it is RECOMMENDED that a sender
delivery from the signaling protocol. does not start sending NALUs requiring the added or updated
parameter sets prior to acknowledgement of delivery from the
signaling protocol.
- When parameter sets are updated, the following synchronization - When parameter sets are updated, the following synchronization
issue should be taken into account. When overwriting a parameter issue should be taken into account. When overwriting a parameter
set at the receiver, the sender has to ensure that the parameter set at the receiver, the sender has to ensure that the parameter
set in question is not needed by any NALU present in the network set in question is not needed by any NALU present in the network
or receiver buffers. Otherwise, decoding with a wrong parameter or receiver buffers. Otherwise, decoding with a wrong parameter
set may occur. To lessen this problem, it is RECOMMENDED either set may occur. To lessen this problem, it is RECOMMENDED either
to overwrite only those parameter sets that have not been used for to overwrite only those parameter sets that have not been used for
a sufficiently long time (to ensure that all related NALUs have a sufficiently long time (to ensure that all related NALUs have
been consumed), or to add a new parameter set instead (which may been consumed), or to add a new parameter set instead (which may
have negative consequences for the efficiency of the video have negative consequences for the efficiency of the video
coding). coding).
Informative note: In some topologies like Topo-Video-switch- Informative note: In some topologies like Topo-Video-switch-
MCU [28] the origin of the whole set of parameter sets may MCU [28] the origin of the whole set of parameter sets may
come from multiple sources that may use non-unique parameter come from multiple sources that may use non-unique parameter
sets numbers. In this case an offer may overwrite an existing sets identifiers. In this case an offer may overwrite an
parameter set if no other mechanism that enables uniqueness of existing parameter set if no other mechanism that enables
the parameter sets in the out-of-band channel exists. [Ed. uniqueness of the parameter sets in the out-of-band channel
(YkW): Would there be a better place for the text in this exists.
informative note?]
- When new parameter sets are added, previously unused parameter set - In a multiparty session, one participant MUST associate parameter
identifiers are used. This avoids the problem identified in the sets coming from different sources with the source identification
previous paragraph. However, in a multiparty session, unless a whenever possible, e.g. by using sprop-ssrc for out-of-band
synchronized control protocol is used, there is a risk that transported parameter sets, as different sources typically use
multiple entities try to add different parameter sets for the same independent parameter set identifier value spaces.
identifier, which has to be avoided.
- Adding or modifying parameter sets by using both principles B and - Adding or modifying parameter sets by using both principles B and
C in the same RTP session may lead to inconsistencies of the C in the same RTP session may lead to inconsistencies of the
parameter sets because of the lack of synchronization between the parameter sets because of the lack of synchronization between the
control and the RTP channel. Therefore, principles B and C MUST control and the RTP channel. Therefore, principles B and C MUST
NOT both be used in the same session unless sufficient NOT both be used in the same session unless sufficient
synchronization can be provided. synchronization can be provided.
In some scenarios (e.g., when only the subset of this payload format In some scenarios (e.g., when only the subset of this payload format
specification corresponding to H.241 is used) or topologies, it is specification corresponding to H.241 is used) or topologies, it is
skipping to change at page 72, line 8 skipping to change at page 73, line 25
associated with updating the parameter sets delivered out-of-band. associated with updating the parameter sets delivered out-of-band.
If receivers miss some in-band updates (for example, because of a If receivers miss some in-band updates (for example, because of a
loss or a late tune-in), those receivers attempt to decode the loss or a late tune-in), those receivers attempt to decode the
bitstream using out-dated parameters. It is therefore RECOMMENDED bitstream using out-dated parameters. It is therefore RECOMMENDED
that parameter set IDs be partitioned between the out-of-band and that parameter set IDs be partitioned between the out-of-band and
in-band parameter sets. in-band parameter sets.
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) Parameter Sets (Informative)
When a video encoder according to ITU-T Rec. H.264 receives a request When a sender with a video encoder according to [1] receives a
for a decoder refresh point, the encoder shall enter the fast update request for a decoder refresh point, the encoder shall enter the fast
mode by using one of the procedures specified in Section 8.5.1 or update mode by using one of the procedures specified in Section 8.5.1
8.5.2 below. The procedure in 8.5.1 is the preferred response in a or 8.5.2 below. The procedure in 8.5.1 is the preferred response in
lossless transmission environment. Both procedures satisfy the a lossless transmission environment. Both procedures satisfy the
requirement to enter the fast update mode for H.264 video encoding. requirement to enter the fast update mode for H.264 video encoding.
8.5.1. IDR Procedure to Respond to a Request for a Decoder Refresh Point 8.5.1. IDR Procedure to Respond to a Request for a Decoder Refresh Point
This section gives one possible way to respond to a request for a This section gives one possible way to respond to a request for a
decoder refresh point. decoder refresh point.
The encoder shall, in the order presented here: The encoder shall, in the order presented here:
1) Immediately prepare to send an IDR picture. 1) Immediately prepare to send an IDR picture.
skipping to change at page 72, line 34 skipping to change at page 74, line 5
2) Send a sequence parameter set to be used by the IDR picture to be 2) Send a sequence parameter set to be used by the IDR picture to be
sent. The encoder may optionally also send other sequence sent. The encoder may optionally also send other sequence
parameter sets. parameter sets.
3) Send a picture parameter set to be used by the IDR picture to be 3) Send a picture parameter set to be used by the IDR picture to be
sent. The encoder may optionally also send other picture parameter sent. The encoder may optionally also send other picture parameter
sets. sets.
4) Send the IDR picture. 4) Send the IDR picture.
5) From this point forward in time, send or re-send any other 5) From this point forward in time, send any other sequence or
sequence or picture parameter sets, not sent in this procedure, picture parameter sets that have not yet been sent in this
prior to their reference by any NAL unit, regardless of whether procedure, prior to their reference by any NAL unit, regardless of
such parameter sets were previously sent prior to receiving the whether such parameter sets were previously sent prior to
request for a decoder refresh point. As needed, such parameter receiving the request for a decoder refresh point. As needed,
sets may be sent in a batch, one at a time, or in any combination such parameter sets may be sent in a batch, one at a time, or in
of these two methods. Parameter sets may be re-sent at any time any combination of these two methods. Parameter sets may be re-
for redundancy. Caution should be taken when parameter set sent at any time for redundancy. Caution should be taken when
updates are present, as described above in Section 8.4. parameter set updates are present, as described above in Section
8.4.
8.5.2. Gradual Recovery Procedure to Respond to a Request for a Decoder 8.5.2. Gradual Recovery Procedure to Respond to a Request for a Decoder
Refresh Point Refresh Point
This section gives another possible way to respond to a request for a This section gives another possible way to respond to a request for a
decoder refresh point. decoder refresh point.
The encoder shall, in the order presented here: The encoder shall, in the order presented here:
1) Send a recovery point SEI message (see Sections D.1.7 and D.2.7 of 1) Send a recovery point SEI message (see Sections D.1.7 and D.2.7 of
[1]). [1]).
2) Repeat any sequence and picture parameter sets that were sent 2) Repeat any sequence and picture parameter sets that were sent
before the recovery point SEI message, prior to their reference by before the recovery point SEI message, prior to their reference by
a NAL unit. a NAL unit.
The encoder shall ensure that the decoder has access to all reference The encoder shall ensure that the decoder has access to all reference
pictures for inter prediction of pictures at or after the recovery pictures for inter prediction of pictures at or after the recovery
point, which is indicated by the recovery point SEI message, in point, which is indicated by the recovery point SEI message, in
output order, assuming that the transmission from now on is error- output order, assuming that the transmission from now on is error-
free. For example, the encoder may mark all reference pictures as free.
"unused for reference" by issuing a
memory_management_control_operation equal to 5 (see Section 8.2.5 of
[1]).
The value of the recovery_frame_cnt syntax element in the recovery The value of the recovery_frame_cnt syntax element in the recovery
point SEI message shall be such that the time between the reception point SEI message should be small enough to ensure a fast recovery.
of the request for a decoder refresh point and completing the
transmission of the access unit including the recovery point is less
than or equal to 3 seconds.
As needed, such parameter sets may be re-sent in a batch, one at a As needed, such parameter sets may be re-sent in a batch, one at a
time, or in any combination of these two methods. Parameter sets may time, or in any combination of these two methods. Parameter sets may
be re-sent at any time for redundancy. Caution should be taken when be re-sent at any time for redundancy. Caution should be taken when
parameter set updates are present, as described above in Section 8.4. parameter set updates are present, as described above in Section 8.4.
9. Security Considerations 9. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
skipping to change at page 74, line 33 skipping to change at page 75, line 45
10. Congestion Control 10. Congestion Control
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[5], and with any applicable RTP profile; e.g., RFC 3551 [15]. An [5], and with any applicable RTP profile; e.g., RFC 3551 [15]. An
additional requirement if best-effort service is being used is: users additional requirement if best-effort service is being used is: users
of this payload format MUST monitor packet loss to ensure that the of this payload format MUST monitor packet loss to ensure that the
packet loss rate is within acceptable parameters. Packet loss is packet loss rate is within acceptable parameters. Packet loss is
considered acceptable if a TCP flow across the same network path, and considered acceptable if a TCP flow across the same network path, and
experiencing the same network conditions, would achieve an average experiencing the same network conditions, would achieve an average
throughput, measured on a reasonable timescale, that is not less than throughput, measured on a reasonable timescale that is not less than
the RTP flow is achieving. This condition can be satisfied by the RTP flow is achieving. This condition can be satisfied by
implementing congestion control mechanisms to adapt the transmission implementing congestion control mechanisms to adapt the transmission
rate (or the number of layers subscribed for a layered multicast rate (or the number of layers subscribed for a layered multicast
session), or by arranging for a receiver to leave the session if the session), or by arranging for a receiver to leave the session if the
loss rate is unacceptably high. loss rate is unacceptably high.
The bit rate adaptation necessary for obeying the congestion control The bit rate adaptation necessary for obeying the congestion control
principle is easily achievable when real-time encoding is used. principle is easily achievable when real-time encoding is used.
However, when pre-encoded content is being transmitted, bandwidth However, when pre-encoded content is being transmitted, bandwidth
adaptation requires the availability of more than one coded adaptation requires the availability of more than one coded
skipping to change at page 88, line 26 skipping to change at page 89, line 41
7.4.1.2 of [1]. Consequently, slices of different pictures cannot be 7.4.1.2 of [1]. Consequently, slices of different pictures cannot be
interleaved, and the multi-picture slice interleaving technique (see interleaved, and the multi-picture slice interleaving technique (see
section 12.6) for improved error resilience cannot be used. 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 is thanked for his the development of RFC 3984. Randell Jesup, Stephen Botzko, and
valuable comments during the development of this RFC. Magnus Westerlund are thanked for their valuable comments during the
development of this RFC.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
15. References 15. References
15.1. Normative References 15.1. Normative References
[1] ITU-T Recommendation H.264, "Advanced video coding for generic [1] ITU-T Recommendation H.264, "Advanced video coding for generic
audiovisual services", May 2003. [Ed. (YkW): This should be audiovisual services", November 2007. [Ed. (YkW): This should
updated to the latest version.] be updated after a later version is approved.]
[2] ISO/IEC International Standard 14496-10:2003. [Ed. (YkW): This [2] ISO/IEC International Standard 14496-10:2008.
should be updated to the latest version.]
[3] ITU-T Recommendation H.241, "Extended video procedures and [3] ITU-T Recommendation H.241, "Extended video procedures and
control signals for H.300 series terminals", May 2006. [Ed. control signals for H.300 series terminals", May 2006.
(TK): This should be updated to the latest version, when
published.]
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[6] Handley, M. and V. Jacobson, "SDP: Session Description [6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
skipping to change at page 92, line 36 skipping to change at page 94, line 5
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
16. Backward compatibility to RFC 3984 16. 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.
TBD. The technical changes are listed in section 17.
17. Changes from RFC 3984 Items 1), 2), 3), 7), 8), 9), 11), 12) are bug-fix type of changes,
and do not incur any backward compatibility issues.
To be updated. Item 4), addition of six new media type parameters, does not incur
any backward compatibility issues for SDP Offer/Answer based
applications, as legacy RFC 3984 receivers ignore these parameters,
and it is fine for legacy RFC 3984 senders not to use these
parameters as they are optional. However, there is a backward
compatibility issue for SDP declarative usage based applications,
e.g. those using RTSP and SAP, because the SDP receiver per RFC 3984
cannot accept a session for which the SDP includes an unrecognized
parameter. Therefore, the RTSP or SAP server may have to prepare two
sets of streams, one for legacy RFC 3984 receivers and one for
receivers according to this memo.
17.1. Technical changes Items 5), 6) and 10) are related to out-of-band transport of
parameter sets. When a sender according to this memo is
communicating with a legacy receiver according to RFC 3984, there is
no backward compatibility issue. When the legacy receiver sees an SDP
message with no parameter-add the value of parameter-add is inferred
to be equal to 1 by the legacy receiver (related to change item 5)).
As RFC 3984 allows inclusion of any parameter sets in sprop-
parameter-sets, it is fine to the legacy receiver to include
parameter sets only for the default level in sprop-parameter-sets
(related to change item 6)). When there are new parameters e.g.
sprop-level-parameter-sets present, the legacy receiver simply
ignores them (related to change item 10)). When a legacy sender
according to RFC 3984 is communicating with a receiver according to
this memo, there is one backward compatibility issue. When the
legacy sender includes parameter sets for a level different than the
default level indicated by profile-level-id to sprop-parameter-sets,
the parameter value of sprop-parameter-sets is invalid to the
receiver and therefore the session may be rejected. In SDP
Offer/Answer between a legacy offerer according to RFC 3984 and an
answerer according to this memo, when the answerer includes in the
answer parameter sets that are not a superset of the parameter sets
included in the offer, the parameter value of sprop-parameter-sets is
invalid to offerer and the session may not be initiated properly
(related to change item 10)).
The technical changes (including bug fixes) from RFC 3984 are: Item 13) removed that use of out-of-band transport of parameter sets
is recommended. As out-of-band transport of parameter sets is still
allowed, this change does not incur any backward compatibility
issues.
Item 14) does not incur any backward compatibility issues as the
added subsection 8.5 is informative.
17. Changes from RFC 3984
Following is the list of technical changes (including bug fixes) from
RFC 3984. Besides this list of technical changes, numerous editorial
changes have been made, but not documented in this memo.
1) In subsections 5.4, 5.5, 6.2, 6,3 and 6.4, removed that the 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
There are N VCL NAL units in the deinterleaving buffer. There are N VCL NAL units in the deinterleaving buffer.
to to
There are N or more VCL NAL units in the deinterleaving buffer. There are N or more VCL NAL units in the de-interleaving buffer.
3) In subsection 7.2.2, changed the sentence
Herein, n corresponds to the NAL unit having the greatest value
of AbsDON among the received NAL units.
to
Herein, n corresponds to the NAL unit having the greatest value
of AbsDON among the NAL units in the deinterleaving buffer.
4) In subsection 8.1, the semantics of sprop-init-buf-time, paragraph 3) In subsection 8.1, the semantics of sprop-init-buf-time, paragraph
2, changed the sentence 2, changed the sentence
The parameter is the maximum value of (transmission time of a NAL The parameter is the maximum value of (transmission time of a NAL
unit - decoding time of the NAL unit), assuming reliable and unit - decoding time of the 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.
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-
level-parameter-sets, use-level-parameter-sets, sprop-ssrc, sar-
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.2.2, changed bullet item 1, such that in the SDP 6) In subsection 8.1, added a constraint to sprop-parameter-sets such
offer/answer model, the use of the level part of "profile-level- that it can only contain parameter sets for the same profile and
id" does not need to be symmetric, i.e. the value of the level level as indicated by profile-level-id.
part in the answer does not have not be the same as in the offer.
In addition, an informative note was added to clarify the
specification of level 1b in H.264.
7) In subsection 8.2.2, changed bullet item 3 from
The capability parameters ("max-mbps", "max-fs", "max-cpb", "max-
dpb", "max-br", ,"redundant-pic-cap", "max-rcmd-nalu-size") MAY
be used to declare further capabilities. Their interpretation
depends on the direction attribute. When the direction attribute
is sendonly, then the parameters describe the limits of the RTP
packets and the NAL unit stream that the sender is capable of
producing. When the direction attribute is sendrecv or recvonly,
then the parameters describe the limitations of what the receiver
accepts.
to
The capability parameters ("max-mbps", "max-fs", "max-cpb", "max-
dpb", "max-br", ,"redundant-pic-cap", "max-rcmd-nalu-size") MAY
be used to declare further capabilities. These parameters can
only be present when the direction attribute is sendrecv or
recvonly, and the parameters describe the limitations of what the
receiver accepts.
Such that the description matches the semantics of these
parameters defined earlier.
8) In subsection 8.2.2. the following paragraph
For streams being delivered over multicast, the following rules
apply in addition:
was changed to the following (with an item added after the
paragraph):
For streams being delivered over multicast, the following rules
apply:
o The media format configuration is identified by the same
parameters as above for unicast (i.e. "profile-level-id",
"packetization-mode", and, if required by "packetization-
mode", "sprop-deint-buf-req"). These media format
configuration parameters (including the level part of
"profile-level-id") MUST be used symmetrically; i.e., the
answerer MUST either maintain all configuration parameters or
remove the media format (payload type) completely.
Because some items described above for unicast do not apply for
multicast.
9) In subsection 8.2.2, the bullet item starting with "In an offer or
answer for which the direction attribute "a=sendonly" is included
for the media stream, the following interpretation of the
parameters MUST be used:", removed the following, because, the
direction attribute is sendonly, the sender will not receive
streams.
Declaring the capabilities of the sender when it receives a
stream:
- max-mbps
- max-fs
- max-cpb
- max-dpb
- max-br
- redundant-pic-cap
- deint-buf-cap
- max-rcmd-nalu-size
17.2. Editorial changes
The editorial changes from RFC 3984 are:
1) In subsection 4.1 (Definitions), added the definition of "NALU-
time" (moved from subsection 5.7 with slight modifications), and
changed the use of "NALU time" to "NALU-time" at two places in
subsection 5.7.
2) Added the subsection number 4.2 for Abbreviations.
3) In subsection 5.2, added the following paragraph right before
Table 1:
Table 1 summarizes NAL unit types and the corresponding RTP
packet types when each of these NAL units is directly used a
packet payload, and where the types are described in this memo.
4) In subsection 5.2, changed Table 1 from
Table 1. Summary of NAL unit types and their payload structures
Type Packet Type name Section
---------------------------------------------------------
0 undefined -
1-23 NAL unit Single NAL unit packet per H.264 5.6
24 STAP-A Single-time aggregation packet 5.7.1
25 STAP-B Single-time aggregation packet 5.7.1
26 MTAP16 Multi-time aggregation packet 5.7.2
27 MTAP24 Multi-time aggregation packet 5.7.2
28 FU-A Fragmentation unit 5.8
29 FU-B Fragmentation unit 5.8
30-31 undefined -
to
Table 1. Summary of NAL unit types and the corresponding packet
types
NAL Unit Packet Packet Type Name Section
Type Type
---------------------------------------------------------
0 reserved -
1-23 NAL unit Single NAL unit packet 5.6
24 STAP-A Single-time aggregation packet 5.7.1
25 STAP-B Single-time aggregation packet 5.7.1
26 MTAP16 Multi-time aggregation packet 5.7.2
27 MTAP24 Multi-time aggregation packet 5.7.2
28 FU-A Fragmentation unit 5.8
29 FU-B Fragmentation unit 5.8
30-31 reserved -
5) In subsection 5.3, removed "greater than 00" from the following
sentence:
In addition to the specification above, according to this RTP
payload specification, values of NRI indicate the relative
transport priority, as determined by the encoder.
6) In subsection 5.3, the second informative note, corrected "nal
unit" to "NAL unit".
7) In the end of subsection 5.4, changed the text starting from the
second sentence of the last text paragraph and Table 3 from
The used packetization mode governs which NAL unit types are
allowed in RTP payloads. Table 3 summarizes the allowed NAL unit
types for each packetization mode. Some NAL unit type values
(indicated as undefined in Table 3) are reserved for future
extensions. NAL units of those types SHOULD NOT be sent by a
sender and MUST be ignored by a receiver. For example, the Types
1-23, with the associated packet type "NAL unit", are allowed in
"Single NAL Unit Mode" and in "Non-Interleaved Mode", but
disallowed in "Interleaved Mode". Packetization modes are
explained in more detail in section 6.
Table 3. Summary of allowed NAL unit types for each packetization
mode (yes = allowed, no = disallowed, ig = ignore)
Type Packet Single NAL Non-Interleaved Interleaved
Unit Mode Mode Mode
-------------------------------------------------------------
0 undefined ig ig ig
1-23 NAL unit yes yes no
24 STAP-A no yes no
25 STAP-B no no yes
26 MTAP16 no no yes
27 MTAP24 no no yes
28 FU-A no yes yes
29 FU-B no no yes
30-31 undefined ig ig ig
to
The used packetization mode governs which NAL unit types are
allowed in RTP payloads. Table 3 summarizes the allowed packet
payload types for each packetization mode. Packetization modes
are explained in more detail in section 6.
Table 3. Summary of allowed NAL unit types for each packetization
mode (yes = allowed, no = disallowed, ig = ignore)
Payload Packet Single NAL Non-Interleaved Interleaved
Type Type Unit Mode Mode Mode
-------------------------------------------------------------
0 reserved ig ig ig
1-23 NAL unit yes yes no
24 STAP-A no yes no
25 STAP-B no no yes
26 MTAP16 no no yes
27 MTAP24 no no yes
28 FU-A no yes yes
29 FU-B no no yes
30-31 reserved ig ig ig
Some NAL unit or payload type values (indicated as undefined in
Table 3) are reserved for future extensions. NAL units of those
types SHOULD NOT be sent by a sender (direct as packet payloads,
or as aggregation units in aggregation packets, or as fragmented
units in FU packets) and SHOULD be ignored by a receiver. For
example, the payload types 1-23, with the associated packet type
"NAL unit", are allowed in "Single NAL Unit Mode" and in "Non-
Interleaved Mode", but disallowed in "Interleaved Mode".
However, NAL units of NAL 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 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 aggregation units in STAP-A
packets or fragmented units in FU-A packets, in addition to being
directly used as packet payloads.
8) In subsections 5.6 and 5.7, changed "type" to "Type" in Figures 2
and 3.
9) Corrected the titles of Figures 7,8,12, and 13, wherein "and" was
replaced by "containing".
10)In subsection 5.7.2, corrected the sentence
The DON of the following NAL unit is equal to (DONB + DOND) %
65536, in which % denotes the modulo operation.
to
The DON of the NAL unit contained in a multi-time aggregation
unit is equal to (DONB + DOND) % 65536, in which % denotes the
modulo operation.
11)In Figure 11, corrected "NALU unit size" to "NAL unit size".
12)In subsection 5.7.2, the informative note under Figure 11,
corrected the first sentence from
The "earliest" multi-time aggregation unit is the one that would
have the smallest extended RTP timestamp among all the
aggregation units of an MTAP if the aggregation units were
encapsulated in single NAL unit packets.
to
The "earliest" multi-time aggregation unit is the one that would
have the smallest extended RTP timestamp among all the
aggregation units of an MTAP if the NAL units contained in the
aggregation units were encapsulated in single NAL unit packets.
13)In subsection 5.7.3, corrected the following sentence by replacing
"picture" with "NAL unit".
The fragmentation mechanism allows fragmenting a single picture
and applying generic forward error correction as described in
section 12.5.
14)In subsection 5.7.3, changed the following sentence by replacing
'A' with "An".
A FU payload MAY have any number of octets and MAY be empty.
15)In subsection 5.7.3, the last informative note, changed the last
sentence from
However, the (potential) use of zero-length NALUs should be
carefully weighed against the increased risk of the loss of the
NALU because of the additional packets employed for its
transmission.
to
However, the (potential) use of zero-length NALU fragments should
be carefully weighed against the increased risk of the loss of at
least a part of the NALU because of the additional packets
employed for its transmission.
16)In subsection 6.1, corrected the sentence
Coded slice NAL units or coded slice data partition NAL units
belonging to the same coded picture (and thus sharing the same
RTP timestamp value) MAY be sent in any order permitted by the
applicable profile defined in [1]; however, for delay-critical
systems, they SHOULD be sent in their original coding order to
minimize the delay. Note that the coding order is not
necessarily the scan order, but the order the NAL packets become
available to the RTP stack.
to
Coded slice NAL units or coded slice data partition NAL units
belonging to the same coded picture (and thus sharing the same
RTP timestamp value) MAY be sent in any order; however, for
delay-critical systems, they SHOULD be sent in their original
decoding order to minimize the delay. Note that the decoding
order is the order of the NAL units in the bitstream.
17)Removed "(Informative)" from the tile of section 7, and changed
the first sentences in the beginning of section 7 from
The de-packetization process is implementation dependent.
Therefore, the following description should be seen as an example
of a suitable implementation. Other schemes may be used as well.
Optimizations relative to the described algorithms are likely
possible.
to
The de-packetization process is implementation dependent.
Therefore, the following description should be seen as an example
of a suitable implementation. Other schemes may be used as well
as long as the output for the same input is the same as the
process described below. The output is the same meaning that the
number of NAL units and their order are both the identical.
Optimizations relative to the described algorithms are likely
possible.
18)In subsection 7.1, paragraph 1, corrected the last sentence from
If a decapsulated packet is an FU-A, all the fragments of the
fragmented NAL unit are concatenated and passed to the decoder.
to
For all the FU-A packets containing fragments of a single NAL
unit, the decapsulated fragments are concatenated in their
sending order to recover the NAL unit, which is then passed to
the decoder.
19)In subsection 7.2, paragraph 2, corrected the first sentence
(copied below) by replacing "packets" with "NAL units".
The receiver includes a receiver buffer, which is used to
compensate for transmission delay jitter and to reorder packets
from transmission order to the NAL unit decoding order.
20)In subsection 7.2.2, paragraph 1, changed the following sentence
by replacing "is" with "are".
After initial buffering, decoding and playback is started, and
the buffering-while-playing mode is used.
21)In subsection 7.2.2, paragraph 1, changed the sentence
The value of DON is calculated and stored for all NAL units.
to
The value of DON is calculated and stored for each NAL unit.
22)In subsection 7.2.2, removed "an" from the following sentence.
Let PDON be a variable that is initialized to 0 at the beginning
of the an RTP session.
23)In section 8, paragraph 2, changed the sentence
The name of all these parameters starts with "sprop" for stream
properties.
to
The names of all these parameters start with "sprop" for stream
properties.
24)In subsection 8.1, the semantics of max-mbps, max-fs, max-cpb,
max-dpb, and max-br, changed the last paragraph above the
informative note from
A receiver MUST NOT signal values of max-mbps, max-fs, max-
cpb, max-dpb, and max-br that meet the requirements of a
higher level, referred to as level A herein, compared to the
level specified in the value of the profile-level-id
parameter, if the receiver can support all the properties of
level A.
to
If a receiver can support all the properties of level A, the
level specified in the value of the profile-level-id MUST be
level A (i.e. MUST NOT be lower than level A). In other
words, a sender or receiver MUST NOT signal values of max-
mbps, max-fs, max-cpb, max-dpb, and max-br that meet the
requirements of a higher level compared to the level specified
in the value of the profile-level-id parameter.
25)In subsection 8.1, the semantics of max-dpb, the informative note,
removed "and is a property of the video decoder only" from the
following sentence.
The decoded picture buffer stores reconstructed samples and is a
property of the video decoder only.
26)In subsection 8.1, the semantics of max-br, paragraph 2, removed
the following sentence that is repeated later in the exact form.
The value of max-br MUST be greater than or equal to the value of
MaxBR for the level given in Table A-1 of [1].
27)In subsection 8.1, the semantics of packetization-mode, changed
the last sentence from
The value of packetization mode MUST be an integer in the range
of 0 to 2, inclusive.
to
The value of packetization-mode MUST be an integer in the range
of 0 to 2, inclusive.
28)In subsection 8.1, the semantics of sprop-init-buf-time, paragraph
2, changed the following sentence by replacing "MUST buffer" by
"MUST wait".
The parameter signals the initial buffering time that a receiver
MUST buffer before starting decoding to recover the NAL unit
decoding order from the transmission order.
29)In subsection 8.1, changed "NAL unit stream" to "RTP packet
stream" at several places in the semantics of sprop-interleaving-
depth, sprop-deint-buf-req, sprop-init-buf-time and sprop-max-don-
diff.
30)In subsection 8.1, removed the paragraph talking about file
formats after the description of "Encoding considerations". The
references 29 and 30 (to file format specifications) were also
removed.
31)In subsection 8.2.1, the example SDP message. Added the required
parameter "packetization-mode", which was missing. Another change
is the change of a hypothetical value of "sprop-parameter-sets" to
"<base64 data>", as readers may be confused by the hypothetical
value. The same change regarding hypothetical values of "sprop-
parameter-sets" was made to the SDP examples in subsection 8.3.
32)In subsection 8.2.2, bullet item 2, changed the beginning sentence
from
The parameters "sprop-parameter-sets", "sprop-deint-buf-req",
"sprop-interleaving-depth", "sprop-max-don-diff", and "sprop-
init-buf-time" describe the properties of the NAL unit stream
that the offerer or answerer is sending for this media format
configuration.
to
The parameters "packetization-mode", and if present, "sprop-
deint-buf-req", "sprop-parameter-sets", "sprop-interleaving-
depth", "sprop-max-don-diff", and "sprop-init-buf-time", describe
the properties of the RTP packet stream that the offerer or
answerer is sending for this media format configuration.
33)In subsection 8.2.2, bullet item 2, the informative note, the last
sentence, corrected the typo "then" to "than".
34)In subsection 8.2.2, changed the following bullet item for
multicast
o The stream properties parameters ("sprop-parameter-sets",
"sprop-deint-buf-req", "sprop-interleaving-depth", "sprop-
max-don-diff", and "sprop-init-buf-time") MUST NOT be changed
by the answerer. Thus, a payload type can either be accepted
unaltered or removed.
to
o The stream properties parameters ("sprop-parameter-sets",
"sprop-interleaving-depth", "sprop-max-don-diff", and "sprop-
init-buf-time") MUST NOT be changed by the answerer. Thus, a
payload type can either be accepted unaltered or removed.
35)In subsection 8.2.3, changed two uses of "NAL unit stream" to "RTP
packet stream", and changed the sentence "Declaring actual
configuration or properties:" to "Declaring actual configuration
or stream properties:".
36)In subsection 8.3, the first sentence, changed "A SIP Offer/Answer
exchange" to "An SDP Offer/Answer exchange".
37)In subsection 8.3, the first example, changed "Offerer -> Answer
SDP message:" to "Offerer -> Answerer SDP message:".
38)In subsection 8.3, in the paragraph describing the offer SDP in
the first example, changed
PT 98 represents single NALU mode, PT 99 non-interleaved mode; PT
100 indicates the interleaved mode.
to
PT 98 represents single NALU mode, PT 99 represents non-
interleaved mode, and PT 100 indicates the interleaved mode.
And changed "that are required for the answerer" to "that are
required by the answerer".
And changed
Note that the value for "sprop-parameter-sets", although
identical in the example above, could be different for each
payload type.
to
Note that the value for "sprop-parameter-sets" could be different
for each payload type.
39)In subsection 8.3, changed the two paragraphs describing the
answer SDP in the first example from
As the Offer/Answer negotiation covers both sending and receiving
streams, an offer indicates the exact parameters for what the
offerer is willing to receive, whereas the answer indicates the
same for what the answerer accepts to receive. In this case the
offerer declared that it is willing to receive payload type 98.
The answerer accepts this by declaring a equivalent payload type
97; i.e., it has identical values for the three parameters
"profile-level-id", packetization-mode, and "sprop-deint-buf-
req". This has the following implications for both the offerer
and the answerer concerning the parameters that declare
properties. The offerer initially declared a certain value of
the "sprop-parameter-sets" in the payload definition for PT=98.
However, as the answerer accepted this as PT=97, the values of
"sprop-parameter-sets" in PT=98 must now be used instead when the
offerer sends PT=97. Similarly, when the answerer sends PT=98 to
the offerer, it has to use the properties parameters it declared
in PT=97.
The answerer also accepts the reception of the two configurations
that payload types 99 and 100 represent. It provides the initial
parameter sets for the answerer-to-offerer direction, and for
buffering related parameters that it will use to send the payload
types. It also provides the offerer with its memory limit for
deinterleaving operations by providing a "deint-buf-cap"
parameter. This is only useful if the offerer decides on making
a second offer, where it can take the new value into account.
The "max-rcmd-nalu-size" indicates that the answerer can
efficiently process NALUs up to the size of 3980 bytes. However,
there is no guarantee that the network supports this size.
to
As the Offer/Answer negotiation covers both sending and receiving
streams, an offer indicates the exact parameters for what the
offerer is willing to receive, whereas the answer indicates the
same for what the answerer accepts to receive. In this case the
offerer declared that it is willing to receive payload type 98.
The answerer accepts this by declaring an equivalent payload type
97; i.e., it has identical values for the two parameters
"profile-level-id" and "packetization-mode" (since
"packetization-mode" is equal to 0, "sprop-deint-buf-req" is not
present). As the offered payload type 98 is accepted, the
answerer needs to store parameter sets included in sprop-
parameter-sets=<base64 data#0> in case the offer finally decides
to use this configuration. In the answer, the answerer includes
the parameter sets in sprop-parameter-sets=<base64 data#3> that
the answerer would use in the stream sent from the answerer if
this configuration is finally used.
The answerer also accepts the reception of the two configurations
that payload types 99 and 100 represent. Again, the answerer
needs to store parameter sets included in sprop-parameter-
sets=<base64 data#1> and sprop-parameter-sets=<base64 data#2> in
case the offer finally decides to use either of these two
configurations. The answerer provides the initial parameter sets
for the answerer-to-offerer direction, i.e. the parameter sets in
sprop-parameter-sets=<base64 data#4> and sprop-parameter-
sets=<base64 data#5>, for payload types 99 and 100, respectively,
that it will use to send the payload types. The answerer also
provides the offerer with its memory limit for deinterleaving
operations by providing a "deint-buf-cap" parameter. This is
only useful if the offerer decides on making a second offer,
where it can take the new value into account. The "max-rcmd-
nalu-size" indicates that the answerer can efficiently process
NALUs up to the size of 3980 bytes. However, there is no
guarantee that the network supports this size.
40)In the end of subsection 8.3, added four more SDP offer/answer
examples describing level downgrade and using or not using out-of-
band transmission of parameter sets.
41)In subsection 8.4, changed two uses of "RTP stream" to "RTP packet
stream".
42)In subsection 8.4, changed the sentence 7) In subsection 8.2.2, removed sprop-deint-buf-req from being part
of the media format configuration in usage with the SDP
Offer/Answer model.
It is RECOMMENDED that parameter set IDs be partitioned between 8) In subsection 8.2.2, made it clear that level is downgradable in
the out-of-band and in-band parameter sets. the SDP Offer/Answer model, i.e. the use of the level part of
"profile-level-id" does not need to be symmetric (the level
included in the answer can be lower than or equal to the level
included in the offer).
to 9) In subsection 8.2.2, removed that the capability parameters may be
used to declare encoding capabilities.
It is therefore RECOMMENDED that parameter set IDs be partitioned 10)In subsection 8.2.2, added rules on how to use sprop-parameter-
between the out-of-band and in-band parameter sets. sets and sprop-level-parameter-sets for out-of-band transport of
parameter sets, with or without level downgrading.
43)In subsection 13.3, changed 11)In subsection 8.2.2, clarified the rules of using the media type
parameters with SDP Offer/Answer for multicast.
pictures are transmitted at constant intervals (that is, 1 / 12)In subsection 8.2.2, completed and corrected the list of how
frame rate). different media type parameters shall be interpreted in the
different combinations of offer or answer and direction attribute.
to 13)In subsection 8.4, changed the text such that both out-of-band and
in-band transport of parameter sets are allowed and neither is
recommended or required.
pictures are transmitted at constant intervals (that is, 1 / 14)Added subsection 8.5 (informative) providing example methods for
(frame rate)). decoder refresh to handle parameter set losses.
18. Open issues 18. Open issues
The issues remaining open are: The issues remaining open are:
1) Add a brief summary of the changes to RFC 3984 in the beginning of 1) (From Randell) References to RFC 2733 should be updated to (and
section 1.
2) The semantics of sar, e.g. the allowed values and its relationship
with esar, as well its use in SDP offer/answer need to be
clarified.
3) Use of deint-buf-cap in SDP offer/answer for multicast is missing
(and was missing in RFC 3984).
4) Some SDP offer/answer examples using new SDP parameters to be
added.
5) Sections 8.4 and 8.5 need to be updated under the new context of
using sprop-parameter-sets or sprop-level-parameter-sets, and
possibly together with sprop-ssrc, for out-of-band transporting of
parameter sets.
6) (from Randell) References to RFC 2733 should be updated to (and
checked against) RFC 5109. There are a lot of calculations and checked against) RFC 5109. There are a lot of calculations and
the like that should be checked. Also update [17] to RFC 5109. the like that should be checked. Also update [17] to RFC 5109.
7) To complete the section on backward compatibility to RFC 3984. For
example, operations backwards-compatible and non-backwards-
compatible to RFC 3984 need to be identified and added.
8) To update the changes from RFC 3984.
19. Changes Log
Technical changes compared to draft-wang-avt-rfc3984bis-01.txt
- Changed that reserved NAL unit types MUST be ignored to SHOULD be
ignored in section 5.4.
- (Could be considered as an editorial change as well) In section
8.1, updated the semantics of profile-level-id, especially related
to constraint_set3_flag, signaling of level 1b, Constrained
Baseline profile, and equivalent combinations of profile_idc and
profile-iop.
- In section 8.1, added 7 new optional media type parameters: max-
smbps, sprop-level-parameter-sets, sar, esar, sprop-ssrc, and
rfc3984-compatible.
- In section 8.1, updated the semantics of sprop-parameter-sets.
- In section 8.1, added back parameter-add which is in RFC 3984. And
added that the use of parameter-add is deprecated.
- In section 8.2.2, the usage of media type parameters with the SDP
offer/answer model has been updated. For example, the parameter
rfc3984-compatible is now part of the media format configuration.
Level downgrade is better clarified. Use of sprop-parameter-sets
or sprop-level-parameter-sets for out-of-band transporting of
parameter sets is explained in more details.
- In section 8.4, updated the text such that both out-of-band and
in-band parameter sets transports are possible but neither is
recommended. Clarified that in some scenarios in-band transport is
desired.
- Added section 8.5 (informative) discussing decoder refresh point
procedure in case some parameter sets are lost in in-band
transport.
Editorial changes compared to draft-wang-avt-rfc3984bis-01.txt (the
list is incomplete)
- Added a definition of "static macroblock" in section 4.1.
- Added abbreviations "SAR" and "VUI" in section 4.2.
- Changed the informative reference [15] to normative reference [3].
- Changed "undefined" in all the tables to "reserved".
- Changed "MIME" to "media type" throughout the document.
 End of changes. 161 change blocks. 
1221 lines changed or deleted 724 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/