draft-ietf-avtext-avpf-ccm-layered-02.txt   draft-ietf-avtext-avpf-ccm-layered-03.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: March 26, 2017 M. Westerlund Expires: May 21, 2017 M. Westerlund
Ericsson Ericsson
September 22, 2016 November 17, 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-02 draft-ietf-avtext-avpf-ccm-layered-03
Abstract Abstract
This document updates RFC5104 by fixing a shortcoming in the This document updates RFC5104 by fixing a shortcoming in the
specification language of the Codec Control Message Full Intra specification language of the Codec Control Message Full Intra
Request (FIR) as defined in RFC5104 when using it with layered Request (FIR) as defined in RFC5104 when using it with layered
codecs. In particular, a Decoder Refresh Point needs to be sent by a codecs. In particular, a Decoder Refresh Point needs to be sent by a
media sender when a FIR is received on any layer of the layered media sender when a FIR is received on any layer of the layered
bitstream, regardless on whether those layers are being sent in a bitstream, regardless on whether those layers are being sent in a
single or in multiple RTP flows. The other payload-specific feedback single or in multiple RTP flows. The other payload-specific feedback
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 March 26, 2017. This Internet-Draft will expire on May 21, 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 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . 5 4. Full Intra Request for Layered Codecs . . . . . . . . . . . . 5
5. Identifying the use of Layered Codecs (Informative) . . . . . 5 5. Identifying the use of layered bitstreams (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) . . . . . . 7 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) . . . . . . . . . 8 6.5. H.271 Video Back Channel Message (VBCM) . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9 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
Extended RTP Profile for Real-time Transport Control Protocol (RTCP)- The Extended RTP Profile for Real-time Transport Control Protocol
Based Feedback (RTP/AVPF) [RFC4585] and Codec Control Messages in the (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] and Codec Control Messages
RTP Audio-Visual Profile with Feedback (AVPF) [RFC5104] specify a in the RTP Audio-Visual Profile with Feedback (AVPF) [RFC5104]
number of payload-specific feedback messages which a media receiver specify a number of payload-specific feedback messages which a media
can use to inform a media sender of certain conditions, or make receiver can use to inform a media sender of certain conditions, or
certain requests. The feedback messages are being sent as RTCP make certain requests. The feedback messages are being sent as RTCP
receiver reports, and RFC 4585 specifies timing rules that make the receiver reports, and RFC 4585 specifies timing rules that make the
use of those messages practical for time-sensitive codec control. 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, a number of options exist how to transport those layers in
RTP streams (in MRST or MRMT mode as defined in A Taxonomy of RTP. With reference to A Taxonomy of Semantics and Mechanisms for
Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Real-Time Transport Protocol (RTP) Sources [RFC7656]):
Sources [RFC7656]), or multiplexed (using media-codec specific
multiplexing mechanisms) in a single RTP stream (SRST mode as defined single layers or groups of layers may be sent in their own RTP
in [RFC7656]). The dependency relationship between layers forms a streams in MRST or MRMT mode;
directed graph, with the base layer at the root. Enhancement layers
depend on the base layer and potentially on other enhancement layers, using media-codec specific multiplexing mechanisms, multiple
and the target layer and all layers it depends on have to be decoded layers may be sent in a single RTP stream in SRST mode.
jointly in order to re-create the uncompressed media signal at the
fidelity of the target layer. The dependency relationship between layers in a truly layered,
pyramid-shaped bitstream forms a directed graph, with the base layer
at the root. Enhancement layers depend on the base layer and
potentially on other enhancement layers, and the target layer and all
layers it depends on have to be decoded jointly in order to re-create
the uncompressed media signal at the fidelity of the target layer.
Such a layering structure is assumed henceforth; for more exotic
layering structures please see Section 5.
Implementation experience has shown that the Full Intra Request Implementation experience has shown that the Full Intra Request
command as defined in [RFC5104] is underspecified when used with command as defined in [RFC5104] is underspecified when used with
layered codecs and when more than one RTP stream is used to transport layered codecs and when more than one RTP stream is used to 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 [RFC5104] specification language it is not clear particular, from the [RFC5104] specification language it is not clear
whether an FIR received for only a single RTP stream of multiple RTP whether an FIR received for only a single RTP stream of multiple RTP
streams covering the same layered bitstream necessarily triggers the streams covering the same layered bitstream necessarily triggers the
sending of a Decoder Refresh Point (as defined in [RFC5104] section sending of a Decoder Refresh Point (as defined in [RFC5104] section
2.2) for all layers, or only for the layer which is transported in 2.2) for all layers, or only for the layer which is transported in
skipping to change at page 3, line 38 skipping to change at page 3, line 45
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 [RFC5104] section 2.2) to cover layered codecs, in line with in [RFC5104] section 2.2) to cover layered codecs, in line with
the corresponding definitions used in a popular layered codec the corresponding definitions used in a popular layered 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. Require a media sender to send a Decoder Refresh Point after the
over the RTCP stream associated with any of the RTP streams over media sender has received a Full Intra Request over an RTCP
which a part of the layered bitstream is transported, to send a stream associated with any of the RTP streams over which a part
Decoder Refresh Point; of the layered bitstream is transported;
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 bitstream is
use for which the above rules apply. in use for which the above rules apply.
While, clearly, the reaction to FIR for layered codecs in [RFC5104] While, clearly, the reaction to FIR for layered codecs in [RFC5104]
and companion documents is underspecified, it appears that this is and companion documents is underspecified, it appears that this is
not the case for any of the other payload-specific codec control not the case for any of the other payload-specific codec control
messages defined in any of [RFC4585], [RFC5104]. A brief summary of messages defined in any of [RFC4585], [RFC5104]. A brief summary of
the analysis that led to this conclusion is also included in this the analysis 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 remainder of this section replaces the definition of Decoder
section 2.2 of [RFC5104]. Refresh Point in section 2.2 of [RFC5104] in its entirety.
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 that is conveyed in-band.
on the video compression standard) that is conveyed in-band. In In [H.264], for example, a decoder refresh point contains those
[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. (That is assuming the parameter sets have not
units (and that are not conveyed out of band). been 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--in particular,
particular, the requirement to COMPLETELY reset the decoder to a the requirement to completely reset the decoder to a known state--
known state) implies that the decoder refresh point includes hard or implies that the decoder refresh point includes hard or gradual
gradual single layer decoder refresh points for all layers. 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 A media receiver or middlebox may decide to send a FIR command based
(based on the guidance provided in Section 4.3.1 of [RFC5104], it on the guidance provided in Section 4.3.1 of [RFC5104]. When sending
MUST target the RTP stream that carries the base layer of the layered the FIR command, it MUST target the RTP stream that carries the base
bitstream, and this is done by setting the Feedback Control layer of the layered bitstream, and this is done by setting the
Information (FCI, and in particular the SSRC field therein) to refer Feedback Control Information (FCI, and in particular the SSRC field
to the SSRC of the forward RTP stream that carries the base layer. therein) to refer to the SSRC of the forward RTP stream that carries
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 and control on the forward RTP streams as specified in sections 3.5.1.
5. of [RFC5104] apply for the RTP streams both in isolation and 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 bitstreams (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
surprisingly difficult to identify this situation. In general, it is surprisingly difficult to identify the use of a layered bitstream.
expected that implementers know when layered coding (in its commonly In general, it is expected that implementers know when layered
understood sense: with inter-layer prediction between pyramided- bitstreams (in its commonly understood sense: with inter-layer
arranged layers) is in use and when not, and can therefore implement prediction between pyramided-arranged layers) are in use and when
the above updates to RFC 5104 correctly. However, there are use not, and can therefore implement the above updates to RFC 5104
cases of the use of layered codecs that may be viewed as somewhat correctly. However, there are scenarios in which layered codecs are
exotic today but clearly are supported by the video coding syntax, in employed creating non-pyramid shaped bitstreams. Those scenarios may
which the above rules would lead to suboptimal system behavior. be viewed as somewhat exotic today but clearly are supported by
Nothing would break, and there would not be an interop failure, but certain video coding syntaxes, such as H.264/SVC. When blindly
the user experience may suffer through the sending or receiving of applying the above rules to those non-pyramid-arranged layering
structures, suboptimal system behavior would result. Nothing would
break, and there would not be an interoperability failure, but the
user experience may suffer through the sending or receiving of
Decoder Refresh Points at times or on parts of the bitstream that are Decoder Refresh Points at times or on parts of the bitstream that are
unnecessary from a user experience viewpoint. Therefore, this unnecessary from a user experience viewpoint. Therefore, this
informative section is included that provides the current informative section is included that provides the current
understanding of when a layered codec is in use and when not. understanding of when a layered bitstream is in use and when not.
The key observation made here is that the RTP payload format The key observation made here is that the RTP payload format
negotiated for the RTP streams, in isolation, is not necessarily an negotiated for the RTP streams, in isolation, is not necessarily an
indicator for the use of layering. Some layered codecs (including indicator for the use of a layered bitstream. Some layered codecs
H.264/SVC) can form decodable bitstreams including only (one or more) (including H.264/SVC) can form decodable bitstreams including only
enhancement layers, without the base layer, effectively creating (one or more) enhancement layers, without the base layer, effectively
simulcastable sub-bitstreams in a scalable bitstream that does not creating simulcastable sub-bitstreams within a single scalable
take advantage of inter-layer prediction. In such a scenario, it is bitstream (as defined in the video coding standard), but without
potentially (though not necessarily) unnecessary--or even counter- inter-layer prediction. In such a scenario, it is potentially,
productive--to send a decoder refresh point on all RTP streams using though not necessarily, counter-productive to send a decoder refresh
that payload format and SSRC. point on all RTP streams using that payload format and SSRC. It is
beyond the scope of this document to discuss optimized reactions to
FIRs received on RTP streams carrying such exotic bitstreams.
One good indication of the likely use of layering with interlayer One good indication of the likely use of pyramid-shaped layering with
prediction is when the various RTP streams are "bound" together on interlayer prediction is when the various RTP streams are "bound"
the signaling level. In an SDP environment, this would be the case together on the signaling level. In an SDP environment, this would
if they are marked as being dependent from each other using The be the case if they are marked as being dependent from each other
Session Description Protocol (SDP) Grouping Framework [RFC5888] and using The Session Description Protocol (SDP) Grouping Framework
the layer dependency RFC 5583 [RFC5583]. [RFC5888] and 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, AVPF [RFC4585] and Codec Control Messages [RFC5104] Between them, AVPF [RFC4585] and Codec Control Messages [RFC5104]
define a total of seven Payload-specific Feedback messages. For the define a total of seven Payload-specific Feedback messages. For the
FIR command message, guidance has been provided above. In this FIR command message, guidance has been provided above. In this
section, some information is provided with respect to the remaining section, some information is provided with 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 section 6.3.1 of [RFC4585]. The prudent response PLI is defined in section 6.3.1 of [RFC4585]. The prudent response
to a PLI message received for an enhancement layer is to "repair" to a PLI message received for an enhancement layer is to "repair"
(through whatever source-coding specific means) that enhancement that enhancement layer and all dependent enhancement layers through
layer and all dependent enhancement layers, but not the reference appropriate source-coding specific means. However, the reference
layer(s) used by the enhancement layer for which the PLI was layer(s) used by the enhancement layer for which the PLI was received
received. The encoder can figure out by itself what constitutes a does not require repair. The encoder can figure out by itself what
dependent enhancement layer and does not need help from the system constitutes a dependent enhancement layer and does not need help from
stack in doing so. Insofar, there is nothing that needs to be the system stack in doing so. Thus, there is nothing that needs to
specified herein. be specified herein.
6.2. Slice Loss Indication (SLI) 6.2. Slice Loss Indication (SLI)
SLI is defined in section 6.3.2 of [RFC4585]. The authors' current SLI is defined in section 6.3.2 of [RFC4585]. The authors' current
understanding is that the prudent response to a SLI message received understanding is that the prudent response to a SLI message received
for an enhancement layer is to "repair" (through whatever source- for an enhancement layer is to "repair" the affected spatial area of
coding specific means) the affected spatial area of that enhancement that enhancement layer and all dependent enhancement layers through
layer and all dependent enhancement layers, but not the reference appropriate source-coding specific means. As in PLI, the reference
layers used by the enhancement layer for which the SLI was received. layers used by the enhancement layer for which the SLI was received
The encoder can figure out by itself what constitutes a dependent do not need to be repaired. Again, as in PLI, the encoder can
enhancement layer and does not need help from the system stack in determine by itself what constitutes a dependent enhancement layer
doing so. Insofar, there is nothing that needs to be specified and does not need help from the system stack in doing so. Thus,
herein. SLI has seen very little implementation and, as far as it is there is nothing that needs to be specified herein. SLI has seen
known, none in conjunction with layered systems. very little implementation and, as far as it is 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 section 6.3.3 of [RFC4585]. While a technical RPSI is defined in section 6.3.3 of [RFC4585]. While a technical
equivalent of RPSI has been in use with non-layered systems for many equivalent of RPSI has been in use with non-layered systems for many
years, no implementations are known in conjunction of layered codecs. years, no implementations are known in conjunction of layered codecs.
The authors' current understanding is that the reception of an RPSI The authors' current understanding is that the reception of an RPSI
message on any layer indicating a missing reference picture forces message on any layer indicating a missing reference picture forces
the encoder to appropriately handle that missing reference picture in the encoder to appropriately handle that missing reference picture in
the layer indicated, and all dependent layers. Insofar, RPSI should the layer indicated, and all dependent layers. Thus, RPSI should
work 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 section 4.3.2 and 4.3.3 of [RFC5104], 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 communicates guidance of the
user-interface-obtained) guidance of the preferred trade-off between preferred trade-off between spatial quality and frame rate. A
spatial quality and frame rate. A technical equivalent of TSTN/TSTR technical equivalent of TSTN/TSTR has seen deployment for many years
has seen deployment for many years in non-scalable systems. 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
targeted RTP stream. targeted RTP stream.
It is noted that per-layer TSTR/TSTN is a mechanism that is, in some It is noted that per-layer TSTR/TSTN is a mechanism that is, in some
ways, counterproductive in a system using layered codecs. Given a ways, counterproductive in a system using layered codecs. Given a
sufficiently complex layered bitstream layout, a sending system has sufficiently complex layered bitstream layout, a sending system has
flexibility in adjusting the spatio/temporal quality balance by flexibility in adjusting the spatio/temporal quality balance by
adding and removing temporal, spatial, or quality enhancement layers. adding and removing temporal, spatial, or quality enhancement layers.
At present it is unclear whether an allowed (or even recommended) At present it is unclear whether an allowed (or even recommended)
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.
liberal in accepting TSTR messages, perhaps responding in TSTN Instead, it is suggested that an implementation be liberal in
indicating "no change," not sending TSTR messages except when accepting TSTR messages, and upon receipt responding in TSTN
operating in SRST mode as defined in [RFC7656], and contribute to the indicating "no change". Further, it is suggested that new
IETF documentation of any implementation requirements that make per- implementations do not send TSTR messages except when operating in
layer TSTR/TSTN useful. SRST mode as defined in [RFC7656]. Finally implementers are
encouraged to contribute to the IETF documentation of any
implementation requirements that make per-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 section 4.3.4 of [RFC5104]. What was said above VBCM is defined in section 4.3.4 of [RFC5104]. What was said 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 AVPF [RFC4585] (as updated by Support The security considerations of AVPF [RFC4585] (as updated by Support
for Reduced-Size Real-Time Transport Control Protocol (RTCP): for Reduced-Size Real-Time Transport Control Protocol (RTCP):
Opportunities and Consequences [RFC5506]) and Codec Control Messages Opportunities and Consequences [RFC5506]) and Codec Control Messages
[RFC5104] apply. The clarified response to FIR does not require any [RFC5104] apply. The clarified response to FIR does not introduce
updates. additional security considerations.
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 10, line 26 skipping to change at page 10, line 31
draft-ietf-avtext-avpf-ccm-layered-00: resubmit as avtext WG draft draft-ietf-avtext-avpf-ccm-layered-00: resubmit as avtext WG draft
per IETF95 and list confirmation by Rachel 4/25/2016 per IETF95 and list confirmation by Rachel 4/25/2016
draft-ietf-avtext-avpf-ccm-layered-00: In section "Identifying the draft-ietf-avtext-avpf-ccm-layered-00: In section "Identifying the
use of Layered Codecs (Informative)", removed last sentence that use of Layered Codecs (Informative)", removed last sentence that
could be misread that the explicit signaling of simulcasting in could be misread that the explicit signaling of simulcasting in
conjunction with payload formats supporting layered coding implies no conjunction with payload formats supporting layered coding implies no
layering. layering.
draft-ietf-avtext-avpf-ccm-layered-01: clarifications in section 5.
draft-ietf-avtext-avpf-ccm-layered-02: addressing WGLC comments,
mostly editorial; see reflector discussions 09/2016
draft-ietf-avtext-avpf-ccm-layered-03: addressing AD writeup
comments, editorial
Authors' Addresses Authors' Addresses
Stephan Wenger Stephan Wenger
Vidyo, Inc. Vidyo, Inc.
Email: stewe@stewe.org Email: stewe@stewe.org
Jonathan Lennox Jonathan Lennox
Vidyo, Inc. Vidyo, Inc.
 End of changes. 29 change blocks. 
106 lines changed or deleted 130 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/