draft-ietf-payload-rtp-h265-09.txt   draft-ietf-payload-rtp-h265-10.txt 
Network Working Group Y.-K. Wang Network Working Group Y.-K. Wang
Internet Draft Qualcomm Internet Draft Qualcomm
Intended status: Standards track Y. Sanchez Intended status: Standards track Y. Sanchez
Expires: October 2015 T. Schierl Expires: November 2015 T. Schierl
Fraunhofer HHI Fraunhofer HHI
S. Wenger S. Wenger
Vidyo Vidyo
M. M. Hannuksela M. M. Hannuksela
Nokia Nokia
April 14, 2015 May 29, 2015
RTP Payload Format for High Efficiency Video Coding RTP Payload Format for High Efficiency Video Coding
draft-ietf-payload-rtp-h265-09.txt draft-ietf-payload-rtp-h265-10.txt
Abstract Abstract
This memo describes an RTP payload format for the video coding This memo describes an RTP payload format for the video coding
standard ITU-T Recommendation H.265 and ISO/IEC International standard ITU-T Recommendation H.265 and ISO/IEC International
Standard 23008-2, both also known as High Efficiency Video Coding Standard 23008-2, both also known as High Efficiency Video Coding
(HEVC) and developed by the Joint Collaborative Team on Video (HEVC) and developed by the Joint Collaborative Team on Video
Coding (JCT-VC). The RTP payload format allows for packetization Coding (JCT-VC). The RTP payload format allows for packetization
of one or more Network Abstraction Layer (NAL) units in each RTP of one or more Network Abstraction Layer (NAL) units in each RTP
packet payload, as well as fragmentation of a NAL unit into packet payload, as well as fragmentation of a NAL unit into
skipping to change at page 2, line 22 skipping to change at page 2, line 22
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." 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 October 14, 2015. This Internet-Draft will expire on November 29, 2015.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
Abstract.........................................................1 Abstract..........................................................1
Status of this Memo..............................................1 Status of this Memo...............................................1
Table of Contents................................................3 Table of Contents.................................................3
1 Introduction...................................................5 1 Introduction....................................................5
1.1 Overview of the HEVC Codec................................5 1.1 Overview of the HEVC Codec.................................5
1.1.1 Coding-Tool Features.................................5 1.1.1 Coding-Tool Features..................................5
1.1.2 Systems and Transport Interfaces.....................7 1.1.2 Systems and Transport Interfaces......................7
1.1.3 Parallel Processing Support.........................14 1.1.3 Parallel Processing Support..........................14
1.1.4 NAL Unit Header.....................................16 1.1.4 NAL Unit Header......................................16
1.2 Overview of the Payload Format...........................18 1.2 Overview of the Payload Format............................18
2 Conventions...................................................18 2 Conventions....................................................19
3 Definitions and Abbreviations.................................19 3 Definitions and Abbreviations..................................19
3.1 Definitions..............................................19 3.1 Definitions...............................................19
3.1.1 Definitions from the HEVC Specification.............19 3.1.1 Definitions from the HEVC Specification..............19
3.1.2 Definitions Specific to This Memo...................21 3.1.2 Definitions Specific to This Memo....................21
3.2 Abbreviations............................................23 3.2 Abbreviations.............................................23
4 RTP Payload Format............................................24 4 RTP Payload Format.............................................25
4.1 RTP Header Usage.........................................24 4.1 RTP Header Usage..........................................25
4.2 Payload Header Usage.....................................27 4.2 Payload Header Usage......................................27
4.3 Transmission Modes.......................................27 4.3 Transmission Modes........................................28
4.4 Payload Structures.......................................29 4.4 Payload Structures........................................29
4.4.1 Single NAL Unit Packets.............................29 4.4.1 Single NAL Unit Packets..............................29
4.4.2 Aggregation Packets (APs)...........................30 4.4.2 Aggregation Packets (APs)............................30
4.4.3 Fragmentation Units (FUs)...........................35 4.4.3 Fragmentation Units (FUs)............................35
4.4.4 PACI packets........................................38 4.4.4 PACI packets.........................................38
4.4.4.1 Reasons for the PACI rules (informative).......41 4.4.4.1 Reasons for the PACI rules (informative)........41
4.4.4.2 PACI extensions (Informative)..................42 4.4.4.2 PACI extensions (Informative)...................42
4.5 Temporal Scalability Control Information.................43 4.5 Temporal Scalability Control Information..................43
4.6 Decoding Order Number....................................45 4.6 Decoding Order Number.....................................45
5 Packetization Rules...........................................47 5 Packetization Rules............................................47
6 De-packetization Process......................................48 6 De-packetization Process.......................................48
7 Payload Format Parameters.....................................51 7 Payload Format Parameters......................................50
7.1 Media Type Registration..................................51 7.1 Media Type Registration...................................51
7.2 SDP Parameters...........................................77 7.2 SDP Parameters............................................76
7.2.1 Mapping of Payload Type Parameters to SDP...........77 7.2.1 Mapping of Payload Type Parameters to SDP............77
7.2.2 Usage with SDP Offer/Answer Model...................78 7.2.2 Usage with SDP Offer/Answer Model....................78
7.2.3 Usage in Declarative Session Descriptions...........87 7.2.3 Usage in Declarative Session Descriptions............87
7.2.4 Parameter Sets Considerations.......................89 7.2.4 Parameter Sets Considerations........................88
7.2.5 Dependency Signaling in Multi-Stream Mode...........89 7.2.5 Dependency Signaling in Multi-Stream Mode............89
8 Use with Feedback Messages....................................89 8 Use with Feedback Messages.....................................89
8.1 Picture Loss Indication (PLI)............................90 8.1 Picture Loss Indication (PLI).............................89
8.2 Slice Loss Indication (SLI)..............................90 8.2 Slice Loss Indication (SLI)...............................90
8.3 Reference Picture Selection Indication (RPSI)............91 8.3 Reference Picture Selection Indication (RPSI).............91
8.4 Full Intra Request (FIR).................................92 8.4 Full Intra Request (FIR)..................................92
9 Security Considerations.......................................93 9 Security Considerations........................................92
10 Congestion Control...........................................94 10 Congestion Control............................................93
11 IANA Consideration...........................................95 11 IANA Consideration............................................95
12 Acknowledgements.............................................95 12 Acknowledgements..............................................95
13 References...................................................96 13 References....................................................95
13.1 Normative References....................................96 13.1 Normative References.....................................95
13.2 Informative References..................................97 13.2 Informative References...................................97
14 Authors' Addresses...........................................99 14 Authors' Addresses............................................99
1 Introduction 1 Introduction
1.1 Overview of the HEVC Codec 1.1 Overview of the HEVC Codec
High Efficiency Video Coding [HEVC], formally known as ITU-T High Efficiency Video Coding [HEVC], formally known as ITU-T
Recommendation H.265 and ISO/IEC International Standard 23008-2 Recommendation H.265 and ISO/IEC International Standard 23008-2
was ratified by ITU-T in April 2013 and reportedly provides was ratified by ITU-T in April 2013 and reportedly provides
significant coding efficiency gains over H.264 [H.264]. significant coding efficiency gains over H.264 [H.264].
skipping to change at page 6, line 18 skipping to change at page 6, line 18
smaller units in a hierarchical quad-tree manner and can smaller units in a hierarchical quad-tree manner and can
represent smaller blocks down to size 4x4. Similarly, the represent smaller blocks down to size 4x4. Similarly, the
transforms used in HEVC can have different sizes, starting from transforms used in HEVC can have different sizes, starting from
4x4 and going up to 32x32. Utilizing large blocks and transforms 4x4 and going up to 32x32. Utilizing large blocks and transforms
contribute to the major gain of HEVC, especially at high contribute to the major gain of HEVC, especially at high
resolutions. resolutions.
Entropy coding Entropy coding
HEVC uses a single entropy coding engine, which is based on HEVC uses a single entropy coding engine, which is based on
Context Adaptive Binary Arithmetic Coding (CABAC), whereas H.264 Context Adaptive Binary Arithmetic Coding (CABAC) [CABAC],
uses two distinct entropy coding engines. CABAC in HEVC shares whereas H.264 uses two distinct entropy coding engines. CABAC in
many similarities with CABAC of H.264, but contains several HEVC shares many similarities with CABAC of H.264, but contains
improvements. Those include improvements in coding efficiency several improvements. Those include improvements in coding
and lowered implementation complexity, especially for parallel efficiency and lowered implementation complexity, especially for
architectures. parallel architectures.
In-loop filtering In-loop filtering
H.264 includes an in-loop adaptive deblocking filter, where the H.264 includes an in-loop adaptive deblocking filter, where the
blocking artifacts around the transform edges in the blocking artifacts around the transform edges in the
reconstructed picture are smoothed to improve the picture quality reconstructed picture are smoothed to improve the picture quality
and compression efficiency. In HEVC, a similar deblocking filter and compression efficiency. In HEVC, a similar deblocking filter
is employed but with somewhat lower complexity. In addition, is employed but with somewhat lower complexity. In addition,
pictures undergo a subsequent filtering operation called Sample pictures undergo a subsequent filtering operation called Sample
Adaptive Offset (SAO), which is a new design element in HEVC. Adaptive Offset (SAO), which is a new design element in HEVC.
skipping to change at page 8, line 41 skipping to change at page 8, line 41
in both VPS and sequence parameter set (SPS) includes 12 bytes of in both VPS and sequence parameter set (SPS) includes 12 bytes of
data to describe the entire bitstream (including all temporally data to describe the entire bitstream (including all temporally
scalable layers, which are referred to as sub-layers in the HEVC scalable layers, which are referred to as sub-layers in the HEVC
specification), and can optionally include more profile, tier and specification), and can optionally include more profile, tier and
level information pertaining to individual temporally scalable level information pertaining to individual temporally scalable
layers. The profile indicator indicates the "best viewed as" layers. The profile indicator indicates the "best viewed as"
profile when the bitstream conforms to multiple profiles, similar profile when the bitstream conforms to multiple profiles, similar
to the major brand concept in the ISO base media file format to the major brand concept in the ISO base media file format
(ISOBMFF) [ISOBMFF] and file formats derived based on ISOBMFF, (ISOBMFF) [ISOBMFF] and file formats derived based on ISOBMFF,
such as the 3GPP file format [3GPPFF]. The profile, tier and such as the 3GPP file format [3GPPFF]. The profile, tier and
level syntax structure also includes the indications of whether level syntax structure also includes indications such as 1)
the bitstream is free of frame-packed content, whether the whether the bitstream is free of frame-packed content, 2) whether
bitstream is free of interlaced source content and free of field the bitstream is free of interlaced source content, and 3)
pictures, i.e. contains only frame pictures of progressive whether the bitstream is free of field pictures. When the answer
source, such that clients/players with no support of post- is yes for both 2) and 3), the bitstream contains only frame
processing functionalities for handling of frame-packed or pictures of progressive source. Based on these indications,
interlaced source content or field pictures can reject those clients/players without support of post-processing
bitstreams. functionalities for handling of frame-packed, interlaced source
content or field pictures can reject those bitstreams that
contain such pictures.
Bitstream and elementary stream Bitstream and elementary stream
HEVC includes a definition of an elementary stream, which is new HEVC includes a definition of an elementary stream, which is new
compared to H.264. An elementary stream consists of a sequence compared to H.264. An elementary stream consists of a sequence
of one or more bitstreams. An elementary stream that consists of of one or more bitstreams. An elementary stream that consists of
two or more bitstreams has typically been formed by splicing two or more bitstreams has typically been formed by splicing
together two or more bitstreams (or parts thereof). When an together two or more bitstreams (or parts thereof). When an
elementary stream contains more than one bitstream, the last NAL elementary stream contains more than one bitstream, the last NAL
unit of the last access unit of a bitstream (except the last unit of the last access unit of a bitstream (except the last
bitstream in the elementary stream) must contain an end of bitstream in the elementary stream) must contain an end of
bitstream NAL unit and the first access unit of the subsequent bitstream NAL unit and the first access unit of the subsequent
bitstream must be an intra random access point (IRAP) access bitstream must be an intra random access point (IRAP) access
unit. This IRAP access unit may be a clean random access (CRA), unit. This IRAP access unit may be a clean random access (CRA),
broken link access (BLA), or instantaneous decoding refresh (IDR) broken link access (BLA), or instantaneous decoding refresh (IDR)
access unit. access unit.
Random access support Random access support
HEVC includes signaling in NAL unit header, through NAL unit HEVC includes signaling in the NAL unit header, through NAL unit
types, of IRAP pictures beyond IDR pictures. Three types of IRAP types, of IRAP pictures beyond IDR pictures. Three types of IRAP
pictures, namely IDR, CRA and BLA pictures are supported, wherein pictures, namely IDR, CRA and BLA pictures are supported, wherein
IDR pictures are conventionally referred to as closed group-of- IDR pictures are conventionally referred to as closed group-of-
pictures (closed-GOP) random access points, and CRA and BLA pictures (closed-GOP) random access points, and CRA and BLA
pictures are those conventionally referred to as open-GOP random pictures are those conventionally referred to as open-GOP random
access points. BLA pictures usually originate from splicing of access points. BLA pictures usually originate from splicing of
two bitstreams or part thereof at a CRA picture, e.g. during two bitstreams or part thereof at a CRA picture, e.g. during
stream switching. To enable better systems usage of IRAP stream switching. To enable better systems usage of IRAP
pictures, altogether six different NAL units are defined to pictures, altogether six different NAL units are defined to
signal the properties of the IRAP pictures, which can be used to signal the properties of the IRAP pictures, which can be used to
skipping to change at page 17, line 19 skipping to change at page 17, line 19
+-------------+-----------------+ +-------------+-----------------+
Figure 1 The structure of HEVC NAL unit header Figure 1 The structure of HEVC NAL unit header
The semantics of the fields in the NAL unit header are as The semantics of the fields in the NAL unit header are as
specified in [HEVC] and described briefly below for convenience. specified in [HEVC] and described briefly below for convenience.
In addition to the name and size of each field, the corresponding In addition to the name and size of each field, the corresponding
syntax element name in [HEVC] is also provided. syntax element name in [HEVC] is also provided.
F: 1 bit F: 1 bit
forbidden_zero_bit. Required to be zero in [HEVC]. HEVC forbidden_zero_bit. Required to be zero in [HEVC]. Note that
declares a value of 1 as a syntax violation. Note that the the inclusion of this bit in the NAL unit header was to enable
inclusion of this bit in the NAL unit header is to enable
transport of HEVC video over MPEG-2 transport systems transport of HEVC video over MPEG-2 transport systems
(avoidance of start code emulations) [MPEG2S]. (avoidance of start code emulations) [MPEG2S]. In the context
of this memo, the value 1 MAY be used to indicate a syntax
violation. For example, when RTP is transported over UDP-lite
[RFC3828] and the receiver decides to feed the video decoder
NAL unit(s) where the corresponding UDP-lite packet failed a
checksum test, then this bit can be set to alarm the decoder
of possible bit errors.
Type: 6 bits Type: 6 bits
nal_unit_type. This field specifies the NAL unit type as nal_unit_type. This field specifies the NAL unit type as
defined in Table 7-1 of [HEVC]. If the most significant bit defined in Table 7-1 of [HEVC]. If the most significant bit
of this field of a NAL unit is equal to 0 (i.e. the value of of this field of a NAL unit is equal to 0 (i.e. the value of
this field is less than 32), the NAL unit is a VCL NAL unit. this field is less than 32), the NAL unit is a VCL NAL unit.
Otherwise, the NAL unit is a non-VCL NAL unit. For a Otherwise, the NAL unit is a non-VCL NAL unit. For a
reference of all currently defined NAL unit types and their reference of all currently defined NAL unit types and their
semantics, please refer to Section 7.4.1 in [HEVC]. semantics, please refer to Section 7.4.1 in [HEVC].
skipping to change at page 22, line 16 skipping to change at page 22, line 19
must rewrite RTCP packets to match the changes to the RTP must rewrite RTCP packets to match the changes to the RTP
stream as specified in Section 7 of [RFC3550]. stream as specified in Section 7 of [RFC3550].
Media Transport: As used in the MRST, MRMT, and SRST definitions Media Transport: As used in the MRST, MRMT, and SRST definitions
below, Media Transport denotes the transport of packets over a below, Media Transport denotes the transport of packets over a
transport association identified by a 5-tuple (source address, transport association identified by a 5-tuple (source address,
source port, destination address, destination port, transport source port, destination address, destination port, transport
protocol). See also Section 2.1.13 of [I-D.ietf-avtext-rtp- protocol). See also Section 2.1.13 of [I-D.ietf-avtext-rtp-
grouping-taxonomy]. grouping-taxonomy].
Informative note: The term "bitstream" in this document is
equivalent to the term "encoded stream" in [I-D.ietf-avtext-
rtp-grouping-taxonomy].
Multiple RTP streams on a Single Transport (MRST): Multiple RTP Multiple RTP streams on a Single Transport (MRST): Multiple RTP
streams carrying a single HEVC bitstream on a Single Transport. streams carrying a single HEVC bitstream on a Single Transport.
See also Section 3.5 of [I-D.ietf-avtext-rtp-grouping-taxonomy]. See also Section 3.5 of [I-D.ietf-avtext-rtp-grouping-taxonomy].
Multiple RTP streams on Multiple Transports (MRMT): Multiple RTP Multiple RTP streams on Multiple Transports (MRMT): Multiple RTP
streams carrying a single HEVC bitstream on Multiple Transports. streams carrying a single HEVC bitstream on Multiple Transports.
See also Section 3.5 of [I-D.ietf-avtext-rtp-grouping-taxonomy]. See also Section 3.5 of [I-D.ietf-avtext-rtp-grouping-taxonomy].
NAL unit decoding order: A NAL unit order that conforms to the NAL unit decoding order: A NAL unit order that conforms to the
constraints on NAL unit order given in Section 7.4.2.4 in [HEVC]. constraints on NAL unit order given in Section 7.4.2.4 in [HEVC].
skipping to change at page 25, line 31 skipping to change at page 25, line 38
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 RTP header according to [RFC3550] Figure 2 RTP header according to [RFC3550]
The RTP header information to be set according to this RTP The RTP header information to be set according to this RTP
payload format is set as follows: payload format is set as follows:
Marker bit (M): 1 bit Marker bit (M): 1 bit
Set for the last packet, carried in the current RTP stream, of Set for the last packet carried in the current RTP stream of
the access unit, in line with the normal use of the M bit in the access unit. This is in line with the normal use of the M
video formats, to allow an efficient playout buffer handling. bit in video formats to allow an efficient playout buffer
When MRST or MRMT is in use, if an access unit appears in handling. When MRST or MRMT is in use, if an access unit
multiple RTP streams, the marker bit is set on each RTP appears in multiple RTP streams, the marker bit is set on each
stream's last packet of the access unit. RTP stream's last packet of the access unit.
Informative note: The content of a NAL unit does not tell Informative note: The content of a NAL unit does not tell
whether or not the NAL unit is the last NAL unit, in whether or not the NAL unit is the last NAL unit, in
decoding order, of an access unit. An RTP sender decoding order, of an access unit. An RTP sender
implementation may obtain this information from the video implementation may obtain these information from the video
encoder. If, however, the implementation cannot obtain encoder. If, however, the implementation cannot obtain
this information directly from the encoder, e.g. when the these information directly from the encoder, e.g. when the
bitstream was pre-encoded, and also there is no timestamp bitstream was pre-encoded, and also there is no timestamp
allocated for each NAL unit, then the sender implementation allocated for each NAL unit, then the sender implementation
can inspect subsequent NAL units in decoding order to can inspect subsequent NAL units in decoding order to
determine whether or not the NAL unit is the last NAL unit determine whether or not the NAL unit is the last NAL unit
of an access unit as follows. A NAL unit naluX is the last of an access unit as follows. A NAL unit is determined to
NAL unit of an access unit if it is the last NAL unit of be the last NAL unit of an access unit if it is the last
the bitstream or the next VCL NAL unit naluY in decoding NAL unit of the bitstream. A NAL unit naluX is also
order has the high-order bit of the first byte after its determined to be the last NAL unit of an access unit if
NAL unit header equal to 1, and all NAL units between naluX both the following conditions are true: 1) the next VCL NAL
and naluY, when present, have nal_unit_type in the range of unit naluY in decoding order has the high-order bit of the
32 to 35, inclusive, equal to 39, or in the ranges of 41 to first byte after its NAL unit header equal to 1, and 2) all
44, inclusive, or 48 to 55, inclusive. NAL units between naluX and naluY, when present, have
nal_unit_type in the range of 32 to 35, inclusive, equal to
39, or in the ranges of 41 to 44, inclusive, or 48 to 55,
inclusive.
Payload type (PT): 7 bits Payload type (PT): 7 bits
The assignment of an RTP payload type for this new packet The assignment of an RTP payload type for this new packet
format is outside the scope of this document and will not be format is outside the scope of this document and will not be
specified here. The assignment of a payload type has to be specified here. The assignment of a payload type has to be
performed either through the profile used or in a dynamic way. performed either through the profile used or in a dynamic way.
Informative note: It is not required to use different Informative note: It is not required to use different
payload type values for different RTP streams in MRST or payload type values for different RTP streams in MRST or
skipping to change at page 27, line 20 skipping to change at page 27, line 29
Synchronization source (SSRC): 32-bits Synchronization source (SSRC): 32-bits
Used to identify the source of the RTP packets. When using Used to identify the source of the RTP packets. When using
SRST, by definition a single SSRC is used for all parts of a SRST, by definition a single SSRC is used for all parts of a
single bitstream. In MRST or MRMT, different SSRCs are used single bitstream. In MRST or MRMT, different SSRCs are used
for each RTP stream containing a subset of the sub-layers of for each RTP stream containing a subset of the sub-layers of
the single (temporally scalable) bitstream. A receiver is the single (temporally scalable) bitstream. A receiver is
required to correctly associate the set of SSRCs that are required to correctly associate the set of SSRCs that are
included parts of the same bitstream. included parts of the same bitstream.
Informative note: The term "bitstream" in this document is
equivalent to the term "encoded stream" in [I-D.ietf-
avtext-rtp-grouping-taxonomy].
4.2 Payload Header Usage 4.2 Payload Header Usage
The first two bytes of the payload of an RTP packet are referred The first two bytes of the payload of an RTP packet are referred
to as the payload header. The payload header consists of the to as the payload header. The payload header consists of the
same fields (F, Type, LayerId, and TID) as the NAL unit header as same fields (F, Type, LayerId, and TID) as the NAL unit header as
shown in Section 1.1.4, irrespective of the type of the payload shown in Section 1.1.4, irrespective of the type of the payload
structure. structure.
The TID value indicates (among other things) the relative The TID value indicates (among other things) the relative
importance of an RTP packet, for example because NAL units importance of an RTP packet, for example because NAL units
skipping to change at page 31, line 39 skipping to change at page 31, line 39
AP may contain non-VCL NAL units for which the TID value in AP may contain non-VCL NAL units for which the TID value in
the NAL unit header may be different than the TID value of the the NAL unit header may be different than the TID value of the
VCL NAL units in the same AP. VCL NAL units in the same AP.
An AP MUST carry at least two aggregation units and can carry as An AP MUST carry at least two aggregation units and can carry as
many aggregation units as necessary; however, the total amount of many aggregation units as necessary; however, the total amount of
data in an AP obviously MUST fit into an IP packet, and the size data in an AP obviously MUST fit into an IP packet, and the size
SHOULD be chosen so that the resulting IP packet is smaller than SHOULD be chosen so that the resulting IP packet is smaller than
the MTU size so to avoid IP layer fragmentation. An AP MUST NOT the MTU size so to avoid IP layer fragmentation. An AP MUST NOT
contain Fragmentation Units (FUs) specified in Section 4.4.3. contain Fragmentation Units (FUs) specified in Section 4.4.3.
APs MUST NOT be nested; i.e. an AP MUST NOT contain another AP. APs MUST NOT be nested; i.e. an AP must not contain another AP.
The first aggregation unit in an AP consists of a conditional 16- The first aggregation unit in an AP consists of a conditional 16-
bit DONL field (in network byte order) followed by a 16-bit bit DONL field (in network byte order) followed by a 16-bit
unsigned size information (in network byte order) that indicates unsigned size information (in network byte order) that indicates
the size of the NAL unit in bytes (excluding these two octets, the size of the NAL unit in bytes (excluding these two octets,
but including the NAL unit header), followed by the NAL unit but including the NAL unit header), followed by the NAL unit
itself, including its NAL unit header, as shown in Figure 5. itself, including its NAL unit header, as shown 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
skipping to change at page 35, line 34 skipping to change at page 35, line 34
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 An example of an AP containing two aggregation units Figure 8 An example of an AP containing two aggregation units
with the DONL and DOND fields with the DONL and DOND fields
4.4.3 Fragmentation Units (FUs) 4.4.3 Fragmentation Units (FUs)
Fragmentation units (FUs) are introduced to enable fragmenting a Fragmentation units (FUs) are introduced to enable fragmenting a
single NAL unit into multiple RTP packets, possibly without single NAL unit into multiple RTP packets, possibly without
cooperation or knowledge of the HEVC encoder. A fragment of a NAL cooperation or knowledge of the HEVC encoder. A fragment of a
unit consists of an integer number of consecutive octets of that NAL unit consists of an integer number of consecutive octets of
NAL unit. Fragments of the same NAL unit MUST be sent in consecutive that NAL unit. Fragments of the same NAL unit MUST be sent in
order with ascending RTP sequence numbers (with no other RTP packets consecutive order with ascending RTP sequence numbers (with no
within the same RTP stream being sent between the first and last other RTP packets within the same RTP stream being sent between
fragment). the first and last fragment).
When a NAL unit is fragmented and conveyed within FUs, it is When a NAL unit is fragmented and conveyed within FUs, it is
referred to as a fragmented NAL unit. APs MUST NOT be referred to as a fragmented NAL unit. APs MUST NOT be
fragmented. FUs MUST NOT be nested; i.e. an FU MUST NOT contain fragmented. FUs MUST NOT be nested; i.e. an FU must not contain
a subset of another FU. a subset of another FU.
The RTP timestamp of an RTP packet carrying an FU is set to the The RTP timestamp of an RTP packet carrying an FU is set to the
NALU-time of the fragmented NAL unit. NALU-time of the fragmented NAL unit.
An FU consists of a payload header (denoted as PayloadHdr), an FU An FU consists of a payload header (denoted as PayloadHdr), an FU
header of one octet, a conditional 16-bit DONL field (in network header of one octet, a conditional 16-bit DONL field (in network
byte order), and an FU payload, as shown in Figure 9. byte order), and an FU payload, as shown in Figure 9.
0 1 2 3 0 1 2 3
skipping to change at page 37, line 37 skipping to change at page 37, line 37
If sprop-max-don-diff is greater than 0 for any of the RTP If sprop-max-don-diff is greater than 0 for any of the RTP
streams, and the S bit is equal to 1, the DONL field MUST be streams, and the S bit is equal to 1, the DONL field MUST be
present in the FU, and the variable DON for the fragmented NAL present in the FU, and the variable DON for the fragmented NAL
unit is derived as equal to the value of the DONL field. unit is derived as equal to the value of the DONL field.
Otherwise (sprop-max-don-diff is equal to 0 for all the RTP Otherwise (sprop-max-don-diff is equal to 0 for all the RTP
streams, or the S bit is equal to 0), the DONL field MUST NOT be streams, or the S bit is equal to 0), the DONL field MUST NOT be
present in the FU. present in the FU.
A non-fragmented NAL unit MUST NOT be transmitted in one FU; i.e. A non-fragmented NAL unit MUST NOT be transmitted in one FU; i.e.
the Start bit and End bit MUST NOT both be set to one in the same the Start bit and End bit must not both be set to one in the same
FU header. FU header.
The FU payload consists of fragments of the payload of the The FU payload consists of fragments of the payload of the
fragmented NAL unit so that if the FU payloads of consecutive fragmented NAL unit so that if the FU payloads of consecutive
FUs, starting with an FU with the S bit equal to 1 and ending FUs, starting with an FU with the S bit equal to 1 and ending
with an FU with the E bit equal to 1, are sequentially with an FU with the E bit equal to 1, are sequentially
concatenated, the payload of the fragmented NAL unit can be concatenated, the payload of the fragmented NAL unit can be
reconstructed. The NAL unit header of the fragmented NAL unit is reconstructed. The NAL unit header of the fragmented NAL unit is
not included as such in the FU payload, but rather the not included as such in the FU payload, but rather the
information of the NAL unit header of the fragmented NAL unit is information of the NAL unit header of the fragmented NAL unit is
skipping to change at page 39, line 10 skipping to change at page 39, line 10
mechanism in future specifications. mechanism in future specifications.
A PACI packet consists of a payload header (denoted as A PACI packet consists of a payload header (denoted as
PayloadHdr), for which the structure follows what is described in PayloadHdr), for which the structure follows what is described in
Section 4.2 above. The payload header is followed by the fields Section 4.2 above. The payload header is followed by the fields
A, cType, PHSsize, F[0..2] and Y. A, cType, PHSsize, F[0..2] and Y.
Figure 11 shows a PACI packet in compliance with this memo; that Figure 11 shows a PACI packet in compliance with this memo; that
is, without any extensions. is, without any extensions.
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 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
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y| | Payload Header Extension Structure (PHES) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| Payload Header Extension Structure (PHES) |
|=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=| |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=|
| | | |
| PACI payload: NAL unit | | PACI payload: NAL unit |
| . . . | | . . . |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+ | :...OPTIONAL RTP padding |
| :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-
Figure 11 The structure of a PACI Figure 11 The structure of a PACI
The fields in the payload header are set as follows. The F bit The fields in the payload header are set as follows. The F bit
MUST be equal to 0. The Type field MUST be equal to 50. The MUST be equal to 0. The Type field MUST be equal to 50. The
value of LayerId MUST be a copy of the LayerId field of the PACI value of LayerId MUST be a copy of the LayerId field of the PACI
payload NAL unit or NAL-unit-like structure. The value of TID payload NAL unit or NAL-unit-like structure. The value of TID
MUST be a copy of the TID field of the PACI payload NAL unit or MUST be a copy of the TID field of the PACI payload NAL unit or
NAL-unit-like structure. NAL-unit-like structure.
skipping to change at page 40, line 26 skipping to change at page 40, line 16
Indicates the length of the PHES field. The value is limited Indicates the length of the PHES field. The value is limited
to be less than or equal to 32 octets, to simplify encoder to be less than or equal to 32 octets, to simplify encoder
design for MTU size matching. design for MTU size matching.
F0 F0
This field equal to 1 specifies the presence of a temporal This field equal to 1 specifies the presence of a temporal
scalability support extension in the PHES. scalability support extension in the PHES.
F1, F2 F1, F2
MUST be 0, available for future extensions, see Section MUST be 0, available for future extensions, see Section
4.4.4.2. 4.4.4.2. Receivers compliant with this version of the HEVC
payload format MUST ignore F1=1 and/or F2=1, and also ignore
any information in the PHES indicated as present by F1=1
and/or F2=1.
Informative note: The receiver can do that by first
decoding information associated with F0=1, and then
skipping over any remaining bytes of the PHES based on the
value of PHSsize.
Y: 1 bit Y: 1 bit
MUST be 0, available for future extensions, see Section MUST be 0, available for future extensions, see Section
4.4.4.2. 4.4.4.2. Receivers compliant with this version of the HEVC
payload format MUST ignore Y=1, and also ignore any
information in the PHES indicated as present by Y.
PHES: variable number of octets PHES: variable number of octets
A variable number of octets as indicated by the value of A variable number of octets as indicated by the value of
PHSsize. PHSsize.
PACI Payload PACI Payload
The single NAL unit packet or NAL-unit-like structure (such The single NAL unit packet or NAL-unit-like structure (such
as: FU or AP) to be carried, not including the first two as: FU or AP) to be carried, not including the first two
octets. octets.
skipping to change at page 42, line 23 skipping to change at page 42, line 23
4.4.4.2 PACI extensions (Informative) 4.4.4.2 PACI extensions (Informative)
This section includes recommendations for future specification This section includes recommendations for future specification
designers on how to extent the PACI syntax to accommodate future designers on how to extent the PACI syntax to accommodate future
extensions. Obviously, designers are free to specify whatever extensions. Obviously, designers are free to specify whatever
appears to be appropriate to them at the time of their design. appears to be appropriate to them at the time of their design.
However, a lot of thought has been invested into the extension However, a lot of thought has been invested into the extension
mechanism described below, and we suggest that deviations from it mechanism described below, and we suggest that deviations from it
warrant a good explanation. warrant a good explanation.
This memo defines only a single payload header extension (Temporal This memo defines only a single payload header extension
Scalability Control Information, described below in Section 4.5), (Temporal Scalability Control Information, described below in
and, therefore, only the F0 bit carries semantics. F1 and F2 are Section 4.5), and, therefore, only the F0 bit carries semantics.
already named (and not just marked as reserved, as a typical video F1 and F2 are already named (and not just marked as reserved, as
spec designer would do). They are intended to signal two additional a typical video spec designer would do). They are intended to
extensions. The Y bit allows to, recursively, add further F and Y signal two additional extensions. The Y bit allows to,
bits to extend the mechanism beyond 3 possible payload header recursively, add further F and Y bits to extend the mechanism
extensions. It is suggested to define a new packet type (using a beyond 3 possible payload header extensions. It is suggested to
different value for Type) when assigning the F1, F2, or Y bits define a new packet type (using a different value for Type) when
different semantics than what is suggested below. assigning the F1, F2, or Y bits different semantics than what is
suggested below.
When a Y bit is set, an 8 bit flag-extension is inserted after When a Y bit is set, an 8 bit flag-extension is inserted after
the Y bit. A flag-extension consists of 7 flags F[n..n+6], and the Y bit. A flag-extension consists of 7 flags F[n..n+6], and
another Y bit. another Y bit.
The basic PACI header already includes F0, F1, and F2. The basic PACI header already includes F0, F1, and F2.
Therefore, the Fx bits in the first flag-extensions are numbered Therefore, the Fx bits in the first flag-extensions are numbered
F3, F4, ..., F9, the F bits in the second flag-extension are F3, F4, ..., F9, the F bits in the second flag-extension are
numbered F10, F11, ..., F16, and so forth. As a result, at least numbered F10, F11, ..., F16, and so forth. As a result, at least
3 Fx bits are always in the PACI, but the number of Fx bits (and 3 Fx bits are always in the PACI, but the number of Fx bits (and
skipping to change at page 44, line 5 skipping to change at page 44, line 5
defined in this specification, known as Temporal Scalability defined in this specification, known as Temporal Scalability
Control Information (TSCI). If, in the future, additional Control Information (TSCI). If, in the future, additional
payload header extensions become necessary, they could be payload header extensions become necessary, they could be
specified in this section of an updated version of this document, specified in this section of an updated version of this document,
or in their own documents. or in their own documents.
When F0 is set to 1 in a PACI, this specifies that the PHES field When F0 is set to 1 in a PACI, this specifies that the PHES field
includes the TSCI fields TL0PICIDX, IrapPicID, S, and E as includes the TSCI fields TL0PICIDX, IrapPicID, S, and E as
follows: follows:
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 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
1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y|
+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=50) |A| cType | PHSsize |F0..2|Y| | TL0PICIDX | IrapPicID |S|E| RES | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-+ | .... |
| TL0PICIDX | IrapPicID |S|E| RES | | | PACI payload: NAL unit |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |
| .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACI payload: NAL unit | | :...OPTIONAL RTP padding |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+
Figure 12 The structure of a PACI with a PHES containing a TSCI Figure 12 The structure of a PACI with a PHES containing a TSCI
TL0PICIDX (8 bits) TL0PICIDX (8 bits)
When present, the TL0PICIDX field MUST be set to equal to When present, the TL0PICIDX field MUST be set to equal to
temporal_sub_layer_zero_idx as specified in Section D.3.22 of temporal_sub_layer_zero_idx as specified in Section D.3.22 of
[H.265] for the access unit containing the NAL unit in the [H.265] for the access unit containing the NAL unit in the
PACI. PACI.
IrapPicID (8 bits) IrapPicID (8 bits)
skipping to change at page 47, line 32 skipping to change at page 47, line 24
transmitted, and gaps in values of AbsDon may occur. Another transmitted, and gaps in values of AbsDon may occur. Another
example is MRST or MRMT with sprop-max-don-diff greater than example is MRST or MRMT with sprop-max-don-diff greater than
0, where the AbsDon values must indicate cross-layer decoding 0, where the AbsDon values must indicate cross-layer decoding
order for NAL units conveyed in all the RTP streams. order for NAL units conveyed in all the RTP streams.
5 Packetization Rules 5 Packetization Rules
The following packetization rules apply: The following packetization rules apply:
o If sprop-max-don-diff is greater than 0 for any of the RTP o If sprop-max-don-diff is greater than 0 for any of the RTP
streams, the transmission order of NAL units carried in the RTP streams, the transmission order of NAL units carried in the
stream MAY be different than the NAL unit decoding order and the RTP stream MAY be different than the NAL unit decoding order
NAL unit output order. Otherwise (sprop-max-don-diff is equal and the NAL unit output order. Otherwise (sprop-max-don-diff
to 0 for all the RTP streams), the transmission order of NAL is equal to 0 for all the RTP streams), the transmission order
units carried in the RTP stream MUST be the same as the NAL unit of NAL units carried in the RTP stream MUST be the same as the
decoding order, and, when tx-mode is equal to "MRST" or "MRMT", NAL unit decoding order, and, when tx-mode is equal to "MRST"
MUST also be the same as the NAL unit output order. or "MRMT", MUST also be the same as the NAL unit output order.
o A NAL unit of a small size SHOULD be encapsulated in an o A NAL unit of a small size SHOULD be encapsulated in an
aggregation packet together with one or more other NAL units aggregation packet together with one or more other NAL units
in order to avoid the unnecessary packetization overhead for in order to avoid the unnecessary packetization overhead for
small NAL units. For example, non-VCL NAL units such as small NAL units. For example, non-VCL NAL units such as
access unit delimiters, parameter sets, or SEI NAL units are access unit delimiters, parameter sets, or SEI NAL units are
typically small and can often be aggregated with VCL NAL units typically small and can often be aggregated with VCL NAL units
without violating MTU size constraints. without violating MTU size constraints.
o Each non-VCL NAL unit SHOULD, when possible from an MTU size o Each non-VCL NAL unit SHOULD, when possible from an MTU size
skipping to change at page 59, line 26 skipping to change at page 59, line 11
This parameter indicates whether the transmission mode is This parameter indicates whether the transmission mode is
SRST, MRST, or MRMT. SRST, MRST, or MRMT.
The value of tx-mode MUST be equal to "SRST", "MRST" or The value of tx-mode MUST be equal to "SRST", "MRST" or
"MRMT". When not present, the value of tx-mode is inferred "MRMT". When not present, the value of tx-mode is inferred
to be equal to "SRST". to be equal to "SRST".
If the value is equal to "MRST", MRST MUST be in use. If the value is equal to "MRST", MRST MUST be in use.
Otherwise, if the value is equal to "MRMT", MRMT MUST be in Otherwise, if the value is equal to "MRMT", MRMT MUST be in
use. Otherwise (the value is equal to "SRST"), SRST MUST be use. Otherwise (the value is equal to "SRST"), SRST MUST
in use. be in use.
The value of tx-mode MUST be equal to "MRST" for all RTP The value of tx-mode MUST be equal to "MRST" for all RTP
streams in an MRST. streams in an MRST.
The value of tx-mode MUST be equal to "MRMT" for all RTP The value of tx-mode MUST be equal to "MRMT" for all RTP
streams in an MRMT. streams in an MRMT.
sprop-vps: sprop-vps:
This parameter MAY be used to convey any video parameter This parameter MAY be used to convey any video parameter
skipping to change at page 81, line 22 skipping to change at page 81, line 8
media format configuration. This differs from the normal media format configuration. This differs from the normal
usage of the Offer/Answer parameters: normally such parameters usage of the Offer/Answer parameters: normally such parameters
declare the properties of the bitstream or RTP stream that the declare the properties of the bitstream or RTP stream that the
offerer or the answerer is able to receive. When dealing with offerer or the answerer is able to receive. When dealing with
HEVC, the offerer assumes that the answerer will be able to HEVC, the offerer assumes that the answerer will be able to
receive media encoded using the configuration being offered. receive media encoded using the configuration being offered.
Informative note: The above parameters apply for any RTP Informative note: The above parameters apply for any RTP
stream and all RTP streams the RTP stream depends on, when stream and all RTP streams the RTP stream depends on, when
present, sent by a declaring entity with the same present, sent by a declaring entity with the same
configuration; i.e. they are dependent on their source configuration. In other words, the applicability of the
above parameters to RTP streams depends on the source
endpoint. Rather than being bound to the payload type, endpoint. Rather than being bound to the payload type,
the values may have to be applied to another payload type the values may have to be applied to another payload type
when being sent, as they apply for the configuration. when being sent, as they apply for the configuration.
o The capability parameters max-lsr, max-lps, max-cpb, max-dpb, o The capability parameters max-lsr, max-lps, max-cpb, max-dpb,
max-br, max-tr, and max-tc MAY be used to declare further max-br, max-tr, and max-tc MAY be used to declare further
capabilities of the offerer or answerer for receiving. These capabilities of the offerer or answerer for receiving. These
parameters MUST NOT be present when the direction attribute is parameters MUST NOT be present when the direction attribute is
"sendonly". "sendonly".
skipping to change at page 85, line 44 skipping to change at page 85, line 31
| | | | | | | | | |
profile-space C D C D P profile-space C D C D P
profile-id C D C D P profile-id C D C D P
tier-flag C D C D P tier-flag C D C D P
level-id D D D D P level-id D D D D P
interop-constraints C D C D P interop-constraints C D C D P
profile-compatibility-indicator C D C D P profile-compatibility-indicator C D C D P
tx-mode C C C C P tx-mode C C C C P
max-recv-level-id R R R R - max-recv-level-id R R R R -
sprop-max-don-diff P P - - P sprop-max-don-diff P P - - P
sprop- depack-buf-nalus P P - - P sprop-depack-buf-nalus P P - - P
sprop-depack-buf-bytes P P - - P sprop-depack-buf-bytes P P - - P
depack-buf-cap R R R R - depack-buf-cap R R R R -
sprop-segmentation-id P P P P P sprop-segmentation-id P P P P P
sprop-spatial-segmentation-idc P P P P P sprop-spatial-segmentation-idc P P P P P
max-br R R R R - max-br R R R R -
max-cpb R R R R - max-cpb R R R R -
max-dpb R R R R - max-dpb R R R R -
max-lsr R R R R - max-lsr R R R R -
max-lps R R R R - max-lps R R R R -
max-tr R R R R - max-tr R R R R -
skipping to change at page 86, line 34 skipping to change at page 86, line 21
C: configuration for sending and receiving bitstreams C: configuration for sending and receiving bitstreams
D: changable configuration, same as C except possible D: changable configuration, same as C except possible
to answer with a different but consistent value (see the to answer with a different but consistent value (see the
semantics of the six parameters related to profile, tier, semantics of the six parameters related to profile, tier,
and level on these parameters being consistent) and level on these parameters being consistent)
P: properties of the bitstream to be sent P: properties of the bitstream to be sent
R: receiver capabilities R: receiver capabilities
O: operation point selection O: operation point selection
X: MUST NOT be present X: MUST NOT be present
-: not usable, when present SHOULD be ignored -: not usable, when present MUST be ignored
Parameters used for declaring receiver capabilities are in Parameters used for declaring receiver capabilities are in
general downgradable; i.e. they express the upper limit for a general downgradable; i.e. they express the upper limit for a
sender's possible behavior. Thus, a sender MAY select to set its sender's possible behavior. Thus, a sender MAY select to set its
encoder using only lower/lesser or equal values of these encoder using only lower/lesser or equal values of these
parameters. parameters.
When the answer does not include recv-sub-layer-id that is less When the answer does not include recv-sub-layer-id that is less
than the sprop-sub-layer-id in the offer, parameters declaring a than the sprop-sub-layer-id in the offer, parameters declaring a
configuration point are not changeable, with the exception of the configuration point are not changeable, with the exception of the
skipping to change at page 88, line 27 skipping to change at page 88, line 11
- tx-mode - tx-mode
- sprop-vps - sprop-vps
- sprop-sps - sprop-sps
- sprop-pps - sprop-pps
- sprop-max-don-diff - sprop-max-don-diff
- sprop-depack-buf-nalus - sprop-depack-buf-nalus
- sprop-depack-buf-bytes - sprop-depack-buf-bytes
- sprop-segmentation-id - sprop-segmentation-id
- sprop-spatial-segmentation-idc - sprop-spatial-segmentation-idc
o Not usable (when present, they SHOULD be ignored): o Not usable (when present, they MUST be ignored):
- max-lps - max-lps
- max-lsr - max-lsr
- max-cpb - max-cpb
- max-dpb - max-dpb
- max-br - max-br
- max-tr - max-tr
- max-tc - max-tc
- max-fps - max-fps
- max-recv-level-id - max-recv-level-id
- depack-buf-cap - depack-buf-cap
skipping to change at page 89, line 19 skipping to change at page 89, line 5
When out-of-band transport of parameter sets is used, parameter When out-of-band transport of parameter sets is used, parameter
sets MAY still be additionally transported in-band unless sets MAY still be additionally transported in-band unless
explicitly disallowed by an application, and some of these explicitly disallowed by an application, and some of these
additionally in-band transported parameter sets may update some additionally in-band transported parameter sets may update some
of the out-of-band transported parameter sets. Update of a of the out-of-band transported parameter sets. Update of a
parameter set refers to sending of a parameter set of the same parameter set refers to sending of a parameter set of the same
type using the same parameter set ID but with different values type using the same parameter set ID but with different values
for at least one other parameter of the parameter set. for at least one other parameter of the parameter set.
If MRST or MRMT is used, the rules on signaling media decoding 7.2.5Dependency Signaling in Multi-Stream Mode
dependency in SDP as defined in [RFC5583] apply. The rules on
"hierarchical or layered encoding" with multicast in Section 5.7
of [RFC4566] do not apply, i.e. the notation for Connection Data
"c=" SHALL NOT be used with more than one address. The order of
session dependency is given from the RTP stream containing the
lowest temporal sub-layer to the RTP stream containing the
highest temporal sub-layer.
7.2.5 Dependency Signaling in Multi-Stream Mode
If MRST or MRMT is used, the rules on signaling media decoding If MRST or MRMT is used, the rules on signaling media decoding
dependency in SDP as defined in [RFC5583] apply. The rules on dependency in SDP as defined in [RFC5583] apply. The rules on
"hierarchical or layered encoding" with multicast in Section 5.7 "hierarchical or layered encoding" with multicast in Section 5.7
of [RFC4566] do not apply, i.e. the notation for Connection Data of [RFC4566] do not apply. This means that the notation for
"c=" SHALL NOT be used with more than one address. The order of Connection Data "c=" SHALL NOT be used with more than one
session dependency is given from the RTP stream containing the address, i.e. the sub-field <number of addresses> in the sub-
lowest temporal sub-layer to the RTP stream containing the field <connection-address> of the "c=" field, described in
highest temporal sub-layer. [RFC4566], must not be present. The order of session dependency
is given from the RTP stream containing the lowest temporal sub-
layer to the RTP stream containing the highest temporal sub-
layer.
8 Use with Feedback Messages 8 Use with Feedback Messages
The following subsections define the use of the Picture Loss The following subsections define the use of the Picture Loss
Indication (PLI), Slice Lost Indication (SLI), Reference Picture Indication (PLI), Slice Lost Indication (SLI), Reference Picture
Selection Indication (RPSI), and Full Intra Request (FIR) Selection Indication (RPSI), and Full Intra Request (FIR)
feedback messages with HEVC. The PLI, SLI, and RPSI messages are feedback messages with HEVC. The PLI, SLI, and RPSI messages are
defined in RFC 4585 [RFC4585], and the FIR message is defined in defined in RFC 4585 [RFC4585], and the FIR message is defined in
RFC 5104 [RFC5104]. RFC 5104 [RFC5104].
skipping to change at page 91, line 16 skipping to change at page 90, line 36
wide than the picture. wide than the picture.
The subfield "PictureID" MUST be set to the 6 least significant The subfield "PictureID" MUST be set to the 6 least significant
bits of a binary representation of the value of PicOrderCntVal, bits of a binary representation of the value of PicOrderCntVal,
as defined in [HEVC], of the picture for which the lost CTBs are as defined in [HEVC], of the picture for which the lost CTBs are
indicated. Note that for IDR pictures the syntax element indicated. Note that for IDR pictures the syntax element
slice_pic_order_cnt_lsb is not present, but then the value is slice_pic_order_cnt_lsb is not present, but then the value is
inferred to be equal to 0. inferred to be equal to 0.
As described in RFC 4585, an encoder in a media sender can use As described in RFC 4585, an encoder in a media sender can use
this information to "clean up" the corrupted picture by sending these information to "clean up" the corrupted picture by sending
intra information, while observing the constraints described in intra information, while observing the constraints described in
RFC 4585, for example with respect to congestion control. In RFC 4585, for example with respect to congestion control. In
many cases, error tracking is required to identify the corrupted many cases, error tracking is required to identify the corrupted
region in the receiver's state (reference pictures) because of region in the receiver's state (reference pictures) because of
error import in uncorrupted regions of the picture through motion error import in uncorrupted regions of the picture through motion
compensation. Reference picture selection can also be used to compensation. Reference picture selection can also be used to
"clean up" the corrupted picture, which is usually more efficient "clean up" the corrupted picture, which is usually more efficient
and less likely to generate congestion than sending intra and less likely to generate congestion than sending intra
information. information.
skipping to change at page 93, line 12 skipping to change at page 92, line 34
between sender and receiver, established by means outside this between sender and receiver, established by means outside this
document, that parameter sets are exclusively sent out of band. document, that parameter sets are exclusively sent out of band.
9 Security Considerations 9 Security Considerations
RTP packets using the payload format defined in this RTP packets using the payload format defined in this
specification are subject to the security considerations specification are subject to the security considerations
discussed in the RTP specification [RFC3550], and in any discussed in the RTP specification [RFC3550], and in any
applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF
[RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. However, [RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. However,
as RFC 7202 [RFC7202] discusses it is not an RTP payload format's as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate
responsibility to discuss or mandate what solutions are used to a Single Media Security Solution" RFC 7202 [RFC7202] discusses,
meet the basic security goals like confidentiality, integrity, it is not an RTP payload format's responsibility to discuss or
and source authenticity for RTP in general. This responsibility mandate what solutions are used to meet the basic security goals
lays on anyone using RTP in an application. They can find like confidentiality, integrity and source authenticity for RTP
guidance on available security mechanisms and important in general. This responsibility lays on anyone using RTP in an
considerations as discussed in RFC 7201 [RFC7201]. application. They can find guidance on available security
mechanisms and important considerations in Options for Securing
The rest of this section discusses the security impacting RTP Sessions [RFC7201]. Applications SHOULD use one or more
appropriate strong security mechanisms. The rest of this
security consideration section discusses the security impacting
properties of the payload format itself. properties of the payload format itself.
Because the data compression used with this payload format is Because the data compression used with this payload format is
applied end-to-end, any encryption needs to be performed after applied end-to-end, any encryption needs to be performed after
compression. A potential denial-of-service threat exists for compression. A potential denial-of-service threat exists for
data encodings using compression techniques that have non-uniform data encodings using compression techniques that have non-uniform
receiver-end computational load. The attacker can inject receiver-end computational load. The attacker can inject
pathological datagrams into the bitstream that are complex to pathological datagrams into the bitstream that are complex to
decode and that cause the receiver to be overloaded. H.265 is decode and that cause the receiver to be overloaded. H.265 is
particularly vulnerable to such attacks, as it is extremely particularly vulnerable to such attacks, as it is extremely
simple to generate datagrams containing NAL units that affect the simple to generate datagrams containing NAL units that affect the
decoding process of many future NAL units. Therefore, the usage decoding process of many future NAL units. Therefore, the usage
of data origin authentication and data integrity protection of at of data origin authentication and data integrity protection of at
least the RTP packet is RECOMMENDED, for example, with SRTP least the RTP packet is RECOMMENDED, for example, with SRTP
[RFC3711]. [RFC3711].
Note that the appropriate mechanism to ensure confidentiality and
integrity of RTP packets and their payloads is very dependent on
the application and on the transport and signaling protocols
employed. Thus, although SRTP is given as an example above,
other possible choices exist.
Decoders MUST exercise caution with respect to the handling of Decoders MUST exercise caution with respect to the handling of
user data SEI messages, particularly if they contain active user data SEI messages, particularly if they contain active
elements, and MUST restrict their domain of applicability to the elements, and MUST restrict their domain of applicability to the
presentation containing the bitstream. presentation containing the bitstream.
End-to-end security with authentication, integrity, or End-to-end security with authentication, integrity, or
confidentiality protection will prevent a MANE from performing confidentiality protection will prevent a MANE from performing
media-aware operations other than discarding complete packets. media-aware operations other than discarding complete packets.
In the case of confidentiality protection, it will even be In the case of confidentiality protection, it will even be
prevented from discarding packets in a media-aware way. To be prevented from discarding packets in a media-aware way. To be
skipping to change at page 98, line 5 skipping to change at page 97, line 20
[3GPDASH] 3GPP TS 26.247, "Transparent end-to-end Packet-switched [3GPDASH] 3GPP TS 26.247, "Transparent end-to-end Packet-switched
Streaming Service (PSS); Progressive Download and Streaming Service (PSS); Progressive Download and
Dynamic Adaptive Streaming over HTTP (3GP-DASH)", Dynamic Adaptive Streaming over HTTP (3GP-DASH)",
v12.1.0, December 2013. v12.1.0, December 2013.
[3GPPFF] 3GPP TS 26.244, "Transparent end-to-end packet switched [3GPPFF] 3GPP TS 26.244, "Transparent end-to-end packet switched
streaming service (PSS); 3GPP file format (3GP)", streaming service (PSS); 3GPP file format (3GP)",
v12.20, December 2013. v12.20, December 2013.
[CABAC] Sole, J., Joshi, R., Nguyen, N., Ji, T., Karczewicz,
M., Clare, G., Henry, F., and Duenas, A., "Transform
coefficient coding in HEVC", IEEE Transactions on
Circuts and Systems for Video Technology, Vol. 22, No.
12, pp. 1765-1777, December 2012.
[Girod99] Girod, B. and Faerber, F., "Feedback-based error [Girod99] Girod, B. and Faerber, F., "Feedback-based error
control for mobile video transmission", Proceedings control for mobile video transmission", Proceedings
IEEE, Vol. 87, No. 10, pp. 1707-1723, October 1999. IEEE, Vol. 87, No. 10, pp. 1707-1723, October 1999.
[HEVC draft v2] [HEVC draft v2]
Draft version 2 of HEVC, "High Efficiency Video Coding Draft version 2 of HEVC, "High Efficiency Video Coding
(HEVC) Range Extensions text specification: Draft 7", (HEVC) Range Extensions text specification: Draft 7",
JCT-VC document JCTVC-Q1005, 17th JCT-VC meeting, 27 JCT-VC document JCTVC-Q1005, 17th JCT-VC meeting, 27
March - 4 April 2014, Valencia, Spain. March - 4 April 2014, Valencia, Spain.
skipping to change at page 99, line 19 skipping to change at page 98, line 43
[MPEGDASH] ISO/IEC 23009-1, "Information technology - Dynamic [MPEGDASH] ISO/IEC 23009-1, "Information technology - Dynamic
adaptive streaming over HTTP (DASH) - Part 1: Media adaptive streaming over HTTP (DASH) - Part 1: Media
presentation description and segment formats", 2012. presentation description and segment formats", 2012.
[RFC2326] Schulzrinne, H., Rao, A., and Lanphier R., "Real Time [RFC2326] Schulzrinne, H., Rao, A., and Lanphier R., "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins C., and Whelan E., "Session [RFC2974] Handley, M., Perkins C., and Whelan E., "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E.,
and Fairhurst, G., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, July 2004.
[RFC5117] Westerlund, M. and Wenger, S., "RTP Topologies", RFC [RFC5117] Westerlund, M. and Wenger, S., "RTP Topologies", RFC
5117, January 2008. 5117, January 2008.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of
RTP Flows", RFC 6051, November 2010. RTP Flows", RFC 6051, November 2010.
[RFC7201] Westerlund, M. and Perkins, C., "Options for Securing [RFC7201] Westerlund, M. and Perkins, C., "Options for Securing
RTP Sessions", RFC 7201, April 2014. RTP Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and Westerlund, M., "Securing the RTP [RFC7202] Perkins, C. and Westerlund, M., "Securing the RTP
 End of changes. 38 change blocks. 
205 lines changed or deleted 216 lines changed or added

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