draft-ietf-avt-rtp-rfc3984bis-02.txt   draft-ietf-avt-rtp-rfc3984bis-03.txt 
Audio/Video Transport WG Y.-K. Wang Audio/Video Transport WG Y.-K. Wang
Internet Draft Nokia Internet Draft Huawei Technologies
Intended status: Standards track R. Even Intended status: Standards track R. Even
Expires: June 2009 Self-employed Expires: August 2009 Self-employed
T. Kristensen T. Kristensen
Tandberg Tandberg
December 16, 2008 February 23, 2009
RTP Payload Format for H.264 Video RTP Payload Format for H.264 Video
draft-ietf-avt-rtp-rfc3984bis-02.txt draft-ietf-avt-rtp-rfc3984bis-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 16, 2009. This Internet-Draft will expire on August 23, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This memo describes an RTP Payload format for the ITU-T This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec, excluding the ISO/IEC International Standard 14496-10 video codec, excluding the
Scalable Video Coding (SVC) extension and the Multivew Video Coding Scalable Video Coding (SVC) extension and the Multivew Video Coding
extension, for which the RTP payload formats are defined elsewhere. extension, for which the RTP payload formats are defined elsewhere.
The RTP payload format allows for packetization of one or more The RTP payload format allows for packetization of one or more
Network Abstraction Layer Units (NALUs), produced by an H.264 video Network Abstraction Layer Units (NALUs), produced by an H.264 video
encoder, in each RTP payload. The payload format has wide encoder, in each RTP payload. The payload format has wide
applicability, as it supports applications from simple low bit-rate applicability, as it supports applications from simple low bit-rate
conversational usage, to Internet video streaming with interleaved conversational usage, to Internet video streaming with interleaved
transmission, to high bit-rate video-on-demand. transmission, to high bit-rate video-on-demand.
This memo intends to obsolete RFC 3984. Changes from RFC 3984 are This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized
summarized in section 17. Issues on backward compatibility to RFC in section 18. Issues on backward compatibility to RFC 3984 are
3984 are discussed in section 16. discussed in section 17.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................4
1.1. The H.264 Codec...........................................3 1.1. The H.264 Codec...........................................4
1.2. Parameter Set Concept.....................................3 1.2. Parameter Set Concept.....................................5
1.3. Network Abstraction Layer Unit Types......................3 1.3. Network Abstraction Layer Unit Types......................6
2. Conventions....................................................3 2. Conventions....................................................7
3. Scope..........................................................3 3. Scope..........................................................7
4. Definitions and Abbreviations..................................3 4. Definitions and Abbreviations..................................7
4.1. Definitions...............................................3 4.1. Definitions...............................................7
4.2. Abbreviations.............................................3 4.2. Abbreviations.............................................9
5. RTP Payload Format.............................................3 5. RTP Payload Format............................................10
5.1. RTP Header Usage..........................................3 5.1. RTP Header Usage.........................................10
5.2. Payload Structures........................................3 5.2. Payload Structures.......................................12
5.3. NAL Unit Header Usage.....................................3 5.3. NAL Unit Header Usage....................................14
5.4. Packetization Modes.......................................3 5.4. Packetization Modes......................................16
5.5. Decoding Order Number (DON)...............................3 5.5. Decoding Order Number (DON)..............................17
5.6. Single NAL Unit Packet....................................3 5.6. Single NAL Unit Packet...................................20
5.7. Aggregation Packets.......................................3 5.7. Aggregation Packets......................................21
5.7.1. Single-Time Aggregation Packet.......................3 5.7.1. Single-Time Aggregation Packet......................23
5.7.2. Multi-Time Aggregation Packets (MTAPs)...............3 5.7.2. Multi-Time Aggregation Packets (MTAPs)..............25
5.7.3. Fragmentation Units (FUs)............................3 5.7.3. Fragmentation Units (FUs)...........................29
6. Packetization Rules............................................3 6. Packetization Rules...........................................33
6.1. Common Packetization Rules................................3 6.1. Common Packetization Rules...............................33
6.2. Single NAL Unit Mode......................................3 6.2. Single NAL Unit Mode.....................................34
6.3. Non-Interleaved Mode......................................3 6.3. Non-Interleaved Mode.....................................34
6.4. Interleaved Mode..........................................3 6.4. Interleaved Mode.........................................34
7. De-Packetization Process.......................................3 7. De-Packetization Process......................................35
7.1. Single NAL Unit and Non-Interleaved Mode..................3 7.1. Single NAL Unit and Non-Interleaved Mode.................35
7.2. Interleaved Mode..........................................3 7.2. Interleaved Mode.........................................35
7.2.1. Size of the De-interleaving Buffer...................3 7.2.1. Size of the De-interleaving Buffer..................36
7.2.2. De-interleaving Process..............................3 7.2.2. De-interleaving Process.............................36
7.3. Additional De-Packetization Guidelines....................3 7.3. Additional De-Packetization Guidelines...................38
8. Payload Format Parameters......................................3 8. Payload Format Parameters.....................................39
8.1. Media Type Registration...................................3 8.1. Media Type Registration..................................39
8.2. SDP Parameters............................................3 8.2. SDP Parameters...........................................56
8.2.1. Mapping of Payload Type Parameters to SDP............3 8.2.1. Mapping of Payload Type Parameters to SDP...........56
8.2.2. Usage with the SDP Offer/Answer Model................3 8.2.2. Usage with the SDP Offer/Answer Model...............57
8.2.3. Usage in Declarative Session Descriptions............3 8.2.3. Usage in Declarative Session Descriptions...........64
8.3. Examples..................................................3 8.3. Examples.................................................65
8.4. Parameter Set Considerations..............................3 8.4. Parameter Set Considerations.............................72
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)...................................3 Parameter Sets (Informative)..................................74
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...............................................3 Refresh Point..............................................75
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.......................................3 Decoder Refresh Point......................................75
9. Security Considerations........................................3 9. Security Considerations.......................................76
10. Congestion Control............................................3 10. Congestion Control...........................................77
11. IANA Consideration............................................3 11. IANA Consideration...........................................77
12. Informative Appendix: Application Examples....................3 12. Informative Appendix: Application Examples...................78
12.1. Video Telephony according to ITU-T Recommendation H.241 12.1. Video Telephony according to ITU-T Recommendation H.241
Annex A........................................................3 Annex A.......................................................78
12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit 12.2. Video Telephony, No Slice Data Partitioning, No NAL Unit
Aggregation....................................................3 Aggregation...................................................78
12.3. Video Telephony, Interleaved Packetization Using NAL Unit 12.3. Video Telephony, Interleaved Packetization Using NAL Unit
Aggregation....................................................3 Aggregation...................................................79
12.4. Video Telephony with Data Partitioning...................3 12.4. Video Telephony with Data Partitioning..................79
12.5. Video Telephony or Streaming with FUs and Forward Error 12.5. Video Telephony or Streaming with FUs and Forward Error
Correction.....................................................3 Correction....................................................80
12.6. Low Bit-Rate Streaming...................................3 12.6. Low Bit-Rate Streaming..................................82
12.7. Robust Packet Scheduling in Video Streaming..............3 12.7. Robust Packet Scheduling in Video Streaming.............83
13. Informative Appendix: Rationale for Decoding Order Number.....3 13. Informative Appendix: Rationale for Decoding Order Number....84
13.1. Introduction.............................................3 13.1. Introduction............................................84
13.2. Example of Multi-Picture Slice Interleaving..............3 13.2. Example of Multi-Picture Slice Interleaving.............84
13.3. Example of Robust Packet Scheduling......................3 13.3. Example of Robust Packet Scheduling.....................86
13.4. Robust Transmission Scheduling of Redundant Coded Slices.3 13.4. Robust Transmission Scheduling of Redundant Coded Slices89
13.5. Remarks on Other Design Possibilities....................3 13.5. Remarks on Other Design Possibilities...................90
14. Acknowledgements..............................................3 14. Acknowledgements.............................................91
15. References....................................................3 15. References...................................................91
15.1. Normative References.....................................3 15.1. Normative References....................................91
15.2. Informative References...................................3 15.2. Informative References..................................92
Authors' Addresses................................................3 16. Authors' Addresses...........................................94
Intellectual Property Statement...................................3 17. Backward Compatibility to RFC 3984...........................94
Disclaimer of Validity............................................3 18. Changes from RFC 3984........................................96
Acknowledgement...................................................3
16. Backward Compatibility to RFC 3984............................3
17. Changes from RFC 3984.........................................3
1. Introduction 1. Introduction
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.
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 name H.264 is used for the
the codec and the standard, but the memo is equally applicable to 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.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized
in section 18. Issues on backward compatibility to RFC 3984 are
discussed in section 17.
1.1. The H.264 Codec
The H.264 video codec has a very broad application range that covers The H.264 video codec has a very broad application range that covers
all forms of digital compressed video from, low bit-rate Internet all forms of digital compressed video, from low bit-rate Internet
streaming applications to HDTV broadcast and Digital Cinema streaming applications to HDTV broadcast and Digital Cinema
applications with nearly lossless coding. Compared to the current applications with nearly lossless coding. Compared to the current
state of technology, the overall performance of H.264 is such that state of technology, the overall performance of H.264 is such that
bit rate savings of 50% or more are reported. Digital Satellite TV bit rate savings of 50% or more are reported. Digital Satellite TV
quality, for example, was reported to be achievable at 1.5 Mbit/s, quality, for example, was reported to be achievable at 1.5 Mbit/s,
compared to the current operation point of MPEG 2 video at around 3.5 compared to the current operation point of MPEG 2 video at around 3.5
Mbit/s [10]. Mbit/s [10].
The codec specification [1] itself distinguishes conceptually between The codec specification [1] itself distinguishes conceptually between
a video coding layer (VCL) and a network abstraction layer (NAL). a video coding layer (VCL) and a network abstraction layer (NAL).
skipping to change at page 9, line 37 skipping to change at page 9, line 37
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 default sub-profile: The subset of coding tools, which may be all
coding tools of one profile or the common subset of coding tools coding tools of one profile or the common subset of coding tools
of more than one profile, indicated by the profile-level-id of more than one profile, indicated by the profile-level-id
parameter. In SDP Offer/Answer, the default sub-profile must be parameter.
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 default level: The level indicated by the profile-level-id
parameter. In SDP Offer/Answer, level is downgradable, i.e., the parameter, which consists of three octets, profile_idc, profile-
answer may either use the default level or a lower level. iop, and level_idc. The default level is indicated by level_idc
in most cases, and, in some cases, additionally by profile-iop.
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
skipping to change at page 12, line 6 skipping to change at page 11, line 35
is outside the scope of this document and will not be specified is outside the scope of this document and will not be specified
here. The assignment of a payload type has to be performed here. The assignment of a payload type has to be performed
either through the profile used or in a dynamic way. either through the profile used or in a dynamic way.
Sequence number (SN): 16 bits Sequence number (SN): 16 bits
Set and used in accordance with RFC 3550. For the single NALU Set and used in accordance with RFC 3550. For the single NALU
and non-interleaved packetization mode, the sequence number is and non-interleaved packetization mode, the sequence number is
used to determine decoding order for the NALU. used to determine decoding order for the NALU.
Timestamp: 32 bits Timestamp: 32 bits
The RTP timestamp is set to the sampling timestamp of the The RTP timestamp is set to the sampling timestamp of the content.
content. A 90 kHz clock rate MUST be used. A 90 kHz clock rate MUST be used.
If the NAL unit has no timing properties of its own (e.g., If the NAL unit has no timing properties of its own (e.g.,
parameter set and SEI NAL units), the RTP timestamp is set to the parameter set and SEI NAL units), the RTP timestamp is set to the
RTP timestamp of the primary coded picture of the access unit in RTP timestamp of the primary coded picture of the access unit in
which the NAL unit is included, according to section 7.4.1.2 of which the NAL unit is included, according to section 7.4.1.2 of
[1]. [1].
The setting of the RTP Timestamp for MTAPs is defined in section The setting of the RTP Timestamp for MTAPs is defined in section
5.7.2. 5.7.2.
Receivers SHOULD ignore any picture timing SEI messages included Receivers SHOULD ignore any picture timing SEI messages included
in access units that have only one display timestamp. Instead, in access units that have only one display timestamp. Instead,
receivers SHOULD use the RTP timestamp for synchronizing the receivers SHOULD use the RTP timestamp for synchronizing the
display process. display process.
RTP senders SHOULD NOT transmit picture timing SEI messages for RTP senders SHOULD NOT transmit picture timing SEI messages for
pictures that are not supposed to be displayed as multiple pictures that are not supposed to be displayed as multiple fields.
fields.
If one access unit has more than one display timestamp carried in If one access unit has more than one display timestamp carried in
a picture timing SEI message, then the information in the SEI a picture timing SEI message, then the information in the SEI
message SHOULD be treated as relative to the RTP timestamp, with message SHOULD be treated as relative to the RTP timestamp, with
the earliest event occurring at the time given by the RTP the earliest event occurring at the time given by the RTP
timestamp, and subsequent events later, as given by the timestamp, and subsequent events later, as given by the
difference in SEI message picture timing values. Let tSEI1, difference in SEI message picture timing values. Let tSEI1,
tSEI2, ..., tSEIn be the display timestamps carried in the SEI tSEI2, ..., tSEIn be the display timestamps carried in the SEI
message of an access unit, where tSEI1 is the earliest of all message of an access unit, where tSEI1 is the earliest of all
such timestamps. Let tmadjst() be a function that adjusts the such timestamps. Let tmadjst() be a function that adjusts the
skipping to change at page 13, line 19 skipping to change at page 12, line 46
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 inter-arrival 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,
and, in some cases, as the first byte of the payload. This byte is in some cases, as the first byte of the payload. This byte is always
always structured as a NAL unit header. The NAL unit type field structured as a NAL unit header. The NAL unit type field indicates
indicates which structure is present. The possible structures are as which structure is present. The possible structures are as follows:
follows:
Single NAL Unit Packet: Contains only a single NAL unit in the Single NAL Unit Packet: Contains only a single NAL unit in the
payload. The NAL header type field will be equal to the original NAL payload. The NAL header type field will be equal to the original NAL
unit type; i.e., in the range of 1 to 23, inclusive. Specified in unit type; i.e., in the range of 1 to 23, inclusive. Specified in
section 5.6. section 5.6.
Aggregation Packet: Packet type used to aggregate multiple NAL units Aggregation Packet: Packet type used to aggregate multiple NAL units
into a single RTP payload. This packet exists in four versions, the into a single RTP payload. This packet exists in four versions, the
Single-Time Aggregation Packet type A (STAP-A), the Single-Time Single-Time Aggregation Packet type A (STAP-A), the Single-Time
Aggregation Packet type B (STAP-B), Multi-Time Aggregation Packet Aggregation Packet type B (STAP-B), Multi-Time Aggregation Packet
skipping to change at page 13, line 50 skipping to change at page 13, line 30
RTP packets. Exists with two versions, FU-A and FU-B, identified RTP packets. Exists with two versions, FU-A and FU-B, identified
with the NAL unit type numbers 28 and 29, respectively. Specified in with the NAL unit type numbers 28 and 29, respectively. Specified in
section 5.8. section 5.8.
Informative note: This specification does not limit the size of Informative note: This specification does not limit the size of
NAL units encapsulated in single NAL unit packets and NAL units encapsulated in single NAL unit packets and
fragmentation units. The maximum size of a NAL unit encapsulated fragmentation units. The maximum size of a NAL unit encapsulated
in any aggregation packet is 65535 bytes. in any aggregation packet is 65535 bytes.
Table 1 summarizes NAL unit types and the corresponding RTP packet Table 1 summarizes NAL unit types and the corresponding RTP packet
types when each of these NAL units is directly used a packet payload, types when each of these NAL units is directly used as a packet
and where the types are described in this memo. payload, and where the types are described in this memo.
Table 1. Summary of NAL unit types and the corresponding packet Table 1. Summary of NAL unit types and the corresponding packet
types types
NAL Unit Packet Packet Type Name Section NAL Unit Packet Packet Type Name Section
Type Type Type Type
--------------------------------------------------------- ---------------------------------------------------------
0 reserved - 0 reserved -
1-23 NAL unit Single NAL unit packet 5.6 1-23 NAL unit Single NAL unit packet 5.6
24 STAP-A Single-time aggregation packet 5.7.1 24 STAP-A Single-time aggregation packet 5.7.1
skipping to change at page 23, line 11 skipping to change at page 23, line 11
fragmentation units specified in section 5.8. Aggregation packets fragmentation units specified in section 5.8. Aggregation packets
MUST NOT be nested; i.e., an aggregation packet MUST NOT contain MUST NOT be nested; i.e., an aggregation packet MUST NOT contain
another aggregation packet. another aggregation packet.
5.7.1. Single-Time Aggregation Packet 5.7.1. Single-Time Aggregation Packet
Single-time aggregation packet (STAP) SHOULD be used whenever NAL Single-time aggregation packet (STAP) SHOULD be used whenever NAL
units are aggregated that all share the same NALU-time. The payload units are aggregated that all share the same NALU-time. The payload
of an STAP-A does not include DON and consists of at least one of an STAP-A does not include DON and consists of at least one
single-time aggregation unit, as presented in Figure 4. The payload single-time aggregation unit, as presented in Figure 4. The payload
of an STAP-B consists of a 16-bit unsigned decoding order number of an STAP-B consists of a 16-bit unsigned decoding order number (DON)
(DON) (in network byte order) followed by at least one single-time (in network byte order) followed by at least one single-time
aggregation unit, as presented in Figure 5. aggregation unit, as presented in Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: | : |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| | | |
| single-time aggregation units | | single-time aggregation units |
| | | |
skipping to change at page 24, line 24 skipping to change at page 24, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| NAL unit | | NAL unit |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Structure for single-time aggregation unit Figure 6 Structure for single-time aggregation unit
Figure 7 presents an example of an RTP packet that contains an STAP- Figure 7 presents an example of an RTP packet that contains an STAP-A.
A. The STAP contains two single-time aggregation units, labeled as 1 The STAP contains two single-time aggregation units, labeled as 1 and
and 2 in the figure. 2 in the figure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-A NAL HDR | NALU 1 Size | NALU 1 HDR | |STAP-A NAL HDR | NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Data | | NALU 1 Data |
: : : :
skipping to change at page 25, line 4 skipping to change at page 25, line 4
| | NALU 2 Size | NALU 2 HDR | | | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data | | NALU 2 Data |
: : : :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 An example of an RTP packet including an STAP-A containing Figure 7 An example of an RTP packet including an STAP-A containing
two single-time aggregation units two single-time aggregation units
Figure 8 presents an example of an RTP packet that contains an STAP- Figure 8 presents an example of an RTP packet that contains an STAP-B.
B. The STAP contains two single-time aggregation units, labeled as 1 The STAP contains two single-time aggregation units, labeled as 1 and
and 2 in the figure. 2 in the figure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-B NAL HDR | DON | NALU 1 Size | |STAP-B NAL HDR | DON | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR | NALU 1 Data | | NALU 1 Size | NALU 1 HDR | NALU 1 Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
skipping to change at page 26, line 23 skipping to change at page 26, line 23
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 NAL unit payload format for MTAPs Figure 9 NAL unit payload format for MTAPs
Two different multi-time aggregation units are defined in this Two different multi-time aggregation units are defined in this
specification. Both of them consist of 16 bits unsigned size specification. Both of them consist of 16 bits unsigned size
information of the following NAL unit (in network byte order), an 8- information of the following NAL unit (in network byte order), an 8-
bit unsigned decoding order number difference (DOND), and n bits (in bit unsigned decoding order number difference (DOND), and n bits (in
network byte order) of timestamp offset (TS offset) for this NAL network byte order) of timestamp offset (TS offset) for this NAL unit,
unit, whereby n can be 16 or 24. The choice between the different whereby n can be 16 or 24. The choice between the different MTAP
MTAP types (MTAP16 and MTAP24) is application dependent: the larger types (MTAP16 and MTAP24) is application dependent: the larger the
the timestamp offset is, the higher the flexibility of the MTAP, but timestamp offset is, the higher the flexibility of the MTAP, but the
the overhead is also higher. overhead is also higher.
The structure of the multi-time aggregation units for MTAP16 and The structure of the multi-time aggregation units for MTAP16 and
MTAP24 are presented in Figures 10 and 11, respectively. The MTAP24 are presented in Figures 10 and 11, respectively. The
starting or ending position of an aggregation unit within a packet is starting or ending position of an aggregation unit within a packet is
NOT REQUIRED to be on a 32-bit word boundary. The DON of the NAL NOT REQUIRED to be on a 32-bit word boundary. The DON of the NAL
unit contained in a multi-time aggregation unit is equal to (DONB + unit contained in a multi-time aggregation unit is equal to (DONB +
DOND) % 65536, in which % denotes the modulo operation. This memo DOND) % 65536, in which % denotes the modulo operation. This memo
does not specify how the NAL units within an MTAP are ordered, but, does not specify how the NAL units within an MTAP are ordered, but,
in most cases, NAL unit decoding order SHOULD be used. in most cases, NAL unit decoding order SHOULD be used.
skipping to change at page 29, line 41 skipping to change at page 29, line 41
5.7.3. Fragmentation Units (FUs) 5.7.3. Fragmentation Units (FUs)
This payload type allows fragmenting a NAL unit into several RTP This payload type allows fragmenting a NAL unit into several RTP
packets. Doing so on the application layer instead of relying on packets. Doing so on the application layer instead of relying on
lower layer fragmentation (e.g., by IP) has the following advantages: lower layer fragmentation (e.g., by IP) has the following advantages:
o The payload format is capable of transporting NAL units bigger o The payload format is capable of transporting NAL units bigger
than 64 kbytes over an IPv4 network that may be present in pre- than 64 kbytes over an IPv4 network that may be present in pre-
recorded video, particularly in High Definition formats (there is recorded video, particularly in High Definition formats (there is
a limit of the number of slices per picture, which results in a a limit of the number of slices per picture, which results in a
limit of NAL units per picture, which may result in big NAL limit of NAL units per picture, which may result in big NAL units).
units).
o The fragmentation mechanism allows fragmenting a single NAL unit o The fragmentation mechanism allows fragmenting a single NAL unit
and applying generic forward error correction as described in and applying generic forward error correction as described in
section 12.5. section 12.5.
Fragmentation is defined only for a single NAL unit and not for any Fragmentation is defined only for a single NAL unit and not for any
aggregation packets. A fragment of a NAL unit consists of an integer aggregation packets. A fragment of a NAL unit consists of an integer
number of consecutive octets of that NAL unit. Each octet of the NAL number of consecutive octets of that NAL unit. Each octet of the NAL
unit MUST be part of exactly one fragment of that NAL unit. unit MUST be part of exactly one fragment of that NAL unit.
Fragments of the same NAL unit MUST be sent in consecutive order with Fragments of the same NAL unit MUST be sent in consecutive order with
ascending RTP sequence numbers (with no other RTP packets within the ascending RTP sequence numbers (with no other RTP packets within the
same RTP packet stream being sent between the first and last same RTP packet stream being sent between the first and last
fragment). Similarly, a NAL unit MUST be reassembled in RTP sequence fragment). Similarly, a NAL unit MUST be reassembled in RTP sequence
number order. number order.
When a NAL unit is fragmented and conveyed within fragmentation units When a NAL unit is fragmented and conveyed within fragmentation units
(FUs), it is referred to as a fragmented NAL unit. STAPs and MTAPs (FUs), it is referred to as a fragmented NAL unit. STAPs and MTAPs
MUST NOT be fragmented. FUs MUST NOT be nested; i.e., an FU MUST NOT MUST NOT be fragmented. FUs MUST NOT be nested; i.e., an FU MUST NOT
contain another FU. contain another FU.
skipping to change at page 35, line 11 skipping to change at page 35, line 11
mode. STAP-Bs, MTAPs, FU-As, and FU-Bs MAY be used. STAP-As and mode. STAP-Bs, MTAPs, FU-As, and FU-Bs MAY be used. STAP-As and
single NAL unit packets MUST NOT be used. The transmission order of single NAL unit packets MUST NOT be used. The transmission order of
packets and NAL units is constrained as specified in section 5.5. packets and NAL units is constrained as specified in section 5.5.
7. De-Packetization Process 7. De-Packetization Process
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 same output means that the number of NAL units and their order
order are both the identical. Optimizations relative to the are both identical respectively. 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 de- the interleaved mode. Section 7.3 includes additional de-
packetization 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
skipping to change at page 36, line 14 skipping to change at page 36, line 14
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 de-interleaving buffer in this section. Receivers SHOULD also the de-interleaving buffer in this section. Receivers SHOULD also
prepare for transmission delay jitter; i.e., either reserve separate prepare for transmission delay jitter; i.e., either reserve separate
buffers for transmission delay jitter buffering and de-interleaving buffers for transmission delay jitter buffering and de-interleaving
buffering or use a receiver buffer for both transmission delay jitter buffering or use a receiver buffer for both transmission delay jitter
and de-interleaving. Moreover, receivers SHOULD take transmission and de-interleaving. Moreover, receivers SHOULD take transmission
delay jitter into account in the buffering operation; e.g., by delay jitter into account in the buffering operation; e.g., by
additional initial buffering before starting of decoding and 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 de-interleaving 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 De-interleaving Buffer 7.2.1. Size of the De-interleaving Buffer
When the SDP Offer/Answer model or any other capability exchange When the SDP Offer/Answer model or any other capability exchange
procedure is used in session setup, the properties of the received procedure is used in session setup, the properties of the received
stream SHOULD be such that the receiver capabilities are not stream SHOULD be such that the receiver capabilities are not exceeded.
exceeded. In the SDP Offer/Answer model, the receiver can indicate In the SDP Offer/Answer model, the receiver can indicate its
its capabilities to allocate a de-interleaving buffer with the deint- capabilities to allocate a de-interleaving buffer with the deint-buf-
buf-cap media type parameter. The sender indicates the requirement cap media type parameter. The sender indicates the requirement for
for the de-interleaving buffer size with the sprop-deint-buf-req the de-interleaving buffer size with the sprop-deint-buf-req media
media type parameter. It is therefore RECOMMENDED to set the de- type parameter. It is therefore RECOMMENDED to set the de-
interleaving 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 the 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 de-interleaving buffer size. It is therefore RECOMMENDED to set the de-interleaving buffer size. It is therefore RECOMMENDED to set
the de-interleaving buffer size, in terms of number of bytes, equal the de-interleaving buffer size, in terms of number of bytes, equal
skipping to change at page 37, line 19 skipping to change at page 37, line 19
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 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 de-interleaving 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
skipping to change at page 38, line 21 skipping to change at page 38, line 21
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 -
PDON. Otherwise, the DON distance is equal to 65535 - PDON + DON PDON. Otherwise, the DON distance is equal to 65535 - PDON + DON
+ 1. + 1.
o NAL units are delivered to the decoder in ascending order of DON o NAL units are delivered to the decoder in ascending order of DON
distance. If several NAL units share the same value of DON distance. If several NAL units share the same value of DON
distance, they can be passed to the decoder in any order. distance, they can be passed to the decoder in any order.
o When a desired number of NAL units have been passed to the o When a desired number of NAL units have been passed to the decoder,
decoder, the value of PDON is set to the value of DON for the last the value of PDON is set to the value of DON for the last NAL unit
NAL unit passed to the decoder. passed to the decoder.
7.3. Additional De-Packetization Guidelines 7.3. Additional De-Packetization Guidelines
The following additional de-packetization rules may be used to The following additional de-packetization rules may be used to
implement an operational H.264 de-packetizer: implement an operational H.264 de-packetizer:
o Intelligent RTP receivers (e.g., in gateways) may identify lost o Intelligent RTP receivers (e.g., in gateways) may identify lost
coded slice data partitions A (DPAs). If a lost DPA is found, a coded slice data partitions A (DPAs). If a lost DPA is found,
after taking into account possible retransmission and FEC, a
gateway may decide not to send the corresponding coded slice data gateway may decide not to send the corresponding coded slice data
partitions B and C, as their information is meaningless for H.264 partitions B and C, as their information is meaningless for H.264
decoders. In this way a MANE can reduce network load by decoders. In this way a MANE can reduce network load by
discarding useless packets without parsing a complex bitstream. discarding useless packets without parsing a complex bitstream.
o Intelligent RTP receivers (e.g., in gateways) may identify lost o Intelligent RTP receivers (e.g., in gateways) may identify lost
FUs. If a lost FU is found, a gateway may decide not to send the FUs. If a lost FU is found, a gateway may decide not to send the
following FUs of the same fragmented NAL unit, as their following FUs of the same fragmented NAL unit, as their
information is meaningless for H.264 decoders. In this way a MANE information is meaningless for H.264 decoders. In this way a MANE
can reduce network load by discarding useless packets without can reduce network load by discarding useless packets without
skipping to change at page 42, line 50 skipping to change at page 42, line 50
receiver implementation. These parameters MUST NOT be used for receiver implementation. These parameters MUST NOT be used for
any other purpose. The profile-level-id parameter MUST be any other purpose. The profile-level-id parameter MUST be
present in the same receiver capability description that present in the same receiver capability description that
contains any of these parameters. The level conveyed in the contains any of these parameters. The level conveyed in the
value of the profile-level-id parameter MUST be such that the value of the profile-level-id parameter MUST be such that the
receiver is fully capable of supporting. max-mbps, max-smbps, receiver is fully capable of supporting. max-mbps, max-smbps,
max-fs, max-cpb, max-dpb, and max-br MAY be used to indicate max-fs, max-cpb, max-dpb, and max-br MAY be used to indicate
capabilities of the receiver that extend the required capabilities of the receiver that extend the required
capabilities of the signaled level, as specified below. capabilities of the signaled level, as specified below.
When more than one parameter from the set (max-mbps, max-smbps When more than one parameter from the set (max-mbps, max-
, max-fs, max-cpb, max-dpb, max-br) is present, the receiver smbps , max-fs, max-cpb, max-dpb, max-br) is present, the
MUST support all signaled capabilities simultaneously. For receiver MUST support all signaled capabilities simultaneously.
example, if both max-mbps and max-br are present, the signaled For example, if both max-mbps and max-br are present, the
level with the extension of both the frame rate and bit rate signaled level with the extension of both the frame rate and
is supported. That is, the receiver is able to decode NAL bit rate is supported. That is, the receiver is able to
unit streams in which the macroblock processing rate is up to decode NAL unit streams in which the macroblock processing
max-mbps (inclusive), the bit rate is up to max-br rate is up to max-mbps (inclusive), the bit rate is up to max-
(inclusive), the coded picture buffer size is derived as br (inclusive), the coded picture buffer size is derived as
specified in the semantics of the max-br parameter below, and specified in the semantics of the max-br parameter below, and
other properties comply with the level specified in the value other properties comply with the level specified in the value
of the profile-level-id parameter. of the profile-level-id parameter.
If a receiver can support all the properties of level A, the If a receiver can support all the properties of level A, the
level specified in the value of the profile-level-id MUST be level specified in the value of the profile-level-id MUST be
level A (i.e. MUST NOT be lower than level A). In other level A (i.e. MUST NOT be lower than level A). In other words,
words, a sender or receiver MUST NOT signal values of max- a sender or receiver MUST NOT signal values of max-mbps, max-
mbps, max-fs, max-cpb, max-dpb, and max-br that meet the fs, max-cpb, max-dpb, and max-br that meet the requirements of
requirements of a higher level compared to the level specified a higher level compared to the level specified in the value of
in the value of the profile-level-id parameter. the profile-level-id parameter.
Informative note: When the OPTIONAL media type parameters Informative note: When the OPTIONAL media type parameters
are used to signal the properties of a NAL unit stream, are used to signal the properties of a NAL unit stream,
max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br
are not present, and the value of profile-level-id must are not present, and the value of profile-level-id must
always be such that the NAL unit stream complies fully with always be such that the NAL unit stream complies fully with
the specified profile and level. the specified profile and level.
max-mbps: The value of max-mbps is an integer indicating the max-mbps: The value of max-mbps is an integer indicating the
maximum macroblock processing rate in units of macroblocks per maximum macroblock processing rate in units of macroblocks per
skipping to change at page 47, line 39 skipping to change at page 47, line 39
When the profile-level-id parameter is present in the same When the profile-level-id parameter is present in the same
signaling as the redundant-pic-cap parameter, and the profile signaling as the redundant-pic-cap parameter, and the profile
indicated in profile-level-id is such that it disallows the indicated in profile-level-id is such that it disallows the
use of redundant coded pictures (e.g., Main Profile), the use of redundant coded pictures (e.g., Main Profile), the
value of redundant-pic-cap MUST be equal to 0. When a value of redundant-pic-cap MUST be equal to 0. When a
receiver indicates redundant-pic-cap equal to 0, the received receiver indicates redundant-pic-cap equal to 0, the received
stream SHOULD NOT contain redundant coded pictures. stream SHOULD NOT contain redundant coded pictures.
Informative note: Even if redundant-pic-cap is equal to 0, Informative note: Even if redundant-pic-cap is equal to 0,
the decoder is able to ignore redundant codec pictures the decoder is able to ignore redundant codec pictures
provided that the decoder supports such a profile provided that the decoder supports such a profile (Baseline,
(Baseline, Extended) in which redundant coded pictures are Extended) in which redundant coded pictures are 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 can be placed in the NAL unit parameter set NAL units) that can be placed in the NAL unit
skipping to change at page 50, line 5 skipping to change at page 50, line 5
parameter-sets, when conveyed using the "fmtp" source parameter-sets, when conveyed using the "fmtp" source
attribute as specified in section 6.3 of [9]. Assume that attribute as specified in section 6.3 of [9]. Assume that
the offered payload type was accepted at a level lower than the offered payload type was accepted at a level lower than
the default level. If the offered payload type included the default level. If the offered payload type included
sprop-level-parameter-sets or included sprop-parameter-sets sprop-level-parameter-sets or included sprop-parameter-sets
conveyed using the "fmtp" source attribute, and the offerer conveyed using the "fmtp" source attribute, and the offerer
sees that the answerer has not included use-level-src- sees that the answerer has not included use-level-src-
parameter-sets equal to 1 in the answer, the offerer gets parameter-sets equal to 1 in the answer, the offerer gets
to know that in-band transport of parameter sets is needed. to know that in-band transport of parameter sets is needed.
in-band-parameter-sets:
This parameter MAY be used to indicate a receiver capability.
The value MAY be equal to either 0 or 1. The value 1
indicates that receiver discards out-of-band parameter sets in
sprop-parameter-sets and sprop-level-parameter-sets, therefore
the sender MUST transmit all parameter sets in-band. The
value 0 indicates that the receiver utilizes out-of-band
parameter sets included in sprop-parameter-sets and sprop-
level-parameter-sets. When in-band-parameter-sets is equal to
1, use-level-src-parameter-sets MUST NOT be present or MUST be
equal to 0. When the parameter is not present, this receiver
capability is not specified, and therefore the sender MAY send
out-of-band parameter sets only, or it MAY send in-band-
parameter-sets only, or it MAY send both to make sure the
system work.
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 52, line 8 skipping to change at page 52, line 24
unit decoding order from the transmission order. The unit decoding order from the transmission order. The
parameter is the maximum value of (decoding time of the NAL 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.
An example of specifying the value of sprop-init-buf-time An example of specifying the value of sprop-init-buf-time
follows. A NAL unit stream is sent in the following follows. A NAL unit stream is sent in the following
interleaved order, in which the value corresponds to the interleaved order, in which the value corresponds to the
decoding time and the transmission order is from left to decoding time and the transmission order is from left to right:
right:
0 2 1 3 5 4 6 8 7 ... 0 2 1 3 5 4 6 8 7 ...
Assuming a steady transmission rate of NAL units, the Assuming a steady transmission rate of NAL units, the
transmission times are: transmission times are:
0 1 2 3 4 5 6 7 8 ... 0 1 2 3 4 5 6 7 8 ...
Subtracting the decoding time from the transmission time Subtracting the decoding time from the transmission time
column-wise results in the following series: column-wise results in the following series:
skipping to change at page 55, line 36 skipping to change at page 55, line 51
Additional information: Additional information:
None None
File extensions: none File extensions: none
Macintosh file type code: none Macintosh file type code: none
Object identifier or OID: none Object identifier or OID: none
Person & email address to contact for further information: Person & email address to contact for further information:
Ye-Kui Wang, ye-kui.wang@nokia.com Ye-Kui Wang, yekuiwang@huawei.com
Intended usage: COMMON Intended usage: COMMON
Author: Author:
Ye-Kui Wang, ye-kui.wang@nokia.com Ye-Kui Wang, yekuiwang@huawei.com
Change controller: Change controller:
IETF Audio/Video Transport working group delegated from the IETF Audio/Video Transport working group delegated from the
IESG. IESG.
8.2. SDP Parameters 8.2. SDP Parameters
8.2.1. Mapping of Payload Type Parameters to SDP 8.2.1. Mapping of Payload Type Parameters to SDP
The media type video/H264 string is mapped to fields in the Session The media type video/H264 string is mapped to fields in the Session
skipping to change at page 56, line 21 skipping to change at page 56, line 29
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", "use-level-src-parameter-sets", "packetization-mode", cap", "use-level-src-parameter-sets", "in-band-parameter-sets",
"sprop-interleaving-depth", "sprop-deint-buf-req", "deint-buf- "packetization-mode", "sprop-interleaving-depth", "sprop-deint-
cap", "sprop-init-buf-time", "sprop-max-don-diff", "max-rcmd-nalu- buf-req", "deint-buf-cap", "sprop-init-buf-time", "sprop-max-don-
size", "sar-understood", and "sar-supported", when present, MUST diff", "max-rcmd-nalu-size", "sar-understood", and "sar-supported",
be included in the "a=fmtp" line of SDP. These parameters are when present, MUST be included in the "a=fmtp" line of SDP. These
expressed as a media type string, in the form of a semicolon parameters are expressed as a media type string, in the form of a
separated list of parameter=value pairs. semicolon separated list of parameter=value pairs.
o The OPTIONAL parameters "sprop-parameter-sets" and "sprop-level- o The OPTIONAL parameters "sprop-parameter-sets" and "sprop-level-
parameter-sets", when present, MUST be included in the "a=fmtp" parameter-sets", when present, MUST be included in the "a=fmtp"
line of SDP or conveyed using the "fmtp" source attribute as line of SDP or conveyed using the "fmtp" source attribute as
specified in section 6.3 of [9]. For a particular media format specified in section 6.3 of [9]. For a particular media format
(i.e., RTP payload type), a "sprop-parameter-sets" or "sprop- (i.e., RTP payload type), a "sprop-parameter-sets" or "sprop-
level-parameter-sets" MUST NOT be both included in the "a=fmtp" level-parameter-sets" MUST NOT be both included in the "a=fmtp"
line of SDP and conveyed using the "fmtp" source attribute. When line of SDP and conveyed using the "fmtp" source attribute. When
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
skipping to change at page 58, line 35 skipping to change at page 58, line 44
"sprop-max-don-diff", and "sprop-init-buf-time" describe the "sprop-max-don-diff", and "sprop-init-buf-time" describe the
properties of the RTP packet stream that the offerer or answerer properties of the RTP packet stream that the offerer or answerer
is sending for the media format configuration. This differs from is sending for the media format configuration. This differs from
the normal usage of the Offer/Answer parameters: normally such the normal usage of the Offer/Answer parameters: normally such
parameters declare the properties of the stream that the offerer parameters declare the properties of the stream that the offerer
or the answerer is able to receive. When dealing with H.264, the or the answerer is able to receive. When dealing with H.264, the
offerer assumes that the answerer will be able to receive media offerer assumes that the answerer will be able to receive media
encoded using the configuration being offered. encoded using the configuration being offered.
Informative note: The above parameters apply for any stream Informative note: The above parameters apply for any stream
sent by the declaring entity with the same configuration; sent by the declaring entity with the same configuration; i.e.,
i.e., they are dependent on their source. Rather than being they are dependent on their source. Rather than being bound
bound to the payload type, the values may have to be applied to the payload type, the values may have to be applied to
to another payload type when being sent, as they apply for the 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", "sar-understood", "sar-supported") MAY be used to nalu-size", "sar-understood", "sar-supported") MAY be used to
declare further capabilities of the offerer or answerer for declare further capabilities of the offerer or answerer for
receiving. These parameters can only be present when the receiving. These parameters can only be present when the
direction attribute is sendrecv or recvonly, and the parameters direction attribute is sendrecv or recvonly, and the parameters
describe the limitations of what the offerer or answerer accepts describe the limitations of what the offerer or answerer accepts
for receiving streams. for receiving streams.
skipping to change at page 59, line 28 skipping to change at page 59, line 37
However, when out-of-band transport of parameter sets is used, However, when out-of-band transport of parameter sets is used,
parameter sets MAY still be additionally transported in-band. If parameter sets MAY still be additionally transported in-band. If
neither "sprop-parameter-sets" nor "sprop-level-parameter-sets" is neither "sprop-parameter-sets" nor "sprop-level-parameter-sets" is
present, then only in-band transport of parameter sets is used. present, then only in-band transport of parameter sets is used.
An offer MAY include either or both of "sprop-parameter-sets" and An offer MAY include either or both of "sprop-parameter-sets" and
"sprop-level-parameter-sets". An answer MAY include "sprop- "sprop-level-parameter-sets". An answer MAY include "sprop-
parameter-sets", and MUST NOT include "sprop-level-parameter- parameter-sets", and MUST NOT include "sprop-level-parameter-
sets". sets".
When an offered payload type is accepted without level downgrade, If the answer includes "in-band-parameter-sets" equal to 1, then
i.e. the default level is accepted, the following applies. the sender MUST transmit parameter sets in-band.
Otherwise, the following applies.
o When an offered payload type is accepted without level
downgrade, i.e. the default level is accepted, the following
applies.
o When there is a "sprop-parameter-sets" included in the o When there is a "sprop-parameter-sets" included in the
"a=fmtp" line of SDP, the answerer MUST be prepared to use "a=fmtp" line of SDP, the answerer MUST be prepared to
the parameter sets included in "sprop-parameter-sets" for use the parameter sets included in "sprop-parameter-sets"
decoding the incoming NAL unit stream. for decoding the incoming NAL unit stream.
o When there is a "sprop-parameter-sets" conveyed using the o When there is a "sprop-parameter-sets" conveyed using the
"fmtp" source attribute as specified in section 6.3 of [9], "fmtp" source attribute as specified in section 6.3 of
and the answerer understands the "fmtp" source attribute, it [9], and the answerer understands the "fmtp" source
MUST be prepared to use the parameter sets included in attribute, it MUST be prepared to use the parameter sets
"sprop-parameter-sets" for decoding the incoming NAL unit included in "sprop-parameter-sets" for decoding the
stream, and it MUST include either "use-level-src-parameter- incoming NAL unit stream, and it MUST include either
sets" equal to 1 or the "fmtp" source attribute in the "use-level-src-parameter-sets" equal to 1 or the "fmtp"
answer. source attribute in the answer.
o When there is a "sprop-parameter-sets" conveyed using the o When there is a "sprop-parameter-sets" conveyed using the
"fmtp" source attribute as specified in section 6.3 of [9], "fmtp" source attribute as specified in section 6.3 of
and the answerer does not understand the "fmtp" source [9], and the answerer does not understand the "fmtp"
attribute, in-band transport of parameter sets MUST be used, source attribute, the sender MUST transmit parameter sets
and the answerer MUST NOT include "use-level-src-parameter- in-band, and the answerer MUST NOT include "use-level-
sets" equal to 1 or the "fmtp" source attribute in the src-parameter-sets" equal to 1 or the "fmtp" source
answer. attribute in the answer.
o When "sprop-parameter-sets" is not present, in-band o When "sprop-parameter-sets" is not present, the sender
transport of parameter sets MUST be used, and the answer MUST transmit parameter sets in-band.
MUST NOT include "use-level-src-parameter-sets" equal to 1.
o The answerer MUST ignore "sprop-level-parameter-sets", when o The answerer MUST ignore "sprop-level-parameter-sets",
present (either included in the "a=fmtp" line of SDP or when present (either included in the "a=fmtp" line of SDP
conveyed using the "fmtp" source attribute). or conveyed using the "fmtp" source attribute).
When level downgrade is in use, i.e., a level lower than the o When level downgrade is in use, i.e., a level lower than the
default level offered is accepted, the following applies. default level offered is accepted, the following applies.
o The answerer MUST ignore "sprop-parameter-sets", when o The answerer MUST ignore "sprop-parameter-sets", when
present (either included in the "a=fmtp" line of SDP or present (either included in the "a=fmtp" line of SDP or
conveyed using the "fmtp" source attribute). conveyed using the "fmtp" source attribute).
o If "use-level-src-parameter-sets" equal to 1 the "fmtp" o When "use-level-src-parameter-sets" equal to 1 and the
source attribute are not present in the answer for the "fmtp" source attribute are not present in the answer for
accepted payload type, the answerer MUST ignore "sprop- the accepted payload type, the answerer MUST ignore
level-parameter-sets", when present. "sprop-level-parameter-sets", when present, and the
sender MUST transmit parameter sets in-band.
o Otherwise ("use-level-src-parameter-sets" equal to 1 or the o When "use-level-src-parameter-sets" equal to 1 or the
"fmtp" source attribute is present in the answer for the "fmtp" source attribute is present in the answer for the
accepted payload type), the answerer MUST be prepared to use accepted payload type, the answerer MUST be prepared to
the parameter sets that are included in "sprop-level- use the parameter sets that are included in "sprop-level-
parameter-sets" for the accepted level, when present, for parameter-sets" for the accepted level, when present, for
decoding the incoming NAL unit stream, and ignore all other decoding the incoming NAL unit stream, and ignore all
parameter sets included in "sprop-level-parameter-sets". other parameter sets included in "sprop-level-parameter-
sets".
o When no parameter sets for the accepted level are present in o When no parameter sets for the accepted level are present
the "sprop-level-parameter-sets", in-band transport of in the "sprop-level-parameter-sets", the sender MUST
parameter sets MUST be used. transmit parameter sets in-band.
The answerer MAY or MAY not include "sprop-parameter-sets", i.e., 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 the answerer MAY use either out-of-band or in-band transport of
parameter sets for the stream it is sending, regardless of parameter sets for the stream it is sending, regardless of
whether out-of-band parameter sets transport has been used in the whether out-of-band parameter sets transport has been used in the
offerer-to-answerer direction. All parameter sets included in offerer-to-answerer direction. When the offer includes "in-band-
the "sprop-parameter-sets", when present, for the accepted parameter-sets" equal to 1, the answerer MUST not include "sprop-
payload type in an answer MUST be associated with the accepted parameter-sets" and MUST transmit parameter sets in-band. All
level, as indicated by the profile-level-id in the answer for the parameter sets included in the "sprop-parameter-sets", when
accepted payload type. 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 Parameter sets included in "sprop-parameter-sets" in an answer
are independent of those parameter sets included in the offer, as are independent of those parameter sets included in the offer, as
they are used for decoding two different video streams, one from they are used for decoding two different video streams, one from
the answerer to the offerer, and the other in the opposite the answerer to the offerer, and the other in the opposite
direction. The offerer MUST be prepared to use the parameter direction. The offerer MUST be prepared to use the parameter
sets included in the answer's "sprop-parameter-sets", when sets included in the answer's "sprop-parameter-sets", when
present, for decoding the incoming NAL unit stream. present, for decoding the incoming NAL unit stream.
When "sprop-parameter-sets" or "sprop-level-parameter-sets" is When "sprop-parameter-sets" or "sprop-level-parameter-sets" is
skipping to change at page 61, line 23 skipping to change at page 61, line 45
Parameter sets associated with one source MUST only be used to Parameter sets associated with one source MUST only be used to
decode NAL units conveyed in RTP packets from the same source. decode NAL units conveyed in RTP packets from the same source.
When this mechanism is in use, SSRC collision detection and When this mechanism is in use, SSRC collision detection and
resolution MUST be performed as specified in [9]. resolution MUST be performed as specified in [9].
Informative note: Conveyance of "sprop-parameter-sets" and Informative note: Conveyance of "sprop-parameter-sets" and
"sprop-level-parameter-sets" using the "fmtp" source attribute "sprop-level-parameter-sets" using the "fmtp" source attribute
may be used in topologies like Topo-Video-switch-MCU [29] to may be used in topologies like Topo-Video-switch-MCU [29] to
enable out-of-band transport of parameter sets. enable out-of-band transport of parameter sets.
For streams being delivered over multicast, the following rules For streams being delivered over multicast, the following rules apply:
apply:
o The media format configuration is identified by the same o The media format configuration is identified by the same
parameters as above for unicast (i.e. "profile-level-id" and parameters as above for unicast (i.e. "profile-level-id" and
"packetization-mode", when present). These media format "packetization-mode", when present). These media format
configuration parameters (including the level part of "profile- configuration parameters (including the level part of "profile-
level-id") MUST be used symmetrically; i.e., the answerer MUST level-id") MUST be used symmetrically; i.e., the answerer MUST
either maintain all configuration parameters or remove the media either maintain all configuration parameters or remove the media
format (payload type) completely. Note that this implies that the format (payload type) completely. Note that this implies that the
level part of "profile-level-id" for Offer/Answer in multicast is level part of "profile-level-id" for Offer/Answer in multicast is
not downgradable. not downgradable.
skipping to change at page 62, line 29 skipping to change at page 63, line 29
max-smbps R R - max-smbps R R -
max-fs R R - max-fs R R -
max-cpb R R - max-cpb R R -
max-dpb R R - max-dpb R R -
max-br R R - max-br R R -
redundant-pic-cap R R - redundant-pic-cap R R -
deint-buf-cap R R - deint-buf-cap R R -
max-rcmd-nalu-size R R - max-rcmd-nalu-size R R -
sar-understood R R - sar-understood R R -
sar-supported R R - sar-supported R R -
in-band-parameter-sets R R -
use-level-src-parameter-sets R R - use-level-src-parameter-sets R R -
sprop-parameter-sets S - S sprop-parameter-sets S - S
sprop-level-parameter-sets S - S sprop-level-parameter-sets S - S
Legend: Legend:
C: configuration for sending and receiving streams C: configuration for sending and receiving streams
P: properties of the stream to be sent P: properties of the stream to be sent
R: receiver capabilities R: receiver capabilities
S: out-of-band parameter sets S: out-of-band parameter sets
skipping to change at page 64, line 25 skipping to change at page 65, line 25
- 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
- deint-buf-cap - deint-buf-cap
- sar-understood - sar-understood
- sar-supported - sar-supported
- in-band-parameter-sets
- use-level-src-parameter-sets - use-level-src-parameter-sets
o A receiver of the SDP is required to support all parameters and o A receiver of the SDP is required to support all parameters and
values of the parameters provided; otherwise, the receiver MUST values of the parameters provided; otherwise, the receiver MUST
reject (RTSP) or not participate in (SAP) the session. It falls reject (RTSP) or not participate in (SAP) the session. It falls
on the creator of the session to use values that are expected to on the creator of the session to use values that are expected to
be supported by the receiving application. be supported by the receiving application.
8.3. Examples 8.3. Examples
skipping to change at page 70, line 20 skipping to change at page 71, line 23
In the following example, the offerer is a Multipoint Control Unit In the following example, the offerer is a Multipoint Control Unit
(MCU) in a Topo-Video-switch-MCU like topology [29], offering (MCU) in a Topo-Video-switch-MCU like topology [29], offering
parameter sets received (using out-of-band transport) from three parameter sets received (using out-of-band transport) from three
other participants B, C, and D, and receiving parameter sets from the other participants B, C, and D, and receiving parameter sets from the
participant A, which is the answerer. The participants are participant A, which is the answerer. The participants are
identified by their values of CNAME, which are mapped to different identified by their values of CNAME, which are mapped to different
SSRC values. The same codec configuration is used by all the four SSRC values. The same codec configuration is used by all the four
participants. The participant A stores and associates the parameter participants. The participant A stores and associates the parameter
sets included in <parameter sets data#B>, <parameter sets data#C>, sets included in <parameter sets data#B>, <parameter sets data#C>,
and <parameter sets data#D> to participants B, C, and D, and <parameter sets data#D> to participants B, C, and D, respectively,
respectively, and uses <parameter sets data#B> for decoding NAL units and uses <parameter sets data#B> for decoding NAL units carried in
carried in RTP packets originated from participant B only, uses RTP packets originated from participant B only, uses <parameter sets
<parameter sets data#C> for decoding NAL units carried in RTP packets data#C> for decoding NAL units carried in RTP packets originated from
originated from participant C only, and uses <parameter sets data#D> participant C only, and uses <parameter sets data#D> for decoding NAL
for decoding NAL units carried in RTP packets originated from units carried in RTP packets originated from participant D only.
participant D only.
Offer SDP: Offer SDP:
m=video 49170 RTP/AVP 98 m=video 49170 RTP/AVP 98
a=ssrc:SSRC-B cname:CNAME-B a=ssrc:SSRC-B cname:CNAME-B
a=ssrc:SSRC-C cname:CNAME-C a=ssrc:SSRC-C cname:CNAME-C
a=ssrc:SSRC-D cname:CNAME-D a=ssrc:SSRC-D cname:CNAME-D
a=ssrc:SSRC-B fmtp:98 a=ssrc:SSRC-B fmtp:98
sprop-parameter-sets=<parameter sets data#B> sprop-parameter-sets=<parameter sets data#B>
a=ssrc:SSRC-C fmtp:98 a=ssrc:SSRC-C fmtp:98
skipping to change at page 71, line 38 skipping to change at page 72, line 40
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
RTP session. RTP session.
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.
Section 8.2.2 includes a detailed discussion on transport of
parameter sets in-band or out-of-band in SDP Offer/Answer using media
type parameters "sprop-parameter-sets", "sprop-level-parameter-sets",
"use-level-src-parameter-sets" and "in-band-parameter-sets". 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 [29] for which the use of principle C may like Topo-Video-switch-MCU [29] for which the use of principle C may
be desirable. 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 (see below), as a loss using a reliable method of delivering of RTP (see below), as a loss
skipping to change at page 72, line 40 skipping to change at page 73, line 46
- 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 [29] the origin of the whole set of parameter sets may MCU [29] 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 identifiers. In this case an offer may overwrite an sets identifiers. In this case an offer may overwrite an
existing parameter set if no other mechanism that enables existing parameter set if no other mechanism that enables
uniqueness of the parameter sets in the out-of-band channel uniqueness of the parameter sets in the out-of-band channel
exists. exists.
- In a multiparty session, one participant MUST associate parameter - In a multiparty session, one participant MUST associate parameter
skipping to change at page 76, line 46 skipping to change at page 77, line 48
to terminate and re-start the media stream. This may be accomplished to terminate and re-start the media stream. This may be accomplished
by using a different RTP payload type. by using a different RTP payload type.
MANEs MAY follow the suggestions outlined in section 7.3 and remove MANEs MAY follow the suggestions outlined in section 7.3 and remove
certain unusable packets from the packet stream when that stream was certain unusable packets from the packet stream when that stream was
damaged due to previous packet losses. This can help reduce the damaged due to previous packet losses. This can help reduce the
network load in certain special cases. network load in certain special cases.
11. IANA Consideration 11. IANA Consideration
IANA has registered one new media type; see section 8.1. The H264 media subtype name specified by RFC 3984 should be updated
as defined in section 8.1 of this memo.
12. Informative Appendix: Application Examples 12. Informative Appendix: Application Examples
This payload specification is very flexible in its use, in order to This payload specification is very flexible in its use, in order to
cover the extremely wide application space anticipated for H.264. cover the extremely wide application space anticipated for H.264.
However, this great flexibility also makes it difficult for an However, this great flexibility also makes it difficult for an
implementer to decide on a reasonable packetization scheme. Some implementer to decide on a reasonable packetization scheme. Some
information on how to apply this specification to real-world information on how to apply this specification to real-world
scenarios is likely to appear in the form of academic publications scenarios is likely to appear in the form of academic publications
and a test model software and description in the near future. and a test model software and description in the near future.
skipping to change at page 77, line 46 skipping to change at page 78, line 46
In most real-world video telephony applications, picture parameters In most real-world video telephony applications, picture parameters
such as picture size or optional modes never change during the such as picture size or optional modes never change during the
lifetime of a connection. Therefore, all necessary parameter sets lifetime of a connection. Therefore, all necessary parameter sets
(usually only one) are sent as a side effect of the capability (usually only one) are sent as a side effect of the capability
exchange/announcement process, e.g., according to the SDP syntax exchange/announcement process, e.g., according to the SDP syntax
specified in section 8.2 of this document. As all necessary specified in section 8.2 of this document. As all necessary
parameter set information is established before the RTP session parameter set information is established before the RTP session
starts, there is no need for sending any parameter set NAL units. starts, there is no need for sending any parameter set NAL units.
Slice data partitioning is not used, either. Thus, the RTP packet Slice data partitioning is not used, either. Thus, the RTP packet
stream basically consists of NAL units that carry single coded stream basically consists of NAL units that carry single coded slices.
slices.
The encoder chooses the size of coded slice NAL units so that they The encoder chooses the size of coded slice NAL units so that they
offer the best performance. Often, this is done by adapting the offer the best performance. Often, this is done by adapting the
coded slice size to the MTU size of the IP network. For small coded slice size to the MTU size of the IP network. For small
picture sizes, this may result in a one-picture-per-one-packet picture sizes, this may result in a one-picture-per-one-packet
strategy. Intra refresh algorithms clean up the loss of packets and strategy. Intra refresh algorithms clean up the loss of packets and
the resulting drift-related artifacts. the resulting drift-related artifacts.
12.3. Video Telephony, Interleaved Packetization Using NAL Unit 12.3. Video Telephony, Interleaved Packetization Using NAL Unit
Aggregation Aggregation
This scheme allows better error concealment and is used in H.263 This scheme allows better error concealment and is used in H.263
based designs using RFC 2429 packetization [11]. It has been based designs using RFC 2429 packetization [11]. It has been
implemented, and good results were reported [13]. implemented, and good results were reported [13].
The VCL encoder codes the source picture so that all macroblocks The VCL encoder codes the source picture so that all macroblocks (MBs)
(MBs) of one MB line are assigned to one slice. All slices with even of one MB line are assigned to one slice. All slices with even MB
MB row addresses are combined into one STAP, and all slices with odd row addresses are combined into one STAP, and all slices with odd MB
MB row addresses into another. Those STAPs are transmitted as RTP row addresses into another. Those STAPs are transmitted as RTP
packets. The establishment of the parameter sets is performed as packets. The establishment of the parameter sets is performed as
discussed above. discussed above.
Note that the use of STAPs is essential here, as the high number of Note that the use of STAPs is essential here, as the high number of
individual slices (18 for a CIF picture) would lead to unacceptably individual slices (18 for a CIF picture) would lead to unacceptably
high IP/UDP/RTP header overhead (unless the source coding tool FMO is high IP/UDP/RTP header overhead (unless the source coding tool FMO is
used, which is not assumed in this scenario). Furthermore, some used, which is not assumed in this scenario). Furthermore, some
wireless video transmission systems, such as H.324M and the IP-based wireless video transmission systems, such as H.324M and the IP-based
video telephony specified in 3GPP, are likely to use relatively small video telephony specified in 3GPP, are likely to use relatively small
transport packet size. For example, a typical MTU size of H.223 AL3 transport packet size. For example, a typical MTU size of H.223 AL3
skipping to change at page 79, line 30 skipping to change at page 80, line 30
Although application layer, end-to-end use of FEC is often less Although application layer, end-to-end use of FEC is often less
efficient than an FEC-based protection of individual links efficient than an FEC-based protection of individual links
(especially when links of different characteristics are in the (especially when links of different characteristics are in the
transmission path), application layer, end-to-end FEC is unavoidable transmission path), application layer, end-to-end FEC is unavoidable
in some scenarios. RFC 5109 [18] provides means to use generic, in some scenarios. RFC 5109 [18] provides means to use generic,
application layer, end-to-end FEC in packet-loss environments. A application layer, end-to-end FEC in packet-loss environments. A
binary forward error correcting code is generated by applying the XOR binary forward error correcting code is generated by applying the XOR
operation to the bits at the same bit position in different packets. operation to the bits at the same bit position in different packets.
The binary code can be specified by the parameters (n,k) in which k The binary code can be specified by the parameters (n,k) in which k
is the number of information packets used in the connection and n is is the number of information packets used in the connection and n is
the total number of packets generated for k information packets; the total number of packets generated for k information packets; i.e.,
i.e., n-k parity packets are generated for k information packets. n-k parity packets are generated for k information packets.
When a code is used with parameters (n,k) within the RFC 5109 When a code is used with parameters (n,k) within the RFC 5109
framework, the following properties are well known: framework, the following properties are well known:
a) If applied over one RTP packet, RFC 5109 provides only packet a) If applied over one RTP packet, RFC 5109 provides only packet
repetition. repetition.
b) RFC 5109 is most bit rate efficient if XOR-connected packets have b) RFC 5109 is most bit rate efficient if XOR-connected packets have
equal length. equal length.
skipping to change at page 82, line 12 skipping to change at page 83, line 12
use of large packets decreases the amount of RTP/UDP/IP header use of large packets decreases the amount of RTP/UDP/IP header
overhead. For low bit-rate video, the use of large packets means overhead. For low bit-rate video, the use of large packets means
that sometimes up to few pictures should be encapsulated in one that sometimes up to few pictures should be encapsulated in one
packet. packet.
However, loss of a packet including many coded pictures would have However, loss of a packet including many coded pictures would have
drastic consequences for visual quality, as there is practically no drastic consequences for visual quality, as there is practically no
other way to conceal a loss of an entire picture than to repeat the other way to conceal a loss of an entire picture than to repeat the
previous one. One way to construct relatively large packets and previous one. One way to construct relatively large packets and
maintain possibilities for successful loss concealment is to maintain possibilities for successful loss concealment is to
construct MTAPs that contain interleaved slices from several construct MTAPs that contain interleaved slices from several pictures.
pictures. An MTAP should not contain spatially adjacent slices from An MTAP should not contain spatially adjacent slices from the same
the same picture or spatially overlapping slices from any picture. picture or spatially overlapping slices from any picture. If a
If a packet is lost, it is likely that a lost slice is surrounded by packet is lost, it is likely that a lost slice is surrounded by
spatially adjacent slices of the same picture and spatially spatially adjacent slices of the same picture and spatially
corresponding slices of the temporally previous and succeeding corresponding slices of the temporally previous and succeeding
pictures. Consequently, concealment of the lost slice is likely to pictures. Consequently, concealment of the lost slice is likely to
be relatively successful. be relatively successful.
12.7. Robust Packet Scheduling in Video Streaming 12.7. Robust Packet Scheduling in Video Streaming
Robust packet scheduling has been implemented with MPEG-4 Part 2 and Robust packet scheduling has been implemented with MPEG-4 Part 2 and
simulated in a wireless streaming environment [21]. There is no simulated in a wireless streaming environment [21]. There is no
technical reason why similar or better results could not be technical reason why similar or better results could not be
skipping to change at page 83, line 38 skipping to change at page 84, line 38
13.2. Example of Multi-Picture Slice Interleaving 13.2. Example of Multi-Picture Slice Interleaving
An example of multi-picture slice interleaving follows. A subset of An example of multi-picture slice interleaving follows. A subset of
a coded video sequence is depicted below in output order. R denotes a coded video sequence is depicted below in output order. R denotes
a reference picture, N denotes a non-reference picture, and the a reference picture, N denotes a non-reference picture, and the
number indicates a relative output time. number indicates a relative output time.
... R1 N2 R3 N4 R5 ... ... R1 N2 R3 N4 R5 ...
The decoding order of these pictures from left to right is as The decoding order of these pictures from left to right is as follows:
follows:
... R1 R3 N2 R5 N4 ... ... R1 R3 N2 R5 N4 ...
The NAL units of pictures R1, R3, N2, R5, and N4 are marked with a The NAL units of pictures R1, R3, N2, R5, and N4 are marked with a
DON equal to 1, 2, 3, 4, and 5, respectively. DON equal to 1, 2, 3, 4, and 5, respectively.
Each reference picture consists of three slice groups that are Each reference picture consists of three slice groups that are
scattered as follows (a number denotes the slice group number for scattered as follows (a number denotes the slice group number for
each macroblock in a QCIF frame): each macroblock in a QCIF frame):
skipping to change at page 89, line 20 skipping to change at page 90, line 20
representation of a picture is decoded incorrectly, a corresponding representation of a picture is decoded incorrectly, a corresponding
redundant coded picture can be decoded. Examples of applications and redundant coded picture can be decoded. Examples of applications and
coding techniques using the redundant codec picture feature include coding techniques using the redundant codec picture feature include
the video redundancy coding [23] and the protection of "key pictures" the video redundancy coding [23] and the protection of "key pictures"
in multicast streaming [24]. in multicast streaming [24].
One property of many error-prone video communications systems is that One property of many error-prone video communications systems is that
transmission errors are often bursty. Therefore, they may affect transmission errors are often bursty. Therefore, they may affect
more than one consecutive transmission packets in transmission order. more than one consecutive transmission packets in transmission order.
In low bit-rate video communication, it is relatively common that an In low bit-rate video communication, it is relatively common that an
entire coded picture can be encapsulated into one transmission entire coded picture can be encapsulated into one transmission packet.
packet. Consequently, a primary coded picture and the corresponding Consequently, a primary coded picture and the corresponding redundant
redundant coded pictures may be transmitted in consecutive packets in coded pictures may be transmitted in consecutive packets in
transmission order. To make the transmission scheme more tolerant of transmission order. To make the transmission scheme more tolerant of
bursty transmission errors, it is beneficial to transmit the primary bursty transmission errors, it is beneficial to transmit the primary
coded picture and redundant coded picture separated by more than a coded picture and redundant coded picture separated by more than a
single packet. The DON concept enables this. single packet. The DON concept enables this.
13.5. Remarks on Other Design Possibilities 13.5. Remarks on Other Design Possibilities
The slice header syntax structure of the H.264 coding standard The slice header syntax structure of the H.264 coding standard
contains the frame_num syntax element that can indicate the decoding contains the frame_num syntax element that can indicate the decoding
order of coded frames. However, the usage of the frame_num syntax order of coded frames. However, the usage of the frame_num syntax
skipping to change at page 89, line 49 skipping to change at page 90, line 49
o Coded slices from multiple coded video sequences cannot be o Coded slices from multiple coded video sequences cannot be
interleaved, as the frame number syntax element is reset to 0 in interleaved, as the frame number syntax element is reset to 0 in
each IDR picture. each IDR picture.
o The coded fields of a complementary field pair share the same o The coded fields of a complementary field pair share the same
value of the frame_num syntax element. Thus, the decoding order value of the frame_num syntax element. Thus, the decoding order
of the coded fields of a complementary field pair cannot be of the coded fields of a complementary field pair cannot be
recovered based on the frame_num syntax element or any other recovered based on the frame_num syntax element or any other
syntax element of the H.264 coding syntax. syntax element of the H.264 coding syntax.
The RTP payload format for transport of MPEG-4 elementary streams The RTP payload format for transport of MPEG-4 elementary streams [25]
[25] enables interleaving of access units and transmission of enables interleaving of access units and transmission of multiple
multiple access units in the same RTP packet. An access unit is access units in the same RTP packet. An access unit is specified in
specified in the H.264 coding standard to comprise all NAL units the H.264 coding standard to comprise all NAL units associated with a
associated with a primary coded picture according to subclause primary coded picture according to subclause 7.4.1.2 of [1].
7.4.1.2 of [1]. Consequently, slices of different pictures cannot be Consequently, slices of different pictures cannot be interleaved, and
interleaved, and the multi-picture slice interleaving technique (see the multi-picture slice interleaving technique (see section 12.6) for
section 12.6) for improved error resilience cannot be used. improved error resilience cannot be used.
14. Acknowledgements 14. Acknowledgements
Stephan Wenger, Miska Hannuksela, Thomas Stockhammer, Magnus Stephan Wenger, Miska Hannuksela, Thomas Stockhammer, Magnus
Westerlund, and David Singer are thanked as the authors of RFC 3984. Westerlund, and David Singer are thanked as the authors of RFC 3984.
Dave Lindbergh, Philippe Gentric, Gonzalo Camarillo, Gary Sullivan, Dave Lindbergh, Philippe Gentric, Gonzalo Camarillo, Gary Sullivan,
Joerg Ott, and Colin Perkins are thanked for careful review during Joerg Ott, and Colin Perkins are thanked for careful review during
the development of RFC 3984. Randell Jesup, Stephen Botzko, Magnus the development of RFC 3984. Randell Jesup, Stephen Botzko, Magnus
Westerlund, Alex Eleftheriadis, and Thomas Schierl are thanked for Westerlund, Alex Eleftheriadis, and Thomas Schierl are thanked for
their valuable comments and inputs during the development of this their valuable comments and inputs during the development of this
skipping to change at page 93, line 5 skipping to change at page 94, line 5
[28] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [28] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[29] Westerlund, M. and Wenger, S., "RTP Topologies", RFC 5117, [29] Westerlund, M. and Wenger, S., "RTP Topologies", RFC 5117,
January 2008. January 2008.
[30] Wenger, S., Chandra, U., and Westerlund, M., "Codec Control [30] Wenger, S., Chandra, U., and Westerlund, M., "Codec Control
Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", Messages in the RTP Audio-Visual Profile with Feedback (AVPF)",
RFC 5104, February 2008. RFC 5104, February 2008.
Authors' Addresses 16. Authors' Addresses
Ye-Kui Wang Ye-Kui Wang
Nokia Research Center Huawei Technologies
P.O. Box 1000 400 Somerset Corporate Blvd
33721 Tampere Bridgewater, NJ 08807
Finland USA
Phone: +358-50-466-7004 Phone: +1-908-393-4758
EMail: ye-kui.wang@nokia.com EMail: yekuiwang@huawei.com
Roni Even Roni Even
14 David Hamelech 14 David Hamelech
Tel Aviv 64953 Tel Aviv 64953
Israel Israel
Phone: +972-545481099 Phone: +972-545481099
Email:ron.even.tlv@gmail.com Email:ron.even.tlv@gmail.com
Tom Kristensen Tom Kristensen
TANDBERG TANDBERG
Philip Pedersens vei 22 Philip Pedersens vei 22
N-1366 Lysaker N-1366 Lysaker
Norway Norway
Phone: +47 67125125 Phone: +47 67125125
Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no
Intellectual Property Statement 17. Backward Compatibility to RFC 3984
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
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.
The technical changes are listed in section 17. The technical changes are listed in section 18.
Items 1), 2), 3), 7), 9), 10), 12), 13) are bug-fix type of changes, Items 1), 2), 3), 7), 9), 10), 12), 13) are bug-fix type of changes,
and do not incur any backward compatibility issues. and do not incur any backward compatibility issues.
Item 4), addition of five new media type parameters, does not incur Item 4), addition of six new media type parameters, does not incur
any backward compatibility issues for SDP Offer/Answer based any backward compatibility issues for SDP Offer/Answer based
applications, as legacy RFC 3984 receivers ignore these parameters, applications, as legacy RFC 3984 receivers ignore these parameters,
and it is fine for legacy RFC 3984 senders not to use these and it is fine for legacy RFC 3984 senders not to use these
parameters as they are optional. However, there is a backward parameters as they are optional. However, there is a backward
compatibility issue for SDP declarative usage based applications, compatibility issue for SDP declarative usage based applications, e.g.
e.g. those using RTSP and SAP, because the SDP receiver per RFC 3984 those using RTSP and SAP, because the SDP receiver per RFC 3984
cannot accept a session for which the SDP includes an unrecognized cannot accept a session for which the SDP includes an unrecognized
parameter. Therefore, the RTSP or SAP server may have to prepare two parameter. Therefore, the RTSP or SAP server may have to prepare two
sets of streams, one for legacy RFC 3984 receivers and one for sets of streams, one for legacy RFC 3984 receivers and one for
receivers according to this memo. receivers according to this memo.
Items 5), 6) and 11) are related to out-of-band transport of Items 5), 6) and 11) are related to out-of-band transport of
parameter sets. When a sender according to this memo is parameter sets. There are following backward compatibility issues.
communicating with a legacy receiver according to RFC 3984, there is
no backward compatibility issue. When the legacy receiver sees an SDP 1) When a legacy sender per RFC 3984 includes parameter sets for a
message with no parameter-add the value of parameter-add is inferred level different than the default level indicated by profile-level-
to be equal to 1 by the legacy receiver (related to change item 5)). id to sprop-parameter-sets, the parameter value of sprop-
As RFC 3984 allows inclusion of any parameter sets in sprop- parameter-sets is invalid to the receiver per this memo and
parameter-sets, it is fine to the legacy receiver to include therefore the session may be rejected.
parameter sets only for the default level in sprop-parameter-sets
(related to change item 6)). When there are new parameters e.g. 2) In SDP Offer/Answer between a legacy offerer per RFC 3984 and an
sprop-level-parameter-sets present, the legacy receiver simply answerer per this memo, when the answerer includes in the answer
ignores them (related to change item 11)). When a legacy sender parameter sets that are not a superset of the parameter sets
according to RFC 3984 is communicating with a receiver according to included in the offer, the parameter value of sprop-parameter-sets
this memo, there is one backward compatibility issue. When the is invalid to offerer and the session may not be initiated
legacy sender includes parameter sets for a level different than the properly (related to change item 11)).
default level indicated by profile-level-id to sprop-parameter-sets,
the parameter value of sprop-parameter-sets is invalid to the 3) When one endpoint A per this memo includes in-band-parameter-sets
receiver and therefore the session may be rejected. In SDP equal to 1, the other side B per RFC 3984 does not understand that
Offer/Answer between a legacy offerer according to RFC 3984 and an it must transmit parameter sets in-band and B may still exclude
answerer according to this memo, when the answerer includes in the parameter sets in the in-band stream it is sending. Consequently
answer parameter sets that are not a superset of the parameter sets endpoint A cannot decode the stream it receives.
included in the offer, the parameter value of sprop-parameter-sets is
invalid to offerer and the session may not be initiated properly
(related to change item 11)).
Item 7), allowance of conveying sprop-parameter-sets and sprop-level- Item 7), allowance of conveying sprop-parameter-sets and sprop-level-
parameter-sets using the "fmtp" source attribute as specified in parameter-sets using the "fmtp" source attribute as specified in
section 6.3 of [9], is similar as item 4). It does not incur any section 6.3 of [9], is similar as item 4). It does not incur any
backward compatibility issues for SDP Offer/Answer based backward compatibility issues for SDP Offer/Answer based applications,
applications, as legacy RFC 3984 receivers ignore the "fmtp" source as legacy RFC 3984 receivers ignore the "fmtp" source attribute, and
attribute, and it is fine for legacy RFC 3984 senders not to use the it is fine for legacy RFC 3984 senders not to use the "fmtp" source
"fmtp" source attribute as it is optional. However, there is a attribute as it is optional. However, there is a backward
backward compatibility issue for SDP declarative usage based compatibility issue for SDP declarative usage based applications, e.g.
applications, e.g. those using RTSP and SAP, because the SDP receiver those using RTSP and SAP, because the SDP receiver per RFC 3984
per RFC 3984 cannot accept a session for which the SDP includes an cannot accept a session for which the SDP includes an unrecognized
unrecognized parameter (i.e., the "fmtp" source attribute). parameter (i.e., the "fmtp" source attribute). Therefore, the RTSP
Therefore, the RTSP or SAP server may have to prepare two sets of or SAP server may have to prepare two sets of streams, one for legacy
streams, one for legacy RFC 3984 receivers and one for receivers RFC 3984 receivers and one for receivers according to this memo.
according to this memo.
Item 14) removed that use of out-of-band transport of parameter sets Item 14) removed that use of out-of-band transport of parameter sets
is recommended. As out-of-band transport of parameter sets is still is recommended. As out-of-band transport of parameter sets is still
allowed, this change does not incur any backward compatibility allowed, this change does not incur any backward compatibility issues.
issues.
Item 15) does not incur any backward compatibility issues as the Item 15) does not incur any backward compatibility issues as the
added subsection 8.5 is informative. added subsection 8.5 is informative.
17. Changes from RFC 3984 18. Changes from RFC 3984
Following is the list of technical changes (including bug fixes) from Following is the list of technical changes (including bug fixes) from
RFC 3984. Besides this list of technical changes, numerous editorial RFC 3984. Besides this list of technical changes, numerous editorial
changes have been made, but not documented in this memo. changes have been made, but not documented in this memo.
1) In subsections 5.4, 5.5, 6.2, 6,3 and 6.4, removed that the 1) In subsections 5.4, 5.5, 6.2, 6,3 and 6.4, removed that the
packetization mode in use may be signaled by external means. packetization mode in use may be signaled by external means.
2) In subsection 7.2.2, changed the sentence 2) In subsection 7.2.2, changed the sentence
skipping to change at page 96, line 47 skipping to change at page 96, line 42
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 five new media type parameters, namely max-smbps, sprop- 4) Added six new media type parameters, namely max-smbps, sprop-
level-parameter-sets, use-level-src-parameter-sets, sar-understood level-parameter-sets, use-level-src-parameter-sets, in-band-
and sar-supported. parameter-sets, 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.1, added a constraint to sprop-parameter-sets such 6) In subsection 8.1, added a constraint to sprop-parameter-sets such
that it can only contain parameter sets for the same profile and that it can only contain parameter sets for the same profile and
level as indicated by profile-level-id. level as indicated by profile-level-id.
7) In subsection 8.2.1, added that sprop-parameter-sets and sprop- 7) In subsection 8.2.1, added that sprop-parameter-sets and sprop-
 End of changes. 89 change blocks. 
354 lines changed or deleted 323 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/