draft-ietf-payload-rtp-h265-07.txt   draft-ietf-payload-rtp-h265-08.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: June 2015 T. Schierl Expires: October 2015 T. Schierl
Fraunhofer HHI Fraunhofer HHI
S. Wenger S. Wenger
Vidyo Vidyo
M. M. Hannuksela M. M. Hannuksela
Nokia Nokia
December 8, 2014 April 10, 2015
RTP Payload Format for High Efficiency Video Coding RTP Payload Format for High Efficiency Video Coding
draft-ietf-payload-rtp-h265-07.txt draft-ietf-payload-rtp-h265-08.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 19 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 June 8, 2015. This Internet-Draft will expire on October 10, 2015.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2014 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
skipping to change at page 3, line 23 skipping to change at page 3, line 23
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...................................................18
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 Payload Structures.......................................27 4.3 Payload Structures.......................................27
4.4 Transmission Modes.......................................28 4.4 Transmission Modes.......................................28
4.5 Decoding Order Number....................................29 4.5 Decoding Order Number....................................29
4.6 Single NAL Unit Packets..................................31 4.6 Single NAL Unit Packets..................................31
4.7 Aggregation Packets (APs)................................32 4.7 Aggregation Packets (APs)................................32
4.8 Fragmentation Units (FUs)................................37 4.8 Fragmentation Units (FUs)................................37
4.9 PACI packets.............................................40 4.9 PACI packets.............................................40
4.9.1 Reasons for the PACI rules (informative)............43 4.9.1 Reasons for the PACI rules (informative)............43
4.9.2 PACI extensions (Informative).......................44 4.9.2 PACI extensions (Informative).......................44
4.10 Temporal Scalability Control Information................45 4.10 Temporal Scalability Control Information................45
5 Packetization Rules...........................................47 5 Packetization Rules...........................................47
6 De-packetization Process......................................48 6 De-packetization Process......................................48
7 Payload Format Parameters.....................................50 7 Payload Format Parameters.....................................51
7.1 Media Type Registration..................................51 7.1 Media Type Registration..................................51
7.2 SDP Parameters...........................................76 7.2 SDP Parameters...........................................77
7.2.1 Mapping of Payload Type Parameters to SDP...........76 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.......................88 7.2.4 Parameter Sets Considerations.......................89
7.2.5 Dependency Signaling in Multi-Stream Mode...........88 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)............................90
8.2 Slice Loss Indication (SLI)..............................90 8.2 Slice Loss Indication (SLI)..............................91
8.3 Reference Picture Selection Indication (RPSI)............91 8.3 Reference Picture Selection Indication (RPSI)............92
8.4 Full Intra Request (FIR).................................92 8.4 Full Intra Request (FIR).................................93
9 Security Considerations.......................................93 9 Security Considerations.......................................93
10 Congestion Control...........................................94 10 Congestion Control...........................................94
11 IANA Consideration...........................................95 11 IANA Consideration...........................................96
12 Acknowledgements.............................................95 12 Acknowledgements.............................................96
13 References...................................................96 13 References...................................................96
13.1 Normative References....................................96 13.1 Normative References....................................96
13.2 Informative References..................................97 13.2 Informative References..................................98
14 Authors' Addresses...........................................99 14 Authors' Addresses..........................................100
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 22, line 27 skipping to change at page 22, line 27
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].
NAL unit output order: A NAL unit order in which NAL units of
different access units are in the output order of the decoded
pictures corresponding to the access units, as specified in
[HEVC], and in which NAL units within an access unit are in their
decoding order.
NAL-unit-like structure: A data structure that is similar to NAL NAL-unit-like structure: A data structure that is similar to NAL
units in the sense that it also has a NAL unit header and a units in the sense that it also has a NAL unit header and a
payload, with a difference that the payload does not follow the payload, with a difference that the payload does not follow the
start code emulation prevention mechanism required for the NAL start code emulation prevention mechanism required for the NAL
unit syntax as specified in Section 7.3.1.1 of [HEVC]. Examples unit syntax as specified in Section 7.3.1.1 of [HEVC]. Examples
NAL-unit-like structures defined in this memo are packet payloads NAL-unit-like structures defined in this memo are packet payloads
of AP, PACI, and FU packets. of AP, PACI, and FU packets.
NALU-time: The value that the RTP timestamp would have if the NAL NALU-time: The value that the RTP timestamp would have if the NAL
unit would be transported in its own RTP packet. unit would be transported in its own RTP packet.
skipping to change at page 29, line 23 skipping to change at page 29, line 31
the first "SHOULD" instead of "MUST"), and there might be the first "SHOULD" instead of "MUST"), and there might be
scenarios where MRMT is desirable but not possible e.g. when scenarios where MRMT is desirable but not possible e.g. when
IP multicast is not deployed in certain network (this is a IP multicast is not deployed in certain network (this is a
justification of the second "SHOULD" instead of "MUST"). justification of the second "SHOULD" instead of "MUST").
The transmission mode is indicated by the tx-mode media parameter The transmission mode is indicated by the tx-mode media parameter
(see section 7.1). If tx-mode is equal to "SRST", SRST MUST be (see section 7.1). If tx-mode is equal to "SRST", SRST MUST be
used. Otherwise, if tx-mode is equal to "MRST", MRST MUST be used. Otherwise, if tx-mode is equal to "MRST", MRST MUST be
used. Otherwise (tx-mode is equal to "MRMT"), MRMT MUST be used. used. Otherwise (tx-mode is equal to "MRMT"), MRMT MUST be used.
Informative note: When an RTP stream does not depend on other
RTP streams, any of SRST, MRST and MRMT may be in use for the
RTP stream.
Receivers MUST support all of SRST, MRST, and MRMT. Receivers MUST support all of SRST, MRST, and MRMT.
Informative note: The required support of MRMT by receivers Informative note: The required support of MRMT by receivers
does not imply that multicast must be supported by receivers. does not imply that multicast must be supported by receivers.
4.5 Decoding Order Number 4.5 Decoding Order Number
For each NAL unit, the variable AbsDon is derived, representing For each NAL unit, the variable AbsDon is derived, representing
the decoding order number that is indicative of the NAL unit the decoding order number that is indicative of the NAL unit
decoding order. decoding order.
Let NAL unit n be the n-th NAL unit in transmission order within Let NAL unit n be the n-th NAL unit in transmission order within
an RTP stream. an RTP stream.
If tx-mode is equal to "SRST" and sprop-max-don-diff is equal If sprop-max-don-diff is equal to 0 for all the RTP streams
to 0, AbsDon[n], the value of AbsDon for NAL unit n, is derived carrying the HEVC bitstream, AbsDon[n], the value of AbsDon for
as equal to n. NAL unit n, is derived as equal to n.
Otherwise (tx-mode is equal to "MRST" or "MRMT" or sprop-max-don- Otherwise (sprop-max-don-diff is greater than 0 for any of the
diff is greater than 0), AbsDon[n] is derived as follows, where RTP streams), AbsDon[n] is derived as follows, where DON[n] is
DON[n] is the value of the variable DON for NAL unit n: the value of the variable DON for NAL unit n:
o If n is equal to 0 (i.e. NAL unit n is the very first NAL unit o If n is equal to 0 (i.e. NAL unit n is the very first NAL unit
in transmission order), AbsDon[0] is set equal to DON[0]. in transmission order), AbsDon[0] is set equal to DON[0].
o Otherwise (n is greater than 0), the following applies for o Otherwise (n is greater than 0), the following applies for
derivation of AbsDon[n]: derivation of AbsDon[n]:
If DON[n] == DON[n-1], If DON[n] == DON[n-1],
AbsDon[n] = AbsDon[n-1] AbsDon[n] = AbsDon[n-1]
skipping to change at page 31, line 19 skipping to change at page 31, line 32
congestion in the network. In another example, the first congestion in the network. In another example, the first
intra-coded picture of a pre-encoded clip is transmitted in intra-coded picture of a pre-encoded clip is transmitted in
advance to ensure that it is readily available in the advance to ensure that it is readily available in the
receiver, and when transmitting the first intra-coded picture, receiver, and when transmitting the first intra-coded picture,
the originator does not exactly know how many NAL units will the originator does not exactly know how many NAL units will
be encoded before the first intra-coded picture of the pre- be encoded before the first intra-coded picture of the pre-
encoded clip follows in decoding order. Thus, the values of encoded clip follows in decoding order. Thus, the values of
AbsDon for the NAL units of the first intra-coded picture of AbsDon for the NAL units of the first intra-coded picture of
the pre-encoded clip have to be estimated when they are the pre-encoded clip have to be estimated when they are
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 where the AbsDon values must indicate example is MRST or MRMT with sprop-max-don-diff greater than
cross-layer decoding order for NAL units conveyed in all the 0, where the AbsDon values must indicate cross-layer decoding
RTP streams. order for NAL units conveyed in all the RTP streams.
4.6 Single NAL Unit Packets 4.6 Single NAL Unit Packets
A single NAL unit packet contains exactly one NAL unit, and A single NAL unit packet contains exactly one NAL unit, and
consists of a payload header (denoted as PayloadHdr), a consists of a payload header (denoted as PayloadHdr), a
conditional 16-bit DONL field (in network byte order), and the conditional 16-bit DONL field (in network byte order), and the
NAL unit payload data (the NAL unit excluding its NAL unit NAL unit payload data (the NAL unit excluding its NAL unit
header) of the contained NAL unit, as shown in Figure 3. header) of the contained NAL unit, as shown in Figure 3.
0 1 2 3 0 1 2 3
skipping to change at page 32, line 12 skipping to change at page 32, line 26
Figure 3 The structure a single NAL unit packet Figure 3 The structure a single NAL unit packet
The payload header SHOULD be an exact copy of the NAL unit header The payload header SHOULD be an exact copy of the NAL unit header
of the contained NAL unit. However, the Type (i.e. of the contained NAL unit. However, the Type (i.e.
nal_unit_type) field MAY be changed, e.g. when it is desirable to nal_unit_type) field MAY be changed, e.g. when it is desirable to
handle a CRA picture to be a BLA picture [JCTVC-J0107]. handle a CRA picture to be a BLA picture [JCTVC-J0107].
The DONL field, when present, specifies the value of the 16 least The DONL field, when present, specifies the value of the 16 least
significant bits of the decoding order number of the contained significant bits of the decoding order number of the contained
NAL unit. If tx-mode is equal to "MRST" or "MRMT" or sprop-max- NAL unit. If sprop-max-don-diff is greater than 0 for any of the
don-diff is greater than 0, the DONL field MUST be present, and RTP streams, the DONL field MUST be present, and the variable DON
the variable DON for the contained NAL unit is derived as equal for the contained NAL unit is derived as equal to the value of
to the value of the DONL field. Otherwise (tx-mode is equal to the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for
"SRST" and sprop-max-don-diff is equal to 0), the DONL field MUST all the RTP streams), the DONL field MUST NOT be present.
NOT be present.
4.7 Aggregation Packets (APs) 4.7 Aggregation Packets (APs)
Aggregation packets (APs) are introduced to enable the reduction Aggregation packets (APs) are introduced to enable the reduction
of packetization overhead for small NAL units, such as most of of packetization overhead for small NAL units, such as most of
the non-VCL NAL units, which are often only a few octets in size. the non-VCL NAL units, which are often only a few octets in size.
An AP aggregates NAL units within one access unit. Each NAL unit An AP aggregates NAL units within one access unit. Each NAL unit
to be carried in an AP is encapsulated in an aggregation unit. to be carried in an AP is encapsulated in an aggregation unit.
NAL units aggregated in one AP are in NAL unit decoding order. NAL units aggregated in one AP are in NAL unit decoding order.
skipping to change at page 34, line 23 skipping to change at page 34, line 25
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 The structure of the first aggregation unit in an AP Figure 5 The structure of the first aggregation unit in an AP
The DONL field, when present, specifies the value of the 16 least The DONL field, when present, specifies the value of the 16 least
significant bits of the decoding order number of the aggregated significant bits of the decoding order number of the aggregated
NAL unit. NAL unit.
If tx-mode is equal to "MRST" or "MRMT" or sprop-max-don-diff is If sprop-max-don-diff is greater than 0 for any of the RTP
greater than 0, the DONL field MUST be present in an aggregation streams, the DONL field MUST be present in an aggregation unit
unit that is the first aggregation unit in an AP, and the that is the first aggregation unit in an AP, and the variable DON
variable DON for the aggregated NAL unit is derived as equal to for the aggregated NAL unit is derived as equal to the value of
the value of the DONL field. Otherwise (tx-mode is equal to the DONL field. Otherwise (sprop-max-don-diff is equal to 0 for
"SRST" and sprop-max-don-diff is equal to 0), the DONL field MUST all the RTP streams), the DONL field MUST NOT be present in an
NOT be present in an aggregation unit that is the first aggregation unit that is the first aggregation unit in an AP.
aggregation unit in an AP.
An aggregation unit that is not the first aggregation unit in an An aggregation unit that is not the first aggregation unit in an
AP consists of a conditional 8-bit DOND field followed by a 16- AP consists of a conditional 8-bit DOND field followed by a 16-
bit unsigned size information (in network byte order) that bit unsigned size information (in network byte order) that
indicates the size of the NAL unit in bytes (excluding these two indicates the size of the NAL unit in bytes (excluding these two
octets, but including the NAL unit header), followed by the NAL octets, but including the NAL unit header), followed by the NAL
unit itself, including its NAL unit header, as shown in Figure 6. unit itself, including its NAL unit header, as shown in Figure 6.
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 24 skipping to change at page 35, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 The structure of an aggregation unit that is not the Figure 6 The structure of an aggregation unit that is not the
first aggregation unit in an AP first aggregation unit in an AP
When present, the DOND field plus 1 specifies the difference When present, the DOND field plus 1 specifies the difference
between the decoding order number values of the current between the decoding order number values of the current
aggregated NAL unit and the preceding aggregated NAL unit in the aggregated NAL unit and the preceding aggregated NAL unit in the
same AP. same AP.
If tx-mode is equal to "MRST" or "MRMT" or sprop-max-don-diff is If sprop-max-don-diff is greater than 0 for any of the RTP
greater than 0, the DOND field MUST be present in an aggregation streams, the DOND field MUST be present in an aggregation unit
unit that is not the first aggregation unit in an AP, and the that is not the first aggregation unit in an AP, and the variable
variable DON for the aggregated NAL unit is derived as equal to DON for the aggregated NAL unit is derived as equal to the DON of
the DON of the preceding aggregated NAL unit in the same AP plus the preceding aggregated NAL unit in the same AP plus the value
the value of the DOND field plus 1 modulo 65536. Otherwise (tx- of the DOND field plus 1 modulo 65536. Otherwise (sprop-max-don-
mode is equal to "SRST" and sprop-max-don-diff is equal to 0), diff is equal to 0 for all the RTP streams), the DOND field MUST
the DOND field MUST NOT be present in an aggregation unit that is NOT be present in an aggregation unit that is not the first
not the first aggregation unit in an AP, and in this case the aggregation unit in an AP, and in this case the transmission
transmission order and decoding order of NAL units carried in the order and decoding order of NAL units carried in the AP are the
AP are the same as the order the NAL units appear in the AP. same as the order the NAL units appear in the AP.
Figure 7 presents an example of an AP that contains two Figure 7 presents an example of an AP that contains two
aggregation units, labeled as 1 and 2 in the figure, without the aggregation units, labeled as 1 and 2 in the figure, without the
DONL and DOND fields being present. DONL and DOND fields being present.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 39, line 28 skipping to change at page 39, line 28
set to zero. set to zero.
FuType: 6 bits FuType: 6 bits
The field FuType MUST be equal to the field Type of the The field FuType MUST be equal to the field Type of the
fragmented NAL unit. fragmented NAL unit.
The DONL field, when present, specifies the value of the 16 least The DONL field, when present, specifies the value of the 16 least
significant bits of the decoding order number of the fragmented significant bits of the decoding order number of the fragmented
NAL unit. NAL unit.
If tx-mode is equal to "MRST" or "MRMT" or sprop-max-don-diff is If sprop-max-don-diff is greater than 0 for any of the RTP
greater than 0, and the S bit is equal to 1, the DONL field MUST streams, and the S bit is equal to 1, the DONL field MUST be
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 (tx-mode is equal to "SRST" and sprop-max-don-diff is Otherwise (sprop-max-don-diff is equal to 0 for all the RTP
equal to 0, or the S bit is equal to 0), the DONL field MUST NOT streams, or the S bit is equal to 0), the DONL field MUST NOT be
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
skipping to change at page 47, line 36 skipping to change at page 47, line 36
The value of PHSsize MUST be set to 3. Receivers MUST allow The value of PHSsize MUST be set to 3. Receivers MUST allow
other values of the fields F0, F1, F2, Y, and PHSsize, and MUST other values of the fields F0, F1, F2, Y, and PHSsize, and MUST
ignore any additional fields, when present, than specified above ignore any additional fields, when present, than specified above
in the PHES. in the PHES.
5 Packetization Rules 5 Packetization Rules
The following packetization rules apply: The following packetization rules apply:
o If tx-mode is equal to "MRST" or "MRMT" or sprop-max-don-diff is o If sprop-max-don-diff is greater than 0 for any of the RTP
greater than 0 for an RTP stream, the transmission order of NAL streams, the transmission order of NAL units carried in the RTP
units carried in the RTP stream MAY be different than the NAL stream MAY be different than the NAL unit decoding order and the
unit decoding order. Otherwise (tx-mode is equal to "SRST" and NAL unit output order. Otherwise (sprop-max-don-diff is equal
sprop-max-don-diff is equal to 0 for an RTP stream), the to 0 for all the RTP streams), the transmission order of NAL
transmission order of NAL units carried in the RTP stream MUST units carried in the RTP stream MUST be the same as the NAL unit
be the same as the NAL unit decoding order. decoding order, and, when tx-mode is equal to "MRST" 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 49, line 26 skipping to change at page 49, line 26
transmission delay jitter, the receiver buffer is here after transmission delay jitter, the receiver buffer is here after
called the de-packetization buffer in this section. Receivers called the de-packetization buffer in this section. Receivers
should also prepare for transmission delay jitter; i.e. either should also prepare for transmission delay jitter; i.e. either
reserve separate buffers for transmission delay jitter buffering reserve separate buffers for transmission delay jitter buffering
and de-packetization buffering or use a receiver buffer for both and de-packetization buffering or use a receiver buffer for both
transmission delay jitter and de-packetization. Moreover, transmission delay jitter and de-packetization. Moreover,
receivers should take transmission delay jitter into account in receivers should take transmission delay jitter into account in
the buffering operation; e.g. by additional initial buffering the buffering operation; e.g. by additional initial buffering
before starting of decoding and playback. before starting of decoding and playback.
If only one RTP stream is being received and sprop-max-don-diff When sprop-max-don-diff is equal to 0 for all the received RTP
of the only RTP stream being received is equal to 0, the de- streams, the de-packetization buffer size is zero bytes and the
packetization buffer size is zero bytes, i.e. the NAL units process described in the remainder of this paragraph applies.
carried in the RTP stream are directly passed to the decoder in When there is only one RTP stream received, the NAL units carried
their transmission order, which is identical to the decoding in the single RTP stream are directly passed to the decoder in
order of the NAL units. Otherwise, the process described in the their transmission order, which is identical to their decoding
remainder of this section applies. order. When there is more than one RTP stream received, the NAL
units carried in the multiple RTP streams are passed to the
decoder in their NTP timestamp order. When there are several NAL
units of different RTP streams with the same NTP timestamp, the
order to pass them to the decoder is their dependency order,
where NAL units of a dependee RTP stream are passed to the
decoder prior to the NAL units of the dependent RTP stream. When
there are several NAL units of the same RTP stream with the same
NTP timestamp, the order to pass them to the decoder is their
transmission order.
Informative note: The mapping between RTP and NTP
timestamps is conveyed in RTCP SR packets. In addition,
the mechanisms for faster media timestamp synchronization
discussed in [RFC6051] may be used to speed up the
acquisition of the RTP-to-wall-clock mapping.
When sprop-max-don-diff is greater than 0 for any the received
RTP streams, the process described in the remainder of this
section applies.
There are two buffering states in the receiver: initial buffering There are two buffering states in the receiver: initial buffering
and buffering while playing. Initial buffering starts when the and buffering while playing. Initial buffering starts when the
reception is initialized. After initial buffering, decoding and reception is initialized. After initial buffering, decoding and
playback are started, and the buffering-while-playing mode is playback are started, and the buffering-while-playing mode is
used. used.
Regardless of the buffering state, the receiver stores incoming Regardless of the buffering state, the receiver stores incoming
NAL units, in reception order, into the de-packetization buffer. NAL units, in reception order, into the de-packetization buffer.
NAL units carried in RTP packets are stored in the de- NAL units carried in RTP packets are stored in the de-
skipping to change at page 50, line 22 skipping to change at page 50, line 41
Initial buffering lasts until condition A (the difference between Initial buffering lasts until condition A (the difference between
the greatest and smallest AbsDon values of the NAL units in the the greatest and smallest AbsDon values of the NAL units in the
de-packetization buffer is greater than or equal to the value of de-packetization buffer is greater than or equal to the value of
sprop-max-don-diff of the highest RTP stream) or condition B (the sprop-max-don-diff of the highest RTP stream) or condition B (the
number of NAL units in the de-packetization buffer is greater number of NAL units in the de-packetization buffer is greater
than the value of sprop-depack-buf-nalus) is true. than the value of sprop-depack-buf-nalus) is true.
After initial buffering, whenever condition A or condition B is After initial buffering, whenever condition A or condition B is
true, the following operation is repeatedly applied until both true, the following operation is repeatedly applied until both
condition A and condition A become false: condition A and condition B become false:
o The NAL unit in the de-packetization buffer with the smallest o The NAL unit in the de-packetization buffer with the smallest
value of AbsDon is removed from the de-packetization buffer value of AbsDon is removed from the de-packetization buffer
and passed to the decoder. and passed to the decoder.
When no more NAL units are flowing into the de-packetization When no more NAL units are flowing into the de-packetization
buffer, all NAL units remaining in the de-packetization buffer buffer, all NAL units remaining in the de-packetization buffer
are removed from the buffer and passed to the decoder in the are removed from the buffer and passed to the decoder in the
order of increasing AbsDon values. order of increasing AbsDon values.
skipping to change at page 69, line 9 skipping to change at page 69, line 29
the encoder is free to choose any picture rate according to the encoder is free to choose any picture rate according to
the highest level and any signaled optional parameters. the highest level and any signaled optional parameters.
The value of max-fps MUST be smaller than or equal to the The value of max-fps MUST be smaller than or equal to the
full picture rate that is implied by the highest level and, full picture rate that is implied by the highest level and,
when present, one or more of the parameters max-lsr, max- when present, one or more of the parameters max-lsr, max-
lps, and max-br. lps, and max-br.
sprop-max-don-diff: sprop-max-don-diff:
The value of this parameter MUST be equal to 0, if the RTP If tx-mode is equal to "SRST" and there is no NAL unit
stream does not depend on other RTP streams and there is no naluA that is followed in transmission order by any NAL
NAL unit naluA that is followed in transmission order by unit preceding naluA in decoding order (i.e. the
any NAL unit preceding naluA in decoding order. Otherwise, transmission order of the NAL units is the same as the
this parameter specifies the maximum absolute difference decoding order), the value of this parameter MUST be equal
between the decoding order number (i.e., AbsDon) values of to 0.
any two NAL units naluA and naluB, where naluA follows
naluB in decoding order and precedes naluB in transmission Otherwise, if tx-mode is equal to "MRST" or "MRMT", the
order. decoding order of the NAL units of all the RTP streams is
the same as the NAL unit transmission order and the NAL
unit output order, the value of this parameter MUST be
equal to either 0 or 1.
Otherwise, if tx-mode is equal to "MRST" or "MRMT" and the
decoding order of the NAL units of all the RTP streams is
the same as the NAL unit transmission order but not the
same as the NAL unit output order, the value of this
parameter MUST be equal to 1.
Otherwise, this parameter specifies the maximum absolute
difference between the decoding order number (i.e., AbsDon)
values of any two NAL units naluA and naluB, where naluA
follows naluB in decoding order and precedes naluB in
transmission order.
The value of sprop-max-don-diff MUST be an integer in the The value of sprop-max-don-diff MUST be an integer in the
range of 0 to 32767, inclusive. range of 0 to 32767, inclusive.
When not present, the value of sprop-max-don-diff is When not present, the value of sprop-max-don-diff is
inferred to be equal to 0. inferred to be equal to 0.
When the RTP stream depends on one or more other RTP
streams (in this case tx-mode MUST be equal to "MRST" or
"MRMT"), this parameter MUST be present and the value MUST
be greater than 0.
Informative note: When the RTP stream does not depend on
other RTP streams, any of SRST, MRST and MRMT may be in
use.
sprop-depack-buf-nalus: sprop-depack-buf-nalus:
This parameter specifies the maximum number of NAL units This parameter specifies the maximum number of NAL units
that precede a NAL unit in transmission order and follow that precede a NAL unit in transmission order and follow
the NAL unit in decoding order. the NAL unit in decoding order.
The value of sprop-depack-buf-nalus MUST be an integer in The value of sprop-depack-buf-nalus MUST be an integer in
the range of 0 to 32767, inclusive. the range of 0 to 32767, inclusive.
When not present, the value of sprop-depack-buf-nalus is When not present, the value of sprop-depack-buf-nalus is
inferred to be equal to 0. inferred to be equal to 0.
When the RTP stream depends on one or more other RTP When sprop-max-don-diff is present and greater than 0, this
streams (in this case tx-mode MUST be equal to "MRST" or parameter MUST be present and the value MUST be greater
"MRMT"), this parameter MUST be present and the value MUST than 0.
be greater than 0.
sprop-depack-buf-bytes: sprop-depack-buf-bytes:
This parameter signals the required size of the de- This parameter signals the required size of the de-
packetization buffer in units of bytes. The value of the packetization buffer in units of bytes. The value of the
parameter MUST be greater than or equal to the maximum parameter MUST be greater than or equal to the maximum
buffer occupancy (in units of bytes) of the de- buffer occupancy (in units of bytes) of the de-
packetization buffer as specified in section 6. packetization buffer as specified in section 6.
The value of sprop-depack-buf-bytes MUST be an integer in The value of sprop-depack-buf-bytes MUST be an integer in
the range of 0 to 4294967295, inclusive. the range of 0 to 4294967295, inclusive.
When the RTP stream depends on one or more other RTP When sprop-max-don-diff is present and greater than 0, this
streams (in this case tx-mode MUST be equal to "MRST" or parameter MUST be present and the value MUST be greater
"MRMT") or sprop-max-don-diff is present and greater than 0. When not present, the value of sprop-depack-buf-
than 0, this parameter MUST be present and the value MUST bytes is inferred to be equal to 0.
be greater than 0.
Informative note: The value of sprop-depack-buf-bytes Informative note: The value of sprop-depack-buf-bytes
indicates the required size of the de-packetization indicates the required size of the de-packetization
buffer only. When network jitter can occur, an buffer only. When network jitter can occur, an
appropriately sized jitter buffer has to be available as appropriately sized jitter buffer has to be available as
well. well.
depack-buf-cap: depack-buf-cap:
This parameter signals the capabilities of a receiver This parameter signals the capabilities of a receiver
skipping to change at page 81, line 33 skipping to change at page 82, line 17
parallel-cap.spatial-seg-idc of the capability point. A parallel-cap.spatial-seg-idc of the capability point. A
bitstream that is sent based on choosing a capability point bitstream that is sent based on choosing a capability point
with parallel tool type 't' from dec-parallel-cap MUST have with parallel tool type 't' from dec-parallel-cap MUST have
entropy_coding_sync_enabled_flag equal to 0 and entropy_coding_sync_enabled_flag equal to 0 and
min_spatial_segmentation_idc equal to or larger than dec- min_spatial_segmentation_idc equal to or larger than dec-
parallel-cap.spatial-seg-idc of the capability point. parallel-cap.spatial-seg-idc of the capability point.
o An offerer has to include the size of the de-packetization o An offerer has to include the size of the de-packetization
buffer, sprop-depack-buf-bytes, as well as sprop-max-don-diff buffer, sprop-depack-buf-bytes, as well as sprop-max-don-diff
and sprop-depack-buf-nalus, in the offer for an interleaved and sprop-depack-buf-nalus, in the offer for an interleaved
HEVC bitstream or for the MRST or MRMT transmission mode. To HEVC bitstream or for the MRST or MRMT transmission mode when
enable the offerer and answerer to inform each other about sprop-max-don-diff is greater than 0 for at least one of the
their capabilities for de-packetization buffering in receiving RTP streams. To enable the offerer and answerer to inform
RTP streams, both parties are RECOMMENDED to include depack- each other about their capabilities for de-packetization
buf-cap. For interleaved RTP streams or in MRST or MRMT, it buffering in receiving RTP streams, both parties are
is also RECOMMENDED to consider offering multiple payload RECOMMENDED to include depack-buf-cap. For interleaved RTP
types with different buffering requirements when the streams or in MRST or MRMT, it is also RECOMMENDED to consider
capabilities of the receiver are unknown. offering multiple payload types with different buffering
requirements when the capabilities of the receiver are
unknown.
o The capability parameter include-dph MAY be used to declare o The capability parameter include-dph MAY be used to declare
the capability to utilize decoded picture hash SEI messages the capability to utilize decoded picture hash SEI messages
and which types of hashes in any HEVC RTP streams received by and which types of hashes in any HEVC RTP streams received by
the offerer or answerer. the offerer or answerer.
o The sprop-vps, sprop-sps, or sprop-pps, when present (included o The sprop-vps, sprop-sps, or sprop-pps, when present (included
in the "a=fmtp" line of SDP or conveyed using the "fmtp" in the "a=fmtp" line of SDP or conveyed using the "fmtp"
source attribute as specified in section 6.3 of [RFC5576]), source attribute as specified in section 6.3 of [RFC5576]),
are used for out-of-band transport of the parameter sets (VPS, are used for out-of-band transport of the parameter sets (VPS,
skipping to change at page 99, line 22 skipping to change at page 100, line 11
[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.
[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
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
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, April 2014. Security Solution", RFC 7202, April 2014.
[Wang05] Wang, Y.-K., Zhu, C., and Li, H., "Error resilient [Wang05] Wang, Y.-K., Zhu, C., and Li, H., "Error resilient
video coding using flexible reference fames", Visual video coding using flexible reference fames", Visual
Communications and Image Processing 2005 (VCIP 2005), Communications and Image Processing 2005 (VCIP 2005),
 End of changes. 31 change blocks. 
109 lines changed or deleted 146 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/