draft-ietf-payload-rtp-h265-12.txt   draft-ietf-payload-rtp-h265-13.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: December 2015 T. Schierl Expires: December 2015 T. Schierl
Fraunhofer HHI Fraunhofer HHI
S. Wenger S. Wenger
Vidyo Vidyo
M. M. Hannuksela M. M. Hannuksela
Nokia Nokia
June 3, 2015 June 3, 2015
RTP Payload Format for High Efficiency Video Coding RTP Payload Format for High Efficiency Video Coding
draft-ietf-payload-rtp-h265-12.txt draft-ietf-payload-rtp-h265-13.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 3, line 7 skipping to change at page 3, line 7
(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...................................................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.............................................25 4 RTP Payload Format............................................25
4.1 RTP Header Usage..........................................25 4.1 RTP Header Usage.........................................25
4.2 Payload Header Usage......................................27 4.2 Payload Header Usage.....................................27
4.3 Transmission Modes........................................28 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......................................50 7 Payload Format Parameters.....................................50
7.1 Media Type Registration...................................51 7.1 Media Type Registration..................................51
7.2 SDP Parameters............................................76 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........................88 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).............................89 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........................................92 9 Security Considerations.......................................92
10 Congestion Control............................................93 10 Congestion Control...........................................93
11 IANA Consideration............................................95 11 IANA Consideration...........................................95
12 Acknowledgements..............................................95 12 Acknowledgements.............................................95
13 References....................................................95 13 References...................................................95
13.1 Normative References.....................................95 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 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 cooperation or knowledge of the HEVC encoder. A fragment of a NAL
NAL unit consists of an integer number of consecutive octets of unit consists of an integer number of consecutive octets of that
that NAL unit. Fragments of the same NAL unit MUST be sent in NAL unit. Fragments of the same NAL unit MUST be sent in consecutive
consecutive order with ascending RTP sequence numbers (with no order with ascending RTP sequence numbers (with no other RTP packets
other RTP packets within the same RTP stream being sent between within the same RTP stream being sent between the first and last
the first and last fragment). 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
skipping to change at page 39, line 4 skipping to change at page 39, line 4
The PACI packet structure is based on a payload header extension The PACI packet structure is based on a payload header extension
mechanism that is generic and extensible to carry payload header mechanism that is generic and extensible to carry payload header
extensions. In this section, the focus lies on the use within extensions. In this section, the focus lies on the use within
this specification. Section 4.4.4.2 below provides guidance for this specification. Section 4.4.4.2 below provides guidance for
the specification designers in how to employ the extension the specification designers in how to employ the extension
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 0 above. The payload header is followed by the fields A, Section 4.2 above. The payload header is followed by the fields
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) |
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 This memo defines only a single payload header extension (Temporal
(Temporal Scalability Control Information, described below in Scalability Control Information, described below in Section 4.5),
Section 4.5), and, therefore, only the F0 bit carries semantics. and, therefore, only the F0 bit carries semantics. F1 and F2 are
F1 and F2 are already named (and not just marked as reserved, as already named (and not just marked as reserved, as a typical video
a typical video spec designer would do). They are intended to spec designer would do). They are intended to signal two additional
signal two additional extensions. The Y bit allows to, extensions. The Y bit allows to, recursively, add further F and Y
recursively, add further F and Y bits to extend the mechanism bits to extend the mechanism beyond 3 possible payload header
beyond 3 possible payload header extensions. It is suggested to extensions. It is suggested to define a new packet type (using a
define a new packet type (using a different value for Type) when different value for Type) when assigning the F1, F2, or Y bits
assigning the F1, F2, or Y bits different semantics than what is different semantics than what is suggested below.
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 47, line 24 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 streams, the transmission order of NAL units carried in the RTP
RTP stream MAY be different than the NAL unit decoding order stream MAY be different than the NAL unit decoding order and the
and the NAL unit output order. Otherwise (sprop-max-don-diff NAL unit output order. Otherwise (sprop-max-don-diff is equal
is equal to 0 for all the RTP streams), the transmission order to 0 for all the RTP streams), the transmission order of NAL
of NAL units carried in the RTP stream MUST be the same as the units carried in the RTP stream MUST be the same as the NAL unit
NAL unit decoding order, and, when tx-mode is equal to "MRST" decoding order, and, when tx-mode is equal to "MRST" or "MRMT",
or "MRMT", MUST also be the same as the NAL unit output order. 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 11 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 use. Otherwise (the value is equal to "SRST"), SRST MUST be
be in use. 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
 End of changes. 8 change blocks. 
91 lines changed or deleted 90 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/