draft-ietf-payload-rtp-h265-13.txt   draft-ietf-payload-rtp-h265-14.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: February 2016 T. Schierl
Fraunhofer HHI Fraunhofer HHI
S. Wenger S. Wenger
Vidyo Vidyo
M. M. Hannuksela M. M. Hannuksela
Nokia Nokia
June 3, 2015 August 24, 2015
RTP Payload Format for High Efficiency Video Coding RTP Payload Format for H.265/HEVC Video
draft-ietf-payload-rtp-h265-13.txt draft-ietf-payload-rtp-h265-14.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 December 3, 2015. This Internet-Draft will expire on January 24, 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
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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...........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...........89 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)..............................90 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).................................92 8.4 Full Intra Request (FIR).................................91
9 Security Considerations.......................................92 9 Security Considerations.......................................92
10 Congestion Control...........................................93 10 Congestion Control...........................................93
11 IANA Consideration...........................................95 11 IANA Consideration...........................................94
12 Acknowledgements.............................................95 12 Acknowledgements.............................................94
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..................................96
14 Authors' Addresses...........................................99 14 Authors' Addresses...........................................98
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 14, line 37 skipping to change at page 14, line 37
granularity of an integer number of CTUs. The targets for this granularity of an integer number of CTUs. The targets for this
type of high-level parallelization are multicore CPUs and DSPs as type of high-level parallelization are multicore CPUs and DSPs as
well as multiprocessor systems. In a system design, to be well as multiprocessor systems. In a system design, to be
useful, these tools require signaling support, which is provided useful, these tools require signaling support, which is provided
in Section 7 of this memo. This section provides a brief in Section 7 of this memo. This section provides a brief
overview of the tools available in [HEVC]. overview of the tools available in [HEVC].
Many of the tools incorporated in HEVC were designed keeping in Many of the tools incorporated in HEVC were designed keeping in
mind the potential parallel implementations in multi-core/multi- mind the potential parallel implementations in multi-core/multi-
processor architectures. Specifically, for parallelization, four processor architectures. Specifically, for parallelization, four
picture partition strategies are available. picture partition strategies, as described below, are available.
Slices are segments of the bitstream that can be reconstructed Slices are segments of the bitstream that can be reconstructed
independently from other slices within the same picture (though independently from other slices within the same picture (though
there may still be interdependencies through loop filtering there may still be interdependencies through loop filtering
operations). Slices are the only tool that can be used for operations). Slices are the only tool that can be used for
parallelization that is also available, in virtually identical parallelization that is also available, in virtually identical
form, in H.264. Slices based parallelization does not require form, in H.264. Slices based parallelization does not require
much inter-processor or inter-core communication (except for much inter-processor or inter-core communication (except for
inter-processor or inter-core data sharing for motion inter-processor or inter-core data sharing for motion
compensation when decoding a predictively coded picture, which is compensation when decoding a predictively coded picture, which is
skipping to change at page 19, line 20 skipping to change at page 19, line 20
This specification uses the notion of setting and clearing a bit This specification uses the notion of setting and clearing a bit
when bit fields are handled. Setting a bit is the same as when bit fields are handled. Setting a bit is the same as
assigning that bit the value of 1 (On). Clearing a bit is the assigning that bit the value of 1 (On). Clearing a bit is the
same as assigning that bit the value of 0 (Off). same as assigning that bit the value of 0 (Off).
3 Definitions and Abbreviations 3 Definitions and Abbreviations
3.1 Definitions 3.1 Definitions
This document uses the terms and definitions of [HEVC]. Section This document uses the terms and definitions of [HEVC]. Section
3.1.1 lists relevant definitions copied from [HEVC] for 3.1.1 lists relevant definitions copied from [HEVC] (the April
convenience. Section 3.1.2 provides definitions specific to this 2013 version of the H.265 specification) for convenience.
memo. Section 3.1.2 provides definitions specific to this memo.
3.1.1 Definitions from the HEVC Specification 3.1.1 Definitions from the HEVC Specification
access unit: A set of NAL units that are associated with each access unit: A set of NAL units that are associated with each
other according to a specified classification rule, are other according to a specified classification rule, are
consecutive in decoding order, and contain exactly one coded consecutive in decoding order, and contain exactly one coded
picture. picture.
BLA access unit: An access unit in which the coded picture is a BLA access unit: An access unit in which the coded picture is a
BLA picture. BLA picture.
skipping to change at page 28, line 18 skipping to change at page 28, line 18
. a single RTP stream on a single Media Transport (SRST), . a single RTP stream on a single Media Transport (SRST),
. multiple RTP streams over a single Media Transport (MRST), . multiple RTP streams over a single Media Transport (MRST),
or or
. multiple RTP streams over multiple Media Transports (MRMT). . multiple RTP streams over multiple Media Transports (MRMT).
Informative Note: While this specification enables the use of Informative Note: While this specification enables the use of
MRST within the H.265 RTP payload, the signaling of MRST within MRST within the H.265 RTP payload, the signaling of MRST within
SDP Offer/Answer is not fully specified at the time of this SDP Offer/Answer is not fully specified at the time of this
writing. See [RFC5576] and [RFC5583] for what is supported writing. See [RFC5576] and [RFC5583] for what is supported
today as well as [I-D.ietf-avtcore-rtp-multi-stream] and [I- today as well as [I-D.ietf-avtcore-rtp-multi-stream] and
D.ietf-mmusic-sdp-bundle-negotiation] for future directions. [I-D.ietf-mmusic-sdp-bundle-negotiation] for future directions.
When in MRMT, the dependency of one RTP stream on another RTP When in MRMT, the dependency of one RTP stream on another RTP
stream is typically indicated as specified in [RFC5583]. stream is typically indicated as specified in [RFC5583].
[RFC5583] can also be utilized to specify dependencies within [RFC5583] can also be utilized to specify dependencies within
MRST, but only if the RTP streams utilize distinct payload types. MRST, but only if the RTP streams utilize distinct payload types.
When an RTP stream A depends on another RTP stream B, the RTP
stream B is referred to as a dependee RTP stream of the RTP
stream A.
SRST or MRST SHOULD be used for point-to-point unicast scenarios, SRST or MRST SHOULD be used for point-to-point unicast scenarios,
while MRMT SHOULD be used for point-to-multipoint multicast while MRMT SHOULD be used for point-to-multipoint multicast
scenarios where different receivers require different operation scenarios where different receivers require different operation
points of the same HEVC bitstream, to improve bandwidth utilizing points of the same HEVC bitstream, to improve bandwidth utilizing
efficiency. efficiency.
Informative note: A multicast may degrade to a unicast after Informative note: A multicast may degrade to a unicast after
all but one receivers have left (this is a justification of all but one receivers have left (this is a justification of
the first "SHOULD" instead of "MUST"), and there might be the first "SHOULD" instead of "MUST"), and there might be
skipping to change at page 61, line 35 skipping to change at page 61, line 35
is a handheld device (as the display orientation may is a handheld device (as the display orientation may
change when the handheld device is turned around), or change when the handheld device is turned around), or
the filler payload SEI message (as there is no point the filler payload SEI message (as there is no point
in just having more bits in SDP). in just having more bits in SDP).
max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc: max-lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, max-tc:
These parameters MAY be used to signal the capabilities of These parameters MAY be used to signal the capabilities of
a receiver implementation. These parameters MUST NOT be a receiver implementation. These parameters MUST NOT be
used for any other purpose. The highest level (specified used for any other purpose. The highest level (specified
by max-recv-level-id) MUST be such that the receiver is by max-recv-level-id) MUST be the highest that the receiver
fully capable of supporting. max-lsr, max-lps, max-cpb, is fully capable of supporting. max-lsr, max-lps, max-cpb,
max-dpb, max-br, max-tr, and max-tc MAY be used to indicate max-dpb, max-br, max-tr, and max-tc MAY be used to indicate
capabilities of the receiver that extend the required capabilities of the receiver that extend the required
capabilities of the highest level, as specified below. capabilities of the highest level, as specified below.
When more than one parameter from the set (max-lsr, max- When more than one parameter from the set (max-lsr, max-
lps, max-cpb, max-dpb, max-br, max-tr, max-tc) is present, lps, max-cpb, max-dpb, max-br, max-tr, max-tc) is present,
the receiver MUST support all signaled capabilities the receiver MUST support all signaled capabilities
simultaneously. For example, if both max-lsr and max-br simultaneously. For example, if both max-lsr and max-br
are present, the highest level with the extension of both are present, the highest level with the extension of both
the picture rate and bitrate is supported. That is, the the picture rate and bitrate is supported. That is, the
skipping to change at page 71, line 14 skipping to change at page 71, line 14
the value of the sprop-depack-buf-bytes parameter is the value of the sprop-depack-buf-bytes parameter is
smaller than or equal to this parameter. smaller than or equal to this parameter.
When not present, the value of depack-buf-cap is inferred When not present, the value of depack-buf-cap is inferred
to be equal to 4294967295. The value of depack-buf-cap to be equal to 4294967295. The value of depack-buf-cap
MUST be an integer in the range of 1 to 4294967295, MUST be an integer in the range of 1 to 4294967295,
inclusive. inclusive.
Informative note: depack-buf-cap indicates the maximum Informative note: depack-buf-cap indicates the maximum
possible size of the de-packetization buffer of the possible size of the de-packetization buffer of the
receiver only. When network jitter can occur, an receiver only, without allowing for network jitter.
appropriately sized jitter buffer has to be available as
well.
sprop-segmentation-id: sprop-segmentation-id:
This parameter MAY be used to signal the segmentation tools This parameter MAY be used to signal the segmentation tools
present in the bitstream and that can be used for present in the bitstream and that can be used for
parallelization. The value of sprop-segmentation-id MUST parallelization. The value of sprop-segmentation-id MUST
be an integer in the range of 0 to 3, inclusive. When not be an integer in the range of 0 to 3, inclusive. When not
present, the value of sprop-segmentation-id is inferred to present, the value of sprop-segmentation-id is inferred to
be equal to 0. be equal to 0.
skipping to change at page 79, line 33 skipping to change at page 79, line 24
when the profile-compatibility-indicator is used in a recvonly when the profile-compatibility-indicator is used in a recvonly
or sendrecv media description, the bitstream using this RTP or sendrecv media description, the bitstream using this RTP
payload type is required to conform to all profiles indicated payload type is required to conform to all profiles indicated
by profile-space, profile-compatibility-indicator, and by profile-space, profile-compatibility-indicator, and
interop-constraints. interop-constraints.
o To simplify handling and matching of these configurations, the o To simplify handling and matching of these configurations, the
same RTP payload type number used in the offer SHOULD also be same RTP payload type number used in the offer SHOULD also be
used in the answer, as specified in [RFC3264]. used in the answer, as specified in [RFC3264].
o The same RTP payload type number used in the offer MUST be o The same RTP payload type number used in the offer for the
used in the answer when the answer includes recv-sub-layer-id. media subtype H265 MUST be used in the answer when the answer
When the answer does not include recv-sub-layer-id, the answer includes recv-sub-layer-id. When the answer does not include
MUST NOT contain a payload type number used in the offer recv-sub-layer-id, the answer MUST NOT contain a payload type
unless the configuration is exactly the same as in the offer number used in the offer for the media subtype H265 unless the
or the configuration in the answer only differs from that in configuration is exactly the same as in the offer or the
the offer with a different value of level-id. The answer MAY configuration in the answer only differs from that in the
offer with a different value of level-id. The answer MAY
contain the recv-sub-layer-id parameter if an HEVC bitstream contain the recv-sub-layer-id parameter if an HEVC bitstream
contains multiple operation points (using temporal scalability contains multiple operation points (using temporal scalability
and sub-layers) and sprop-vps is included in the offer where and sub-layers) and sprop-vps is included in the offer where
information of sub-layers are present in the first video information of sub-layers are present in the first video
parameter set contained in sprop-vps. If the sprop-vps is parameter set contained in sprop-vps. If the sprop-vps is
provided in an offer, an answerer MAY select a particular provided in an offer, an answerer MAY select a particular
operation point indicated in the first video parameter set operation point indicated in the first video parameter set
contained in sprop-vps. When the answer includes recv-sub- contained in sprop-vps. When the answer includes recv-sub-
layer-id that is less than sprop-sub-layer-id in the offer, layer-id that is less than sprop-sub-layer-id in the offer,
all video parameter sets contained in the sprop-vps parameter all video parameter sets contained in the sprop-vps parameter
skipping to change at page 89, line 5 skipping to change at page 88, line 32
When out-of-band transport of parameter sets is used, parameter When out-of-band transport of parameter sets is used, parameter
sets MAY still be additionally transported in-band unless sets MAY still be additionally transported in-band unless
explicitly disallowed by an application, and some of these explicitly disallowed by an application, and some of these
additionally in-band transported parameter sets may update some additionally in-band transported parameter sets may update some
of the out-of-band transported parameter sets. Update of a of the out-of-band transported parameter sets. Update of a
parameter set refers to sending of a parameter set of the same parameter set refers to sending of a parameter set of the same
type using the same parameter set ID but with different values type using the same parameter set ID but with different values
for at least one other parameter of the parameter set. for at least one other parameter of the parameter set.
7.2.5Dependency Signaling in Multi-Stream Mode 7.2.5 Dependency Signaling in Multi-Stream Mode
If MRST or MRMT is used, the rules on signaling media decoding If MRST or MRMT is used, the rules on signaling media decoding
dependency in SDP as defined in [RFC5583] apply. The rules on dependency in SDP as defined in [RFC5583] apply. The rules on
"hierarchical or layered encoding" with multicast in Section 5.7 "hierarchical or layered encoding" with multicast in Section 5.7
of [RFC4566] do not apply. This means that the notation for of [RFC4566] do not apply. This means that the notation for
Connection Data "c=" SHALL NOT be used with more than one Connection Data "c=" SHALL NOT be used with more than one
address, i.e. the sub-field <number of addresses> in the sub- address, i.e. the sub-field <number of addresses> in the sub-
field <connection-address> of the "c=" field, described in field <connection-address> of the "c=" field, described in
[RFC4566], must not be present. The order of session dependency [RFC4566], must not be present. The order of session dependency
is given from the RTP stream containing the lowest temporal sub- is given from the RTP stream containing the lowest temporal sub-
skipping to change at page 91, line 37 skipping to change at page 91, line 23
picture buffer and requests the encoder to use that correct picture buffer and requests the encoder to use that correct
picture availability information when encoding the next picture, picture availability information when encoding the next picture,
so to stop further temporal error propagation. For this so to stop further temporal error propagation. For this
approach, the decoder side should use the RPSI feedback message. approach, the decoder side should use the RPSI feedback message.
Encoders can encode some long-term reference pictures as Encoders can encode some long-term reference pictures as
specified in H.264 or HEVC for purposes described in the previous specified in H.264 or HEVC for purposes described in the previous
paragraph without the need of a huge decoded picture buffer. As paragraph without the need of a huge decoded picture buffer. As
shown in [Wang05], with a flexible reference picture management shown in [Wang05], with a flexible reference picture management
scheme as in H.264 and HEVC, even a decoded picture buffer size scheme as in H.264 and HEVC, even a decoded picture buffer size
of two would work for the approach described in the previous of two picture storage buffers would work for the approach
paragraph. described in the previous paragraph.
The field "Native RPSI bit string defined per codec" is a base16 The field "Native RPSI bit string defined per codec" is a base16
[RFC4648] representation of the 8 bits consisting of 2 most [RFC4648] representation of the 8 bits consisting of 2 most
significant bits equal to 0 and 6 bits of nuh_layer_id, as significant bits equal to 0 and 6 bits of nuh_layer_id, as
defined in [HEVC], followed by the 32 bits representing the value defined in [HEVC], followed by the 32 bits representing the value
of the PicOrderCntVal (in network byte order), as defined in of the PicOrderCntVal (in network byte order), as defined in
[HEVC], for the picture that is indicated by the RPSI feedback [HEVC], for the picture that is indicated by the RPSI feedback
message. message.
The use of the RPSI feedback message as positive acknowledgement The use of the RPSI feedback message as positive acknowledgement
with HEVC is deprecated. In other words, the RPSI feedback with HEVC is deprecated. In other words, the RPSI feedback
message MUST only be used as a reference picture selection message MUST only be used as a reference picture selection
request, such that it can also be used in multicast. request, such that it can also be used in multicast.
8.4 Full Intra Request (FIR) 8.4 Full Intra Request (FIR)
skipping to change at page 93, line 22 skipping to change at page 93, line 8
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 Decoders MUST exercise caution with respect to the handling of
user data SEI messages, particularly if they contain active user data SEI messages, particularly if they contain active
elements, and MUST restrict their domain of applicability to the elements, and MUST restrict their domain of applicability to the
presentation containing the bitstream. presentation of the bitstream.
End-to-end security with authentication, integrity, or End-to-end security with authentication, integrity, or
confidentiality protection will prevent a MANE from performing confidentiality protection will prevent a MANE from performing
media-aware operations other than discarding complete packets. media-aware operations other than discarding complete packets.
In the case of confidentiality protection, it will even be In the case of confidentiality protection, it will even be
prevented from discarding packets in a media-aware way. To be prevented from discarding packets in a media-aware way. To be
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 21 skipping to change at page 95, line 6
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, and Ben Campbell made valuable Finlayson, Danny Hong, Bo Burman, Ben Campbell, Brian Carpenter,
reviewing comments that led to improvements. and Qin Wu made valuable reviewing comments that 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.
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.
skipping to change at page 97, line 5 skipping to change at page 96, line 36
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, [RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup,
"RTP Payload Format for H.264 Video", RFC 6184, May "RTP Payload Format for H.264 Video", RFC 6184, May
2011. 2011.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, 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 39 skipping to change at page 97, line 24
[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-05 (work Session", draft-ietf-avtcore-rtp-multi-stream-08 (work
in progress), July 2014. in progress), July 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-02 (work in progress), October 2014. 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
Mechanisms for Real-Time Transport", draft-ietf-avtext- Mechanisms for Real-Time Transport", draft-ietf-avtext-
rtp-grouping-taxonomy-02 (work in progress), June 2014. rtp-grouping-taxonomy-08 (work in progress), July 2015.
[ISOBMFF] IS0/IEC 14496-12 | 15444-12: "Information technology - [ISOBMFF] IS0/IEC 14496-12 | 15444-12: "Information technology -
Coding of audio-visual objects - Part 12: ISO base Coding of audio-visual objects - Part 12: ISO base
media file format" | "Information technology - JPEG media file format" | "Information technology - JPEG
2000 image coding system - Part 12: ISO base media file 2000 image coding system - Part 12: ISO base media file
format", 2012. format", 2012.
[JCTVC-J0107] [JCTVC-J0107]
Wang, Y.-K., Chen, Y., Joshi, R., and Ramasubramonian, Wang, Y.-K., Chen, Y., Joshi, R., and Ramasubramonian,
K., "AHG9: On RAP pictures", JCT-VC document JCTVC- K., "AHG9: On RAP pictures", JCT-VC document JCTVC-
 End of changes. 26 change blocks. 
49 lines changed or deleted 41 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/