draft-ietf-payload-rtp-h265-14.txt   draft-ietf-payload-rtp-h265-15.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: February 2016 T. Schierl Expires: May 2016 T. Schierl
Fraunhofer HHI Fraunhofer HHI
S. Wenger S. Wenger
Vidyo Vidyo
M. M. Hannuksela M. M. Hannuksela
Nokia Nokia
August 24, 2015 November 5, 2015
RTP Payload Format for H.265/HEVC Video RTP Payload Format for H.265/HEVC Video
draft-ietf-payload-rtp-h265-14.txt draft-ietf-payload-rtp-h265-15.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 January 24, 2016. This Internet-Draft will expire on May 5, 2016.
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..................................6
1.1.2 Systems and Transport Interfaces.....................7 1.1.2 Systems and Transport Interfaces......................8
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......................................17
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............................................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..............................30
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...........76 7.2.1 Mapping of Payload Type Parameters to SDP............76
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...........88 7.2.5 Dependency Signaling in Multi-Stream Mode............88
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)..............................89 8.2 Slice Loss Indication (SLI)...............................89
8.3 Reference Picture Selection Indication (RPSI)............91 8.3 Reference Picture Selection Indication (RPSI).............91
8.4 Full Intra Request (FIR).................................91 8.4 Full Intra Request (FIR)..................................91
9 Security Considerations.......................................92 9 Security Considerations........................................92
10 Congestion Control...........................................93 10 Congestion Control............................................94
11 IANA Consideration...........................................94 11 IANA Consideration............................................95
12 Acknowledgements.............................................94 12 Acknowledgements..............................................95
13 References...................................................95 13 References....................................................96
13.1 Normative References....................................95 13.1 Normative References.....................................96
13.2 Informative References..................................96 13.2 Informative References...................................97
14 Authors' Addresses...........................................98 14 Authors' Addresses............................................99
1 Introduction 1 Introduction
1.1 Overview of the HEVC Codec The 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].
As both H.264 [H.264] and its RTP payload format [RFC6184] are This memo describes an RTP payload format for HEVC. It shares
widely deployed and generally known in the relevant implementer its basic design with the RTP payload formats of [RFC6184] and
communities, frequently only the differences between those two [RFC6190]. With respect to design philosophy, security,
specifications are highlighted in non-normative, explanatory congestion control, and overall implementation complexity, it has
similar properties to those earlier payload format
specifications. This is a conscious choice, as at least RFC6184
is widely deployed and generally known in the relevant
implementer communities. Mechanisms from RFC6190 were
incorporated as HEVC version 1 supports temporal scalability.
In order to help the overlapping implementer community,
frequently only the differences between RFC6184/RFC6190 and the
HEVC payload format are highlighted in non-normative, explanatory
parts of this memo. Basic familiarity with both specifications parts of this memo. Basic familiarity with both specifications
is assumed for those parts. However, the normative parts of this is assumed for those parts. However, the normative parts of this
memo do not require study of H.264 or its RTP payload format. memo do not require study of RFC6184 or RFC6190.
H.264 and HEVC share a similar hybrid video codec design. 1.1 Overview of the HEVC Codec
Conceptually, both technologies include a video coding layer
H.264 and HEVC share a similar hybrid video codec design. In
this memo, we provide a very brief overview of those features of
HEVC that are in some form addressed by the payload format
specified herein. Implementers have to read and understand, and
apply the ITU-T/ISO/IEC specifications pertaining to HEVC to
arrive at interoperable, well-performing implementations.
Implementers should consider testing their design (including the
interworking between the payload format implementation and the
core video codec) using the tools provided by ITU-T/ISO/IEC; for
example, conformance bitstreams as specified in [add confermance
spec). Not doing so has historically led to badly performing and
unsecure systems.
Conceptually, both H.264 and HEVC include a video coding layer
(VCL), which is often used to refer to the coding-tool features, (VCL), which is often used to refer to the coding-tool features,
and a network abstraction layer (NAL), which is often used to and a network abstraction layer (NAL), which is often used to
refer to the systems and transport interface aspects of the refer to the systems and transport interface aspects of the
codecs. codecs.
1.1.1 Coding-Tool Features 1.1.1 Coding-Tool Features
Similarly to earlier hybrid-video-coding-based standards, Similarly to earlier hybrid-video-coding-based standards,
including H.264, the following basic video coding design is including H.264, the following basic video coding design is
employed by HEVC. A prediction signal is first formed either by employed by HEVC. A prediction signal is first formed either by
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
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 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 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 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 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 92, line 14 skipping to change at page 92, line 14
Upon reception of a FIR, a sender MUST send an IDR picture. Upon reception of a FIR, a sender MUST send an IDR picture.
Parameter sets MUST also be sent, except when there is a priori Parameter sets MUST also be sent, except when there is a priori
knowledge that the parameter sets have been correctly knowledge that the parameter sets have been correctly
established. A typical example for that is an understanding established. A typical example for that is an understanding
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
The scope of this Security Considerations section is limited to
the payload format itself, and to one feature of HEVC that may
pose a particularly serious security risk if implemented naively.
The payload format, in isolation, does not form a complete
system. Implementers are advised to read and understand relevant
security related documents, especially those pertaining to RTP
(see the security considerations section in RFC 3550 [RFC3550]),
and the security of the call control stack chosen (that may make
use of the media type registration of this memo). Implementers
should also consider known security vulnerabilities of video
coding and decoding implementations in general and avoid those.
Within this RTP payload format, and with the exception of the
user data SEI message as described below, no security threats
other than those common to RTP payload formats are known. In
other words, neither the various media plane based mechanisms,
nor the signaling part of this memo, seems to pose a security
risk beyond those common to all RTP based systems.
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 "Securing the RTP Protocol Framework: Why RTP Does Not Mandate as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate
a Single Media Security Solution" RFC 7202 [RFC7202] discusses, a Single Media Security Solution" RFC 7202 [RFC7202] discusses,
it is not an RTP payload format's responsibility to discuss or it is not an RTP payload format's responsibility to discuss or
mandate what solutions are used to meet the basic security goals mandate what solutions are used to meet the basic security goals
like confidentiality, integrity and source authenticity for RTP like confidentiality, integrity and source authenticity for RTP
skipping to change at page 93, line 5 skipping to change at page 93, line 23
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].
Decoders MUST exercise caution with respect to the handling of Like [H.264], HEVC includes a user data Supplementary Enhancement
user data SEI messages, particularly if they contain active Information (SEI) message. This SEI message allows inclusion of
elements, and MUST restrict their domain of applicability to the an arbitrary bitstring into the video bitstream. Such a bitstring
presentation of the bitstream. could include JavaScript, machine code, and other active content.
HEVC leaves the handling of this SEI message to the receiving
system. In order to avoid harmful side effects of the user data
SEI message, decoder implementations cannot naviely trust its
content. For example, it would be a bad and insecure
implementation practice to forward any JavaScript a decoder
implementation detects to a web browser. The safest way to deal
with user data SEI messages is to simply discard them, but that
can have negative side effects on the quality of experience by
the user.
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
allowed to perform such operations, a MANE is required to be a allowed to perform such operations, a MANE is required to be a
trusted entity that is included in the security context trusted entity that is included in the security context
establishment. establishment.
skipping to change at page 95, line 7 skipping to change at page 95, line 35
Muhammed Coban and Marta Karczewicz are thanked for discussions Muhammed Coban and Marta Karczewicz are thanked for discussions
on the specification of the use with feedback messages and other on the specification of the use with feedback messages and other
aspects in this memo. Jonathan Lennox and Jill Boyce are thanked aspects in this memo. Jonathan Lennox and Jill Boyce are thanked
for their contributions to the PACI design included in this memo. for their contributions to the PACI design included in this memo.
Rickard Sjoberg, Arild Fuldseth, Bo Burman, Magnus Westerlund, Rickard Sjoberg, Arild Fuldseth, Bo Burman, Magnus Westerlund,
and Tom Kristensen are thanked for their contributions to and Tom Kristensen are thanked for their contributions to
parallel processing related signalling. Magnus Westerlund, parallel processing related signalling. Magnus Westerlund,
Jonathan Lennox, Bernard Aboba, Jonatan Samuelsson, Roni Even, Jonathan Lennox, Bernard Aboba, Jonatan Samuelsson, Roni Even,
Rickard Sjoberg, Sachin Deshpande, Woo Johnman, Mo Zanaty, Ross Rickard Sjoberg, Sachin Deshpande, Woo Johnman, Mo Zanaty, Ross
Finlayson, Danny Hong, Bo Burman, Ben Campbell, Brian Carpenter, Finlayson, Danny Hong, Bo Burman, Ben Campbell, Brian Carpenter,
and Qin Wu made valuable reviewing comments that led to Qin Wu, and Stephen Farrell made valuable reviewing comments that
improvements. led to improvements.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot, and
the .txt file was generated using the online Word-post procesor
available here: http://www.isi.edu/touch/tools/rfc-word-
template.html.
13 References 13 References
13.1 Normative References 13.1 Normative References
[HEVC] ITU-T Recommendation H.265, "High efficiency video [HEVC] ITU-T Recommendation H.265, "High efficiency video
coding", April 2013. coding", April 2013.
[H.264] ITU-T Recommendation H.264, "Advanced video coding for [H.264] ITU-T Recommendation H.264, "Advanced video coding for
generic audiovisual services", April 2013. generic audiovisual services", April 2013.
skipping to change at page 96, line 32 skipping to change at page 97, line 24
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[RFC5576] Lennox, J., Ott, J., and Schierl, T., "Source-Specific [RFC5576] Lennox, J., Ott, J., and Schierl, T., "Source-Specific
Media Attributes in the Session Description Protocol", Media Attributes in the Session Description Protocol",
RFC 5576, June 2009. RFC 5576, June 2009.
[RFC5583] Schierl, T. and Wenger, S., "Signaling Media Decoding [RFC5583] Schierl, T. and Wenger, S., "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)",
RFC 5583, July 2009. RFC 5583, July 2009.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup,
"RTP Payload Format for H.264 Video", RFC 6184, May
2011.
13.2 Informative References 13.2 Informative References
[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.
skipping to change at page 97, line 24 skipping to change at page 98, line 14
[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.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP "Sending Multiple Media Streams in a Single RTP
Session", draft-ietf-avtcore-rtp-multi-stream-08 (work Session", draft-ietf-avtcore-rtp-multi-stream-09 (work
in progress), July 2015. in progress), September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp-
bundle-negotiation-23 (work in progress), July 2015. bundle-negotiation-23 (work in progress), July 2015.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [I-D.ietf-avtext-rtp-grouping-taxonomy]
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G.,
and Burman, B. "A Taxonomy of Grouping Semantics and and Burman, B. "A Taxonomy of Grouping Semantics and
skipping to change at page 98, line 31 skipping to change at page 99, line 21
[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 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of
RTP Flows", RFC 6051, November 2010. RTP Flows", RFC 6051, November 2010.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup,
"RTP Payload Format for H.264 Video", RFC 6184, May
2011.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, May 2011.
[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),
July 2005, Beijing, China. July 2005, Beijing, China.
14 Authors' Addresses 14 Authors' Addresses
Ye-Kui Wang Ye-Kui Wang
Qualcomm Incorporated Qualcomm Incorporated
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92121, USA San Diego, CA 92121, USA
Phone: +1-858-651-8345 Phone: +1-858-651-8345
EMail: yekuiw@qti.qualcomm.com EMail: yekui.wang@gmail.com
Yago Sanchez Yago Sanchez
Fraunhofer HHI Fraunhofer HHI
Einsteinufer 37 Einsteinufer 37
D-10587 Berlin, Germany D-10587 Berlin, Germany
Phone: +49-30-31002-227 Phone: +49-30-31002-227
Email: yago.sanchez@hhi.fraunhofer.de Email: yago.sanchez@hhi.fraunhofer.de
Thomas Schierl Thomas Schierl
Fraunhofer HHI Fraunhofer HHI
 End of changes. 20 change blocks. 
113 lines changed or deleted 170 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/