draft-ietf-avtext-avpf-ccm-layered-01.txt   draft-ietf-avtext-avpf-ccm-layered-02.txt 
Network Working Group S. Wenger Network Working Group S. Wenger
Internet-Draft J. Lennox Internet-Draft J. Lennox
Updates: 5104 (if approved) Vidyo, Inc. Updates: 5104 (if approved) Vidyo, Inc.
Intended status: Standards Track B. Burman Intended status: Standards Track B. Burman
Expires: November 18, 2016 M. Westerlund Expires: March 26, 2017 M. Westerlund
Ericsson Ericsson
May 17, 2016 September 22, 2016
Using Codec Control Messages in the RTP Audio-Visual Profile with Using Codec Control Messages in the RTP Audio-Visual Profile with
Feedback with Layered Codecs Feedback with Layered Codecs
draft-ietf-avtext-avpf-ccm-layered-01 draft-ietf-avtext-avpf-ccm-layered-02
Abstract Abstract
This document fixes a shortcoming in the specification language of This document updates RFC5104 by fixing a shortcoming in the
the Codec Control Message Full Intra Request (FIR) as defined in specification language of the Codec Control Message Full Intra
RFC5104 when using with layered codecs. In particular, a Decoder Request (FIR) as defined in RFC5104 when using it with layered
Refresh Point needs to be sent by a media sender when a FIR is codecs. In particular, a Decoder Refresh Point needs to be sent by a
received on any layer of the layered bitstream, regardless on whether media sender when a FIR is received on any layer of the layered
those layers are being sent in a single or in multiple RTP flows. bitstream, regardless on whether those layers are being sent in a
The other payload-specific feedback messages defined in RFC 5104 and single or in multiple RTP flows. The other payload-specific feedback
RFC 4585 as updated by RFC 5506 have also been analyzed, and no messages defined in RFC 5104 and RFC 4585 as updated by RFC 5506 have
corresponding shortcomings have been found. also been analyzed, and no corresponding shortcomings have been
found.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 18, 2016. This Internet-Draft will expire on March 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 2 1. Introduction and Problem Statement . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Updated definition of Decoder Refresh Point . . . . . . . . . 4 3. Updated definition of Decoder Refresh Point . . . . . . . . . 4
4. Full Intra Request for Layered Codecs . . . . . . . . . . . . 4 4. Full Intra Request for Layered Codecs . . . . . . . . . . . . 5
5. Identifying the use of Layered Codecs (Informative) . . . . . 5 5. Identifying the use of Layered Codecs (Informative) . . . . . 5
6. Layered Codecs and non-FIR codec control messages 6. Layered Codecs and non-FIR codec control messages
(Informative) . . . . . . . . . . . . . . . . . . . . . . . . 6 (Informative) . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Picture Loss Indication (PLI) . . . . . . . . . . . . . . 6 6.1. Picture Loss Indication (PLI) . . . . . . . . . . . . . . 6
6.2. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . 6 6.2. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . 6
6.3. Reference Picture Selection Indication (RPSI) . . . . . . 6 6.3. Reference Picture Selection Indication (RPSI) . . . . . . 7
6.4. Temporal-Spatial Trade-off Request and Notification 6.4. Temporal-Spatial Trade-off Request and Notification
(TSTR/TSTN) . . . . . . . . . . . . . . . . . . . . . . . 7 (TSTR/TSTN) . . . . . . . . . . . . . . . . . . . . . . . 7
6.5. H.271 Video Back Channel Message (VBCM) . . . . . . . . . 7 6.5. H.271 Video Back Channel Message (VBCM) . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction and Problem Statement 1. Introduction and Problem Statement
RFC 4585 [RFC4585] and RFC 5104 [RFC5104] specify a number of Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-
payload-specific feedback messages which a media receiver can use to Based Feedback (RTP/AVPF) [RFC4585] and Codec Control Messages in the
inform a media sender of certain conditions, or make certain RTP Audio-Visual Profile with Feedback (AVPF) [RFC5104] specify a
requests. The feedback messages are being sent as RTCP receiver number of payload-specific feedback messages which a media receiver
reports, and RFC 4585 specifies timing rules that make the use of can use to inform a media sender of certain conditions, or make
those messages practical for time-sensitive codec control. certain requests. The feedback messages are being sent as RTCP
receiver reports, and RFC 4585 specifies timing rules that make the
use of those messages practical for time-sensitive codec control.
Since the time those RFCs were developed, layered codecs have gained Since the time those RFCs were developed, layered codecs have gained
in popularity and deployment. Layered codecs use multiple sub- in popularity and deployment. Layered codecs use multiple sub-
bitstreams called layers to represent the content in different bitstreams called layers to represent the content in different
fidelities. Depending on the media codec and its RTP payload format fidelities. Depending on the media codec and its RTP payload format
in use, single layers or groups of layers may be sent in their own in use, single layers or groups of layers may be sent in their own
RTP streams (in MRST or MRMT mode as defined in RFC 7656 [RFC7656]), RTP streams (in MRST or MRMT mode as defined in A Taxonomy of
or multiplexed (using media-codec specific multiplexing mechanisms) Semantics and Mechanisms for Real-Time Transport Protocol (RTP)
in a single RTP stream (SRST mode as defined in RFC 7656 [RFC7656]). Sources [RFC7656]), or multiplexed (using media-codec specific
The dependency relationship between layers forms a directed graph, multiplexing mechanisms) in a single RTP stream (SRST mode as defined
with the base layer at the root. Enhancement layers depend on the in [RFC7656]). The dependency relationship between layers forms a
base layer and potentially on other enhancement layers, and the directed graph, with the base layer at the root. Enhancement layers
target layer and all layers it depends on have to be decoded jointly depend on the base layer and potentially on other enhancement layers,
in order to re-create the uncompressed media signal at the fidelity and the target layer and all layers it depends on have to be decoded
of the target layer. jointly in order to re-create the uncompressed media signal at the
fidelity of the target layer.
Implementation experience has shown that the Full Intra Request Implementation experience has shown that the Full Intra Request
command as defined in RFC 5104 [RFC5104] is underspecified when used command as defined in [RFC5104] is underspecified when used with
with layered codecs and when more than one RTP stream is used to layered codecs and when more than one RTP stream is used to transport
transport the layers of a layered bitstream at a given fidelity. In the layers of a layered bitstream at a given fidelity. In
particular, from the RFC 5104 [RFC5104] specification language it is particular, from the [RFC5104] specification language it is not clear
not clear whether an FIR received for only a single RTP stream of whether an FIR received for only a single RTP stream of multiple RTP
multiple RTP streams covering the same layered bitstream necessarily streams covering the same layered bitstream necessarily triggers the
triggers the sending of a Decoder Refresh Point (as defined in sending of a Decoder Refresh Point (as defined in [RFC5104] section
RFC 5104 [RFC5104] section 2.2) for all layers, or only for the layer 2.2) for all layers, or only for the layer which is transported in
which is transported in the RTP stream which the FIR request is the RTP stream which the FIR request is associated with.
associated with.
This document fixes this shortcoming by: This document fixes this shortcoming by:
a. Updating the definition of the Decoder Refresh Point (as defined a. Updating the definition of the Decoder Refresh Point (as defined
in RFC 5104 [RFC5104] section 2.2) to cover layered codecs, in in [RFC5104] section 2.2) to cover layered codecs, in line with
line with the corresponding definitions used in a popular layered the corresponding definitions used in a popular layered codec
codec format, namely H.264/SVC [H.264]. Specifically, a decoder format, namely H.264/SVC [H.264]. Specifically, a decoder
refresh point, in conjunction with layered codecs, resets the refresh point, in conjunction with layered codecs, resets the
state of the whole decoder, which implies that it includes hard state of the whole decoder, which implies that it includes hard
or gradual single-layer decoder refresh for all layers; or gradual single-layer decoder refresh for all layers;
b. Requiring that, when a media sender receives a Full Intra Request b. Requiring that, when a media sender receives a Full Intra Request
over the RTCP stream associated with any of the RTP streams over over the RTCP stream associated with any of the RTP streams over
which a part of the layered bitstream is transported, to send a which a part of the layered bitstream is transported, to send a
Decoder Refresh Point; Decoder Refresh Point;
c. Require that a media receiver sends the FIR on the RTCP stream c. Require that a media receiver sends the FIR on the RTCP stream
associated with the base layer (the option of receiving FIR on associated with the base layer (the option of receiving FIR on
enhancement layer-associated RTCP stream as specified in point b) enhancement layer-associated RTCP stream as specified in point b)
above is kept for backward compatibility); and above is kept for backward compatibility); and
d. Providing guidance on how to detect that a layered codec is in d. Providing guidance on how to detect that a layered codec is in
use for which the above rules apply. use for which the above rules apply.
While, clearly, the reaction to FIR for layered codecs in RFC 5104 While, clearly, the reaction to FIR for layered codecs in [RFC5104]
[RFC5104] and companion documents is underspecified, it appears that and companion documents is underspecified, it appears that this is
this is not the case for any of the other payload-specific codec not the case for any of the other payload-specific codec control
control messages defined in any of RFC 4585 [RFC4585], RFC 5104 messages defined in any of [RFC4585], [RFC5104]. A brief summary of
[RFC5104], or RFC 5506 [RFC5506]. A brief summary of the analysis the analysis that led to this conclusion is also included in this
that led to this conclusion is also included in this document. document.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Updated definition of Decoder Refresh Point 3. Updated definition of Decoder Refresh Point
The text below updates the definition of Decoder Refresh Point in The text below updates the definition of Decoder Refresh Point in
section 2.2 of RFC 5104 [RFC5104]. section 2.2 of [RFC5104].
Decoder Refresh Point: A bit string, packetized in one or more RTP Decoder Refresh Point: A bit string, packetized in one or more RTP
packets, that completely resets the decoder to a known state. packets, that completely resets the decoder to a known state.
Examples for "hard" single layer decoder refresh points are Intra Examples for "hard" single layer decoder refresh points are Intra
pictures in H.261 [H.261], H.263 [H.263], MPEG-1 [MPEG-1], MPEG-2 pictures in H.261 [H.261], H.263 [H.263], MPEG-1 [MPEG-1], MPEG-2
[MPEG-2], and MPEG-4 [MPEG-4]; Instantaneous Decoder Refresh (IDR) [MPEG-2], and MPEG-4 [MPEG-4]; Instantaneous Decoder Refresh (IDR)
pictures in H.264 [H.264], and H.265 [H.265]; and Keyframes in VP8 pictures in H.264 [H.264], and H.265 [H.265]; and Keyframes in VP8
[RFC6386] and VP9 [I-D.grange-vp9-bitstream]. "Gradual" decoder [RFC6386] and VP9 [I-D.grange-vp9-bitstream]. "Gradual" decoder
refresh points may also be used; see for example H.264 [H.264]. refresh points may also be used; see for example H.264 [H.264].
While both "hard" and "gradual" decoder refresh points are acceptable While both "hard" and "gradual" decoder refresh points are acceptable
in the scope of this specification, in most cases the user experience in the scope of this specification, in most cases the user experience
will benefit from using a "hard" decoder refresh point. will benefit from using a "hard" decoder refresh point.
A decoder refresh point also contains all header information above A decoder refresh point also contains all header information above
the syntactical level of the picture layer (or equivalent, depending the syntactical level of the picture layer (or equivalent, depending
on the video compression standard) that is conveyed in-band. In on the video compression standard) that is conveyed in-band. In
H.264 [H.264], for example, a decoder refresh point contains [H.264], for example, a decoder refresh point contains parameter set
parameter set Network Adaptation Layer (NAL) units that generate Network Adaptation Layer (NAL) units that generate parameter sets
parameter sets necessary for the decoding of the following slice/data necessary for the decoding of the following slice/data partition NAL
partition NAL units (and that are not conveyed out of band). units (and that are not conveyed out of band).
When a layered codec is in use, the above definition (and, in When a layered codec is in use, the above definition (and, in
particular, the requirement to COMPLETELY reset the decoder to a particular, the requirement to COMPLETELY reset the decoder to a
known state) implies that the decoder refresh point includes hard or known state) implies that the decoder refresh point includes hard or
gradual single layer decoder refresh points for all layers. gradual single layer decoder refresh points for all layers.
4. Full Intra Request for Layered Codecs 4. Full Intra Request for Layered Codecs
When a media receiver or middlebox has decided to send a FIR command When a media receiver or middlebox has decided to send a FIR command
(based on the guidance provided in Section 4.3.1 of RFC 5104 (based on the guidance provided in Section 4.3.1 of [RFC5104], it
[RFC5104], it MUST do so in the RTCP stream related to the forward MUST target the RTP stream that carries the base layer of the layered
RTP stream that carries the base layer of the layered bitstream, and bitstream, and this is done by setting the Feedback Control
the Feedback Control Information (FCI, and in particular the SSRC Information (FCI, and in particular the SSRC field therein) to refer
field therein) MUST also refer to the forward RTP stream that carries to the SSRC of the forward RTP stream that carries the base layer.
the base layer.
When a Full Intra Request Command is received by the designated media When a Full Intra Request Command is received by the designated media
sender in the RTCP stream associated with any of the RTP streams in sender in the RTCP stream associated with any of the RTP streams in
which any layer of a layered bitstream are sent, the designated media which any layer of a layered bitstream are sent, the designated media
sender MUST send a Decoder Refresh Point (Section 3) as defined above sender MUST send a Decoder Refresh Point (Section 3) as defined above
at its earliest opportunity. The requirements related to congestion at its earliest opportunity. The requirements related to congestion
control on the forward RTP streams as specified in sections 3.5.1.5 control on the forward RTP streams as specified in sections 3.5.1 and
of RFC 5104 [RFC5104] apply for the RTP streams both in isolation and 5. of [RFC5104] apply for the RTP streams both in isolation and
combined. combined.
Note: the requirement to react to FIR commands associated with Note: the requirement to react to FIR commands associated with
enhancement layers is included for robustness and backward enhancement layers is included for robustness and backward
compatibility reasons. compatibility reasons.
5. Identifying the use of Layered Codecs (Informative) 5. Identifying the use of Layered Codecs (Informative)
The above modifications to RFC 5104 unambiguously define how to deal The above modifications to RFC 5104 unambiguously define how to deal
with FIR when layered bitstreams are in use. However, it is with FIR when layered bitstreams are in use. However, it is
skipping to change at page 6, line 5 skipping to change at page 6, line 11
enhancement layers, without the base layer, effectively creating enhancement layers, without the base layer, effectively creating
simulcastable sub-bitstreams in a scalable bitstream that does not simulcastable sub-bitstreams in a scalable bitstream that does not
take advantage of inter-layer prediction. In such a scenario, it is take advantage of inter-layer prediction. In such a scenario, it is
potentially (though not necessarily) unnecessary--or even counter- potentially (though not necessarily) unnecessary--or even counter-
productive--to send a decoder refresh point on all RTP streams using productive--to send a decoder refresh point on all RTP streams using
that payload format and SSRC. that payload format and SSRC.
One good indication of the likely use of layering with interlayer One good indication of the likely use of layering with interlayer
prediction is when the various RTP streams are "bound" together on prediction is when the various RTP streams are "bound" together on
the signaling level. In an SDP environment, this would be the case the signaling level. In an SDP environment, this would be the case
if they are marked as being dependent from each other using the if they are marked as being dependent from each other using The
grouping framework RFC 4588 [RFC4588] and the layer dependency Session Description Protocol (SDP) Grouping Framework [RFC5888] and
RFC 5583 [RFC5583]. the layer dependency RFC 5583 [RFC5583].
6. Layered Codecs and non-FIR codec control messages (Informative) 6. Layered Codecs and non-FIR codec control messages (Informative)
Between them, RFC 4585 [RFC4585] (as updated by RFC 5506 [RFC5506]) Between them, AVPF [RFC4585] and Codec Control Messages [RFC5104]
and RFC 5104 [RFC5104] define a total of seven Payload-specific define a total of seven Payload-specific Feedback messages. For the
Feedback messages. For the FIR command message, guidance has been FIR command message, guidance has been provided above. In this
provided above. In this section, some information is provided with section, some information is provided with respect to the remaining
respect to the remaining six codec control messages. six codec control messages.
6.1. Picture Loss Indication (PLI) 6.1. Picture Loss Indication (PLI)
PLI is defined in RFC 4585 [RFC4585] section 6.3.1. The prudent PLI is defined in section 6.3.1 of [RFC4585]. The prudent response
response to a PLI message received for an enhancement layer is to to a PLI message received for an enhancement layer is to "repair"
"repair" (through whatever source-coding specific means) that (through whatever source-coding specific means) that enhancement
enhancement layer and all dependent enhancement layers, but not the layer and all dependent enhancement layers, but not the reference
reference layer(s) used by the enhancement layer for which the PLI layer(s) used by the enhancement layer for which the PLI was
was received. The encoder can figure out by itself what constitutes received. The encoder can figure out by itself what constitutes a
a dependent enhancement layer and does not need help from the system dependent enhancement layer and does not need help from the system
stack in doing so. Insofar, there is nothing that needs to be stack in doing so. Insofar, there is nothing that needs to be
specified herein. specified herein.
6.2. Slice Loss Indication (SLI) 6.2. Slice Loss Indication (SLI)
SLI is defined in RFC 4585 [RFC4585] section 6.3.2. The authors' SLI is defined in section 6.3.2 of [RFC4585]. The authors' current
current understanding is that the prudent response to a SLI message understanding is that the prudent response to a SLI message received
received for an enhancement layer is to "repair" (through whatever for an enhancement layer is to "repair" (through whatever source-
source-coding specific means) the affected spatial area of that coding specific means) the affected spatial area of that enhancement
enhancement layer and all dependent enhancement layers, but not the layer and all dependent enhancement layers, but not the reference
reference layers used by the enhancement layer for which the SLI was layers used by the enhancement layer for which the SLI was received.
received. The encoder can figure out by itself what constitutes a The encoder can figure out by itself what constitutes a dependent
dependent enhancement layer and does not need help from the system enhancement layer and does not need help from the system stack in
stack in doing so. Insofar, there is nothing that needs to be doing so. Insofar, there is nothing that needs to be specified
specified herein. SLI has seen very little implementation and, as herein. SLI has seen very little implementation and, as far as it is
far as it is known, none in conjunction with layered systems. known, none in conjunction with layered systems.
6.3. Reference Picture Selection Indication (RPSI) 6.3. Reference Picture Selection Indication (RPSI)
RPSI is defined in RFC 4585 [RFC4585] section 6.3.3. While a RPSI is defined in section 6.3.3 of [RFC4585]. While a technical
technical equivalent of RPSI has been in use with non-layered systems equivalent of RPSI has been in use with non-layered systems for many
for many years, no implementations are known in conjunction of years, no implementations are known in conjunction of layered codecs.
layered codecs. The authors' current understanding is that the The authors' current understanding is that the reception of an RPSI
reception of an RPSI message on any layer forces the encoder to message on any layer indicating a missing reference picture forces
"repair" the bitstream on that layer and all dependent layers without the encoder to appropriately handle that missing reference picture in
the need of any system-provided guidance. Insofar, RPSI should work the layer indicated, and all dependent layers. Insofar, RPSI should
without further need for specification language. work without further need for specification language.
6.4. Temporal-Spatial Trade-off Request and Notification (TSTR/TSTN) 6.4. Temporal-Spatial Trade-off Request and Notification (TSTR/TSTN)
TSTN/TSTR are defined in RFC 5104 [RFC5104] section 4.3.2 and 4.3.3, TSTN/TSTR are defined in section 4.3.2 and 4.3.3 of [RFC5104],
respectively. The TSTR request allows to communicate (typically respectively. The TSTR request allows to communicate (typically
user-interface-obtained) guidance of the preferred trade-off between user-interface-obtained) guidance of the preferred trade-off between
spatial quality and frame rate. A technical equivalent of TSTN/TSTR spatial quality and frame rate. A technical equivalent of TSTN/TSTR
has seen deployment for many years in non-scalable systems. has seen deployment for many years in non-scalable systems.
The Temporal-Spatial Trade-off request and notification messages The Temporal-Spatial Trade-off request and notification messages
include an SSRC target, which (similarly to FIR) may refer to an RTP include an SSRC target, which (similarly to FIR) may refer to an RTP
stream carrying a base layer, an enhancement layer, or multiple stream carrying a base layer, an enhancement layer, or multiple
layers. Therefore, the authors' current understanding is that the layers. Therefore, the authors' current understanding is that the
semantics of the message applies to the layers present in the semantics of the message applies to the layers present in the
skipping to change at page 7, line 38 skipping to change at page 7, line 47
option to the reception of a TSTR is to adjust the bit allocation option to the reception of a TSTR is to adjust the bit allocation
within the layer(s) present in the addressed RTP stream, or to adjust within the layer(s) present in the addressed RTP stream, or to adjust
the layering structure accordingly--which can involve more than just the layering structure accordingly--which can involve more than just
the addressed RTP stream. the addressed RTP stream.
Until there is a sufficient critical mass of implementation practice, Until there is a sufficient critical mass of implementation practice,
it is probably prudent for an implementer not to assume either of the it is probably prudent for an implementer not to assume either of the
two options (or any middleground that may exist between the two), be two options (or any middleground that may exist between the two), be
liberal in accepting TSTR messages, perhaps responding in TSTN liberal in accepting TSTR messages, perhaps responding in TSTN
indicating "no change," not sending TSTR messages except when indicating "no change," not sending TSTR messages except when
operating in SRST mode as defined in RFC 7656 [RFC7656], and operating in SRST mode as defined in [RFC7656], and contribute to the
contribute to the IETF documentation of any implementation IETF documentation of any implementation requirements that make per-
requirements that make per-layer TSTR/TSTN useful. layer TSTR/TSTN useful.
6.5. H.271 Video Back Channel Message (VBCM) 6.5. H.271 Video Back Channel Message (VBCM)
VBCM is defined in RFC 5104 [RFC5104] section 4.3.4. What was said VBCM is defined in section 4.3.4 of [RFC5104]. What was said above
above for RPSI (Section 6.3) applies here as well. for RPSI (Section 6.3) applies here as well.
7. Acknowledgements 7. Acknowledgements
The authors want to thank Mo Zanaty for useful discussions. The authors want to thank Mo Zanaty for useful discussions.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
The security considerations of RFC 4585 [RFC4585] (as updated by The security considerations of AVPF [RFC4585] (as updated by Support
RFC 5506 [RFC5506]) and RFC 5104 [RFC5104] apply. The clarified for Reduced-Size Real-Time Transport Control Protocol (RTCP):
response to FIR does not require any updates. Opportunities and Consequences [RFC5506]) and Codec Control Messages
[RFC5104] apply. The clarified response to FIR does not require any
updates.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 9, line 13 skipping to change at page 9, line 27
<http://handle.itu.int/11.1002/1000/12063>. <http://handle.itu.int/11.1002/1000/12063>.
[H.265] ITU-T, "ITU-T Rec. H.265: High efficiency video coding", [H.265] ITU-T, "ITU-T Rec. H.265: High efficiency video coding",
2015, <http://handle.itu.int/11.1002/1000/12455>. 2015, <http://handle.itu.int/11.1002/1000/12455>.
[I-D.grange-vp9-bitstream] [I-D.grange-vp9-bitstream]
Grange, A. and H. Alvestrand, "A VP9 Bitstream Overview", Grange, A. and H. Alvestrand, "A VP9 Bitstream Overview",
draft-grange-vp9-bitstream-00 (work in progress), February draft-grange-vp9-bitstream-00 (work in progress), February
2013. 2013.
[I-D.ietf-mmusic-rid]
Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B.,
Roach, A., and B. Campen, "RTP Payload Format
Constraints", draft-ietf-mmusic-rid-05 (work in progress),
March 2016.
[I-D.ietf-mmusic-sdp-simulcast]
Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in SDP and RTP Sessions", draft-ietf-
mmusic-sdp-simulcast-04 (work in progress), February 2016.
[MPEG-1] ISO/IEC, "ISO/IEC 11172-2:1993 Information technology -- [MPEG-1] ISO/IEC, "ISO/IEC 11172-2:1993 Information technology --
Coding of moving pictures and associated audio for digital Coding of moving pictures and associated audio for digital
storage media at up to about 1,5 Mbit/s -- Part 2: Video", storage media at up to about 1,5 Mbit/s -- Part 2: Video",
1993. 1993.
[MPEG-2] ISO/IEC, "ISO/IEC 13818-2:2013 Information technology -- [MPEG-2] ISO/IEC, "ISO/IEC 13818-2:2013 Information technology --
Generic coding of moving pictures and associated audio Generic coding of moving pictures and associated audio
information -- Part 2: Video", 2013. information -- Part 2: Video", 2013.
[MPEG-4] ISO/IEC, "ISO/IEC 14496-2:2004 Information technology -- [MPEG-4] ISO/IEC, "ISO/IEC 14496-2:2004 Information technology --
Coding of audio-visual objects -- Part 2: Visual", 2004. Coding of audio-visual objects -- Part 2: Visual", 2004.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)",
RFC 5583, DOI 10.17487/RFC5583, July 2009, RFC 5583, DOI 10.17487/RFC5583, July 2009,
<http://www.rfc-editor.org/info/rfc5583>. <http://www.rfc-editor.org/info/rfc5583>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888,
DOI 10.17487/RFC5888, June 2010,
<http://www.rfc-editor.org/info/rfc5888>.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011,
<http://www.rfc-editor.org/info/rfc6386>. <http://www.rfc-editor.org/info/rfc6386>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
for Real-Time Transport Protocol (RTP) Sources", RFC 7656, for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
DOI 10.17487/RFC7656, November 2015, DOI 10.17487/RFC7656, November 2015,
<http://www.rfc-editor.org/info/rfc7656>. <http://www.rfc-editor.org/info/rfc7656>.
skipping to change at page 11, line 6 skipping to change at page 11, line 6
Bo Burman Bo Burman
Ericsson Ericsson
Kistavagen 25 Kistavagen 25
SE - 164 80 Kista SE - 164 80 Kista
Sweden Sweden
Email: bo.burman@ericsson.com Email: bo.burman@ericsson.com
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 2
SE- 164 80 Kista SE- 164 80 Kista
Sweden Sweden
Phone: +46107148287 Phone: +46107148287
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 31 change blocks. 
125 lines changed or deleted 118 lines changed or added

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