Internet Engineering Task Force (IETF) S. Wenger
Request for Comments: 8082 J. Lennox
Updates: 5104 Vidyo, Inc.
Category: Standards Track B. Burman
ISSN: 2070-1721 M. Westerlund
Ericsson
March 2017
Internet Engineering Task Force (IETF) S. Wenger
Request for Comments: 8082 J. Lennox
Updates: 5104 Vidyo, Inc.
Category: Standards Track B. Burman
ISSN: 2070-1721 M. Westerlund
Ericsson
March 2017
Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs
在RTP视听配置文件中使用编解码器控制消息，并使用分层编解码器进行反馈
Abstract
摘要
This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered 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 bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found.
本文档通过修复编解码器控制消息完整内部请求（FIR）描述的规范语言在与分层编解码器一起使用时的一个缺陷来更新RFC 5104。特别地，当在分层比特流的任何层上接收到FIR时，解码器刷新点需要由媒体发送器发送，而不管这些层是在单个RTP流中发送还是在多个RTP流中发送。还分析了RFC 5104和RFC 4585（由RFC 5506更新）中定义的其他有效负载特定反馈消息，未发现相应的缺陷。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8082.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8082.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Problem Statement . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Updated Definition of Decoder Refresh Point . . . . . . . . . 4
4. Full Intra Request for Layered Codecs . . . . . . . . . . . . 5
5. Identifying the Use of Layered Bitstreams (Informative) . . . 6
6. Layered Codecs and Non-FIR Codec Control Messages
(Informative) . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Picture Loss Indication (PLI) . . . . . . . . . . . . . . 7
6.2. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . 7
6.3. Reference Picture Selection Indication (RPSI) . . . . . . 7
6.4. Temporal-Spatial Trade-Off Request and Notification
(TSTR/TSTN) . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. H.271 Video Back Channel Message (VBCM) . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction and Problem Statement . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Updated Definition of Decoder Refresh Point . . . . . . . . . 4
4. Full Intra Request for Layered Codecs . . . . . . . . . . . . 5
5. Identifying the Use of Layered Bitstreams (Informative) . . . 6
6. Layered Codecs and Non-FIR Codec Control Messages
(Informative) . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Picture Loss Indication (PLI) . . . . . . . . . . . . . . 7
6.2. Slice Loss Indication (SLI) . . . . . . . . . . . . . . . 7
6.3. Reference Picture Selection Indication (RPSI) . . . . . . 7
6.4. Temporal-Spatial Trade-Off Request and Notification
(TSTR/TSTN) . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. H.271 Video Back Channel Message (VBCM) . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
The "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] and "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)" [RFC5104] specify a number of payload-specific feedback messages that a media receiver can use to inform a media sender of certain conditions or to make 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.
“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”[RFC4585]和“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”[RFC5104]指定一系列特定于有效负载的反馈消息，媒体接收者可以使用这些消息通知媒体发送者某些情况或发出某些请求。反馈消息将作为RTCP接收器报告发送，RFC 4585指定了使这些消息的使用实用于时间敏感编解码器控制的定时规则。
Since the time those RFCs were developed, layered codecs have gained in popularity and deployment. Layered codecs use multiple sub-bitstreams called "layers" to represent the content in different fidelities. Depending on the media codec and its RTP payload format in use, a number of options exist on how to transport those layers in RTP. Summarizing "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" [RFC7656]):
自从这些RFC被开发以来，分层编解码器已经得到了普及和部署。分层编解码器使用称为“层”的多个子比特流以不同的保真度表示内容。根据所使用的媒体编解码器及其RTP有效负载格式，在如何在RTP中传输这些层上存在许多选项。总结“实时传输协议（RTP）源的语义和机制分类法”[RFC7656]：
single layers or groups of layers may be sent in their own RTP streams in Multiple RTP streams on a Single media Transport (MRST) or Multiple RTP streams on Multiple media Transports (MRMT) mode;
单层或层组可在单个媒体传输（MRST）模式下的多个RTP流中以其自身的RTP流发送，或在多个媒体传输（MRMT）模式下以多个RTP流发送；
using media-codec specific multiplexing mechanisms, multiple layers may be sent in a single RTP stream in Single RTP stream on a Single media Transport (SRST) mode.
使用特定于媒体编解码器的多路复用机制，可以在单一媒体传输（SRST）模式下在单个RTP流中以单个RTP流发送多个层。
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 recreate 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.
在真正分层的金字塔形比特流中，层之间的依赖关系形成一个有向图，底层位于根。增强层依赖于基础层，并且可能依赖于其他增强层，并且必须联合解码目标层及其所依赖的所有层，以便以目标层的保真度重新创建未压缩的媒体信号。此后，假定存在这样的分层结构；有关更多奇特的分层结构，请参见第5节。
Implementation experience has shown that the Full Intra Request (FIR) command as defined in [RFC5104] is underspecified when used with layered codecs and when more than one RTP stream is used to transport the layers of a layered bitstream at a given fidelity. In particular, from the [RFC5104] specification language, it is not clear whether a FIR received for only a single RTP stream of multiple RTP streams covering the same layered bitstream necessarily triggers the sending of a decoder refresh point (as defined in [RFC5104], Section 2.2) for all layers, or only for the layer that is transported in the RTP stream that the FIR request is associated with.
实施经验表明，[RFC5104]中定义的完整帧内请求（FIR）命令在与分层编解码器一起使用时，以及在使用多个RTP流以给定保真度传输分层比特流的层时，未被指定。特别地，从[RFC5104]规范语言来看，不清楚仅针对覆盖相同分层比特流的多个RTP流的单个RTP流接收的FIR是否必然触发所有层的解码器刷新点的发送（如[RFC5104]第2.2节所定义），或者仅针对与FIR请求相关联的RTP流中传输的层。
This document fixes this shortcoming by:
本文档通过以下方式修复了此缺陷：
a. Updating the definition of the decoder refresh point (as defined in [RFC5104], Section 2.2) to cover layered codecs, in line with the corresponding definitions used in a popular layered codec format, namely H.264/SVC (Scalable Video Coding) [H.264]. Specifically, a decoder refresh point, in conjunction with layered codecs, resets the state of the whole decoder, which implies that it includes hard or gradual single-layer decoder refresh for all layers;
a. 根据流行的分层编解码器格式（即H.264/SVC（可伸缩视频编码）[H.264]中使用的相应定义，更新解码器刷新点的定义（如[RFC5104]第2.2节中的定义）以覆盖分层编解码器。具体地说，解码器刷新点与分层编解码器一起重置整个解码器的状态，这意味着它包括所有层的硬的或渐进的单层解码器刷新；
b. Requiring a media sender to send a decoder refresh point after the media sender has received a FIR over an RTCP stream associated with any of the RTP streams over which a part of the layered bitstream is transported;
b. 要求媒体发送方在媒体发送方已经通过与传输分层比特流的一部分的任何RTP流相关联的RTP流接收到FIR之后发送解码器刷新点；
c. Requiring that a media receiver send the FIR on the RTCP stream associated with the base layer. The option of receiving FIR on the enhancement-layer-associated RTCP stream as specified in point b) above is kept for backward compatibility; and
c. 要求媒体接收器在与基本层相关联的RTCP流上发送FIR。为了向后兼容，保留在上述b）点中规定的增强层相关RTCP流上接收FIR的选项；和
d. Providing guidance on how to detect that a layered bitstream is in use for which the above rules apply.
d. 提供如何检测上述规则适用的分层比特流的指导。
While, clearly, the reaction to FIR for layered codecs in [RFC5104] and the companion documents is underspecified, it appears that this is not the case for any of the other payload-specific codec control messages defined in [RFC4585] and [RFC5104]. A brief summary of the analysis that led to this conclusion is also included in this document.
显然，[RFC5104]和相关文档中分层编解码器对FIR的反应没有明确规定，但[RFC4585]和[RFC5104]中定义的任何其他特定于有效载荷的编解码器控制消息似乎都不是这样。本文件还简要概述了导致这一结论的分析。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The remainder of this section replaces the definition of decoder refresh point in Section 2.2 of [RFC5104] in its entirety.
本节剩余部分将全部替换[RFC5104]第2.2节中解码器刷新点的定义。
Decoder Refresh Point: A bit string, packetized in one or more RTP packets, that completely resets the decoder to a known state.
解码器刷新点：一个位字符串，打包在一个或多个RTP数据包中，将解码器完全重置为已知状态。
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 [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 [RFC6386] and VP9 [VP9-BITSTREAM]. "Gradual" decoder refresh points may also be used; see, for example, H.264 [H.264]. While both "hard" and "gradual" decoder refresh points are acceptable in the scope of this specification, in most cases the user experience will benefit from using a "hard" decoder refresh point.
“硬”单层解码器刷新点的示例是H.261[H.261]、H.263[H.263]、MPEG-1[MPEG-1]、MPEG-2[MPEG-2]和MPEG-4[MPEG-4]中的帧内图片；H.264[H.264]和H.265[H.265]中的即时解码器刷新（IDR）图片；和VP8[RFC6386]和VP9[VP9-比特流]中的关键帧。也可以使用“渐进”解码器刷新点；例如，参见H.264[H.264]。虽然“硬”和“渐进”解码器刷新点在本规范的范围内都是可接受的，但在大多数情况下，用户体验将受益于使用“硬”解码器刷新点。
A decoder refresh point also contains all header information above the syntactical level of the picture layer that is conveyed in-band. In [H.264], for example, a decoder refresh point contains those parameter set Network Adaptation Layer (NAL) units that generate parameter sets necessary for the decoding of the following slice/data partition NAL units. (That is, assuming the parameter sets have not been conveyed out of band.)
解码器刷新点还包含在频带内传送的图片层的语法级别之上的所有报头信息。例如，在[H.264]中，解码器刷新点包含那些参数集网络适配层（NAL）单元，这些参数集网络适配层（NAL）单元生成解码以下片/数据分区NAL单元所需的参数集。（也就是说，假设参数集未传送到带外。）
When a layered codec is in use, the above definition -- in particular, the requirement to completely reset the decoder to a known state -- implies that the decoder refresh point includes hard or gradual single-layer decoder refresh points for all layers.
当使用分层编解码器时，上述定义——特别是将解码器完全重置为已知状态的要求——意味着解码器刷新点包括所有层的硬或渐进单层解码器刷新点。
A media receiver or middlebox may decide to send a FIR command based on the guidance provided in Section 4.3.1 of [RFC5104]. When sending the FIR command, it MUST target the RTP stream that carries the base layer of the layered bitstream, and this is done by setting the Feedback Control Information (FCI) (and, in particular, the synchronization source (SSRC) field therein) to refer to the SSRC of the forward RTP stream that carries the base layer.
媒体接收器或中间盒可根据[RFC5104]第4.3.1节提供的指南决定发送FIR命令。当发送FIR命令时，它必须以承载分层比特流的基本层的RTP流为目标，并且这是通过将反馈控制信息（FCI）（尤其是其中的同步源（SSRC）字段）设置为参考承载基本层的前向RTP流的SSRC来完成的。
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 which any layer of a layered bitstream are sent, the designated media sender MUST send a decoder refresh point (Section 3) as defined above at its earliest opportunity. The requirements related to congestion control on the forward RTP streams as specified in Sections 3.5.1 and 5 of [RFC5104] apply for the RTP streams both in isolation and combined.
当指定媒体发送方在与发送分层比特流的任何层的任何RTP流相关联的RTCP流中接收到完整的内部请求命令时，指定媒体发送方必须尽早发送上文定义的解码器刷新点（第3节）。[RFC5104]第3.5.1和5节中规定的与前向RTP流拥塞控制相关的要求适用于隔离和组合的RTP流。
Note: the requirement to react to FIR commands associated with enhancement layers is included for robustness and backward-compatibility reasons.
注：出于稳健性和向后兼容性的原因，包括对与增强层相关的FIR命令作出反应的要求。
The above modifications to RFC 5104 unambiguously define how to deal with FIR commands when layered bitstreams are in use. However, it is surprisingly difficult to identify the use of a layered bitstream. In general, it is expected that implementers know when layered bitstreams (in its commonly understood sense: with inter-layer prediction between pyramid-arranged layers) are in use and when not and can therefore implement the above updates to RFC 5104 correctly. However, there are scenarios in which layered codecs are employed creating non-pyramid-shaped bitstreams. Those scenarios may be viewed as somewhat exotic today but clearly are supported by certain video coding syntaxes, such as H.264/SVC. When blindly 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 unnecessary from a user experience viewpoint. Therefore, this informative section is included that provides the current understanding of when a layered bitstream is in use and when not.
上述对RFC 5104的修改明确定义了在使用分层比特流时如何处理FIR命令。然而，识别分层比特流的使用令人惊讶地困难。一般来说，期望实现者知道分层比特流（在其通常理解的意义上：在金字塔排列的层之间具有层间预测）何时在使用以及何时不在使用，并且因此能够正确地实现对RFC 5104的上述更新。然而，在一些场景中，使用分层编解码器创建非金字塔形比特流。这些场景在今天可能被视为有点异国情调，但显然受到某些视频编码语法（如H.264/SVC）的支持。当盲目地将上述规则应用于那些非金字塔排列的分层结构时，将导致次优的系统行为。没有任何东西会中断，并且不会出现互操作性故障，但是从用户体验的角度来看，解码器刷新点的发送或接收有时会影响用户体验，或者在比特流的某些部分上影响用户体验。因此，本信息部分提供了当前对分层比特流何时使用和何时不使用的理解。
The key observation made here is that the RTP payload format negotiated for the RTP streams, in isolation, is not necessarily an indicator for the use of a layered bitstream. Some layered codecs (including H.264/SVC) can form decodable bitstreams including only (one or more) enhancement layers, without the base layer, effectively creating simulcastable sub-bitstreams within a single scalable bitstream (as defined in the video coding standard), but without inter-layer prediction. In such a scenario, it is potentially, though not necessarily, counterproductive to send a decoder refresh point on all layers for that payload format and media source. It is beyond the scope of this document to discuss optimized reactions to FIRs received on RTP streams carrying such exotic bitstreams.
这里进行的关键观察是，为RTP流单独协商的RTP有效负载格式不一定是分层比特流的使用的指示符。一些分层编解码器（包括H.264/SVC）可以形成仅包括（一个或多个）增强层的可解码比特流，而不包括基本层，有效地在单个可伸缩比特流（如视频编码标准中定义的）内创建可模拟的子比特流，但没有层间预测。在这种情况下，在所有层上为该有效负载格式和媒体源发送解码器刷新点可能（但不一定）会产生反效果。讨论对在承载此类奇异比特流的RTP流上接收到的FIR的优化反应超出了本文档的范围。
One good indication of the likely use of pyramid-shaped layering with inter-layer prediction is when the various RTP streams are "bound" together on the signaling level. In an SDP environment, this would be the case if they are marked as being dependent on each other using "The Session Description Protocol (SDP) Grouping Framework" [RFC5888] and layer dependency [RFC5583].
当各种RTP流在信令级别上“绑定”在一起时，一个很好的迹象表明可能使用金字塔形分层和层间预测。在SDP环境中，如果使用“会话描述协议（SDP）分组框架”[RFC5888]和层依赖性[RFC5583]将它们标记为相互依赖，则会出现这种情况。
Between them, AVPF [RFC4585] and Codec Control Messages [RFC5104] define a total of seven payload-specific feedback messages. For the FIR command message, guidance has been provided above. In this section, some information is provided with respect to the remaining six codec control messages.
在它们之间，AVPF[RFC4585]和编解码器控制消息[RFC5104]定义了总共七条特定于有效负载的反馈消息。对于FIR命令信息，已在上面提供了指导。在本节中，将提供有关其余六条编解码器控制消息的一些信息。
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" that enhancement layer and all dependent enhancement layers through appropriate source-coding-specific means. However, the reference layer or layers used by the enhancement layer for which the PLI was received do not require repair. The encoder can figure out by itself what constitutes a dependent enhancement layer and does not need help from the system stack in doing so. Thus, there is nothing that needs to be specified herein.
PLI的定义见[RFC4585]第6.3.1节。对为增强层接收的PLI消息的谨慎响应是通过适当的源编码特定手段“修复”该增强层和所有相关增强层。然而，接收到PLI的增强层所使用的一个或多个参考层不需要修复。编码器可以自行确定什么构成依赖增强层，并且不需要系统堆栈的帮助。因此，这里不需要指定任何内容。
SLI is defined in Section 6.3.2 of [RFC4585]. The current understanding is that the prudent response to an SLI message received for an enhancement layer is to "repair" the affected spatial area of that enhancement layer and all dependent enhancement layers through appropriate source-coding-specific means. As in PLI, the reference layers used by the enhancement layer for which the SLI was received do not need to be repaired. Again, as in PLI, the encoder can determine by itself what constitutes a dependent enhancement layer and does not need help from the system stack in doing so. Thus, there is nothing that needs to be specified herein. SLI has seen very little implementation and, as far as it is known, none in conjunction with layered systems.
SLI的定义见[RFC4585]第6.3.2节。目前的理解是，对为增强层接收的SLI消息的谨慎响应是通过适当的源编码特定手段“修复”该增强层和所有相关增强层的受影响空间区域。与PLI中一样，接收SLI的增强层使用的参考层不需要修复。同样，在PLI中，编码器可以自行确定什么构成依赖增强层，而不需要系统堆栈的帮助。因此，这里不需要指定任何内容。SLI的实现非常少，就目前所知，没有一个与分层系统结合使用。
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 years, no implementations are known in conjunction of layered codecs. The current understanding is that the reception of an RPSI message on any layer indicating a missing reference picture forces the encoder to appropriately handle that missing reference picture in the layer indicated, and in all dependent layers. Thus, RPSI should work without further need for specification language.
[RFC4585]第6.3.3节对RPSI进行了定义。虽然RPSI的技术等价物已经在非分层系统中使用了很多年，但目前还不知道与分层编解码器结合使用的实现。当前理解是，在指示丢失的参考图片的任何层上接收RPSI消息迫使编码器在所指示的层和所有从属层中适当地处理该丢失的参考图片。因此，RPSI应该在不进一步需要规范语言的情况下工作。
TSTR/TSTN are defined in Sections 4.3.2 and 4.3.3 of [RFC5104], respectively. The TSTR request communicates guidance of the preferred trade-off between spatial quality and frame rate. A technical equivalent of TSTR/TSTN has seen deployment for many years in non-scalable systems.
TSTR/TSTN分别在[RFC5104]第4.3.2节和第4.3.3节中定义。TSTR请求传达空间质量和帧速率之间最佳权衡的指导。TSTR/TSTN的技术等价物已在非可扩展系统中部署多年。
TSTR and TSTN messages include an SSRC target, which, similarly to FIR, may refer to an RTP stream carrying a base layer, an enhancement layer, or multiple layers. Therefore, the current understanding is that the semantics of the message applies to the layers present in the targeted RTP stream.
TSTR和TSTN消息包括SSRC目标，其类似于FIR，可指承载基本层、增强层或多层的RTP流。因此，当前的理解是消息的语义适用于目标RTP流中存在的层。
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 sufficiently complex layered bitstream layout, a sending system has flexibility in adjusting the spatio/temporal quality balance by adding and removing temporal, spatial, or quality enhancement layers. At present, it is unclear whether an allowed (or even recommended) 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 the layering structure accordingly -- which can involve more than just the addressed RTP stream.
需要注意的是，在使用分层编解码器的系统中，每层TSTR/TSTN是一种在某些方面起反作用的机制。给定足够复杂的分层比特流布局，发送系统可以通过添加和移除时间、空间或质量增强层来灵活地调整空间/时间质量平衡。目前，尚不清楚TSTR接收的允许（甚至建议）选项是调整寻址RTP流中存在的层内的比特分配还是相应地调整分层结构，这可能不仅仅涉及寻址RTP流。
Until there is a sufficient critical mass of implementation practice, it is probably prudent for an implementer not to assume either of the two options or any middle ground that may exist between the two. Instead, it is suggested that an implementation be liberal in accepting TSTR messages and upon receipt, responding in TSTN indicating "no change". Further, it is suggested that new implementations do not send TSTR messages except when operating in 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.
在实现实践达到足够的临界质量之前，对于实现者来说，最好不要假设这两个选项中的任何一个或两者之间可能存在的任何中间立场。相反，建议实现在接受TSTR消息和收到后，在TSTN中响应“无更改”时应自由。此外，建议新实现不发送TSTR消息，除非在[RFC7656]中定义的SRST模式下运行。最后，鼓励实施者为IETF文档提供使每层TSTR/TSTN有用的任何实施需求。
VBCM is defined in Section 4.3.4 of [RFC5104]. What was said above for RPSI (Section 6.3) applies here as well.
[RFC5104]第4.3.4节对VBCM进行了定义。上述关于RPSI的内容（第6.3节）也适用于此处。
This memo includes no request to IANA.
本备忘录不包括对IANA的请求。
The security considerations of AVPF [RFC4585] (as updated by "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences" [RFC5506]) and Codec Control Messages [RFC5104] apply. The clarified response to FIR does not introduce additional security considerations.
AVPF[RFC4585]（由“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”[RFC5506]更新）和编解码器控制消息[RFC5104]的安全注意事项适用。对FIR的明确响应没有引入额外的安全考虑。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，DOI 10.17487/RFC5104，2008年2月<http://www.rfc-editor.org/info/rfc5104>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5506]Johansson，I.和M.Westerlund，“支持缩小尺寸实时传输控制协议（RTCP）：机会和后果”，RFC 5506，DOI 10.17487/RFC5506，2009年4月<http://www.rfc-editor.org/info/rfc5506>.
[H.261] ITU-T, "Video codec for audiovisual services at p x 64 kbit/s", ITU-T Recommendation H.261, March 1993, <http://handle.itu.int/11.1002/1000/1088>.
[H.261]ITU-T，“用于p x 64 kbit/s视听服务的视频编解码器”，ITU-T建议H.261，1993年3月<http://handle.itu.int/11.1002/1000/1088>.
[H.263] ITU-T, "Video coding for low bit rate communication", ITU-T Recommendation H.263, January 2005, <http://handle.itu.int/11.1002/1000/7497>.
[H.263]ITU-T，“低比特率通信的视频编码”，ITU-T建议H.263，2005年1月<http://handle.itu.int/11.1002/1000/7497>.
[H.264] ITU-T, "Advanced video coding for generic audiovisual services", ITU-T Recommendation H.264, Version 11, October 2016, <http://handle.itu.int/11.1002/1000/12904>.
[H.264]ITU-T，“通用视听服务的高级视频编码”，ITU-T建议H.264，版本11，2016年10月<http://handle.itu.int/11.1002/1000/12904>.
[H.265] ITU-T, "High efficiency video coding", ITU-T Recommendation H.265, Version 4, December 2016, <http://handle.itu.int/11.1002/1000/12905>.
[H.265]ITU-T，“高效视频编码”，ITU-T建议H.265，第4版，2016年12月<http://handle.itu.int/11.1002/1000/12905>.
[MPEG-1] ISO/IEC, "Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 2: Video", ISO/ IEC 11172-2:1993, August 1993.
[MPEG-1]ISO/IEC，“信息技术——高达1.5 Mbit/s的数字存储媒体的运动图像和相关音频编码——第2部分：视频”，ISO/IEC 11172-2:1993，1993年8月。
[MPEG-2] ISO/IEC, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 2: Video", ISO/IEC 13818-2:2013, October 2013.
[MPEG-2]ISO/IEC，“信息技术——运动图像和相关音频信息的通用编码——第2部分：视频”，ISO/IEC 13818-2:2013，2013年10月。
[MPEG-4] ISO/IEC, "Information technology -- Coding of audio-visual objects -- Part 2: Visual", ISO/IEC 14496-2:2004, June 2004.
[MPEG-4]ISO/IEC，“信息技术——视听对象的编码——第2部分：视觉”，ISO/IEC 14496-2:2004，2004年6月。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.
[RFC5583]Schierl，T.和S.Wenger，“会话描述协议（SDP）中的信令媒体解码依赖性”，RFC 5583，DOI 10.17487/RFC5583，2009年7月<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>.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，DOI 10.17487/RFC5888，2010年6月<http://www.rfc-editor.org/info/rfc5888>.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, <http://www.rfc-editor.org/info/rfc6386>.
[RFC6386]Bankoski，J.，Koleszar，J.，Quillio，L.，Salonen，J.，Wilkins，P.，和Y.Xu，“VP8数据格式和解码指南”，RFC 6386，DOI 10.17487/RFC6386，2011年11月<http://www.rfc-editor.org/info/rfc6386>.
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.
[RFC7656]Lennox，J.，Gross，K.，Nandakumar，S.，Salgueiro，G.，和B.Burman，Ed.，“实时传输协议（RTP）源的语义和机制分类”，RFC 7656，DOI 10.17487/RFC7656，2015年11月<http://www.rfc-editor.org/info/rfc7656>.
[VP9-BITSTREAM] Grange, A., de Rivaz, P., and J. Hunt, "VP9 Bitstream & Decoding Process Specification", Version 0.6, March 2016, <https://storage.googleapis.com/downloads.webmproject.org/ docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf>.
[VP9-BITSTREAM]Grange，A.，de Rivaz，P.，和J.Hunt，“VP9比特流和解码过程规范”，版本0.6，2016年3月<https://storage.googleapis.com/downloads.webmproject.org/ docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf>。
Acknowledgements
致谢
The authors want to thank Mo Zanaty for useful discussions.
作者要感谢Mo Zanaty的有益讨论。
Authors' Addresses
作者地址
Stephan Wenger Vidyo, Inc.
斯蒂芬·温格·维迪奥公司。
Email: stewe@stewe.org
Email: stewe@stewe.org
Jonathan Lennox Vidyo, Inc.
乔纳森·伦诺克斯·维迪奥公司。
Email: jonathan@vidyo.com
Email: jonathan@vidyo.com
Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden
博伯曼爱立信基斯塔瓦根25东南-164 80瑞典基斯塔
Email: bo.burman@ericsson.com
Email: bo.burman@ericsson.com
Magnus Westerlund Ericsson Farogatan 2 SE - 164 80 Kista Sweden
Magnus Westerlund Ericsson Farogatan 2 SE-164 80基斯塔瑞典
Phone: +46107148287
Email: magnus.westerlund@ericsson.com
Phone: +46107148287
Email: magnus.westerlund@ericsson.com