RFC 8082 - Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8082
タイトル : RFC 8082 - 階層化されたコーデックによるフィードバックを伴うRTPオーディオビジュアルプロファイルでのコーデック制御メッセージの使用
翻訳編集 : 自動生成

[要約] RFC 8082は、レイヤードコーデックを使用するRTPオーディオビジュアルプロファイルでのコーデック制御メッセージの使用に関するものです。このRFCの目的は、レイヤードコーデックを使用する際にコーデック制御メッセージを効果的に利用するためのガイドラインを提供することです。

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フローで送信されているかどうかに関係なく、メディアセンダーがデコーダーリフレッシュポイントを送信する必要があります。 RFC 5104およびRFC 4585（RFC 5506によって更新された）で定義された他のペイロード固有のフィードバックメッセージも分析され、対応する欠点は見つかりませんでした。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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で入手できます。

著作権表示

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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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

1. 概要と問題の説明

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プロファイル（RTP / AVPF）」[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ストリームまたはマルチメディアトランスポート（MRMT）モードのマルチRTPストリームの独自の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]で定義されているFull Intra Request（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. デコーダーリフレッシュポイントの定義を更新し（[RFC5104]、セクション2.2で定義）、レイヤードコーデックをカバーするように、一般的なレイヤードコーデック形式、つまりH.264 / SVC（スケーラブルビデオコーディング）で使用される対応する定義に合わせて[ H.264]。具体的には、レイヤー化されたコーデックと組み合わせてデコーダーリフレッシュポイントがデコーダー全体の状態をリセットします。これは、すべてのレイヤーのハードレイヤーまたは段階的なシングルレイヤーデコーダーリフレッシュを含むことを意味します。

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ストリームのいずれかに関連付けられたRTCPストリームで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]で定義されている他のペイロード固有のコーデック制御メッセージには当てはまらないようです。。この結論に至った分析の簡単な要約もこのドキュメントに含まれています。

2. Requirements Language

2. 要件言語

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].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。

3. Updated Definition of Decoder Refresh Point

3. デコーダリフレッシュポイントの定義の更新

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.

デコーダーリフレッシュポイント：1つ以上の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-BITSTREAM]のキーフレーム。「段階的」なデコーダーの更新ポイントも使用できます。たとえば、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）ユニットが含まれています。（つまり、パラメーターセットが帯域外で伝達されていないと仮定します。）

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.

レイヤードコーデックが使用されている場合、上記の定義（特に、デコーダーを既知の状態に完全にリセットする要件）は、デコーダーリフレッシュポイントに、すべてのレイヤーのハードまたは段階的な単層デコーダーリフレッシュポイントが含まれることを意味します。

4. Full Intra Request for Layered Codecs

4. 階層化コーデックの完全なイントラリクエスト

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コマンドに対応する要件が含まれています。

5. Identifying the Use of Layered Bitstreams (Informative)

5. 階層化ビットストリームの使用の識別（参考情報）

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を含む）は、ベースレイヤーなしで（1つ以上の）拡張レイヤーのみを含むデコード可能なビットストリームを形成でき、単一のスケーラブルなビットストリーム内に同時配信可能なサブビットストリームを効果的に作成します（ビデオコーディング標準で定義）、ただし層間予測はありません。そのようなシナリオでは、必ずしもではないが、そのペイロード形式とメディアソースのすべてのレイヤーでデコーダーリフレッシュポイントを送信することは、逆効果になる可能性があります。このようなエキゾチックなビットストリームを運ぶ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].

レイヤ間予測でピラミッド型のレイヤリングが使用される可能性が高いことを示す1つの目安は、さまざまなRTPストリームがシグナリングレベルで「結合」されている場合です。 SDP環境では、「セッション記述プロトコル（SDP）グループ化フレームワーク」[RFC5888]とレイヤーの依存関係[RFC5583]を使用して、それらが相互に依存しているとマークされている場合に当てはまります。

6. Layered Codecs and Non-FIR Codec Control Messages (Informative)

6. 階層化コーデックと非FIRコーデック制御メッセージ（参考）

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]は、合計7つのペイロード固有のフィードバックメッセージを定義します。 FIRコマンドメッセージについては、上記のガイダンスが提供されています。このセクションでは、残りの6つのコーデック制御メッセージに関していくつかの情報を提供します。

6.1. Picture Loss Indication (PLI)

6.1. 画像喪失表示（PLI）

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が受信された拡張層によって使用される1つまたは複数の参照層は、修復を必要としません。エンコーダーは、それ自体が依存拡張レイヤーを構成するものを把握でき、システムスタックからの支援を必要としません。したがって、ここで指定する必要のあるものはありません。

6.2. Slice Loss Indication (SLI)

6.2. スライス損失表示（SLI）

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の実装はほとんど見られず、それが知られている限り、階層化システムと組み合わせたものはありません。

6.3. Reference Picture Selection Indication (RPSI)

6.3. 参照画像選択表示（RPSI）

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.

RPSIは[RFC4585]のセクション6.3.3で定義されています。 RPSIの技術的同等物は非レイヤードシステムで長年使用されてきましたが、レイヤードコーデックと組み合わせた実装は知られていません。現在の理解では、欠落している参照画像を示す任意の層でRPSIメッセージを受信すると、エンコーダーは、指定された層およびすべての依存層で欠落している参照画像を適切に処理します。したがって、RPSIは仕様言語を必要とせずに機能するはずです。

6.4. Temporal-Spatial Trade-Off Request and Notification (TSTR/TSTN)

6.4. 時間と空間のトレードオフのリクエストと通知（TSTR / TSTN）

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.

実装の実践が十分にクリティカルになるまでは、実装者が2つのオプションのいずれか、または2つの間に存在する可能性のある中間のいずれかを想定しないことが賢明でしょう。代わりに、TSTRメッセージを受け入れて、受信時にTSTNで「変更なし」を示すように応答することは、実装が自由であることをお勧めします。さらに、[RFC7656]で定義されているSRSTモードで動作している場合を除いて、新しい実装はTSTRメッセージを送信しないことをお勧めします。最後に、実装者は、レイヤーごとのTSTR / TSTNを有用にするあらゆる実装要件のIETFドキュメントに貢献することをお勧めします。

6.5. H.271 Video Back Channel Message (VBCM)

6.5. H.271ビデオバックチャネルメッセージ（VBCM）

VBCM is defined in Section 4.3.4 of [RFC5104]. What was said above for RPSI (Section 6.3) applies here as well.

VBCMは[RFC5104]のセクション4.3.4で定義されています。 RPSI（セクション6.3）について上記で述べたことは、ここでも当てはまります。

7. IANA Considerations

7. IANAに関する考慮事項

This memo includes no request to IANA.

このメモには、IANAへの要求は含まれていません。

8. Security Considerations

8. セキュリティに関する考慮事項

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に対する明確化された応答は、追加のセキュリティの考慮事項を導入しません。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[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プロファイル（RTP / AVPF） "、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、2月2008、<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、「Reduced-Size Real-Time Transport Control Protocol（RTCP）：Opportunities and Consequences」、RFC 5506、DOI 10.17487 / RFC5506、2009年4月、<http：// www .rfc-editor.org / info / rfc5506>。

9.2. Informative References

9.2. 参考引用

[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、「px 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、「Signaling Media Decoding Dependency in the Session Description Protocol（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.、and Y. Xu、 "VP8 Data Format and Decoding Guide"、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、編、「リアルタイムの転送プロトコル（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 Bitstream＆Decoding Process Specification」、バージョン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.

Stephan Wenger Vidyo、Inc.

   Email: stewe@stewe.org

Jonathan Lennox Vidyo, Inc.

Jonathan Lennox Vidyo、Inc.

   Email: jonathan@vidyo.com

Bo Burman Ericsson Kistavagen 25 SE - 164 80 Kista Sweden

Bo Burman Ericsson Kistavagen 25 SE-164 80 Kistaスウェーデン

   Email: bo.burman@ericsson.com

Magnus Westerlund Ericsson Farogatan 2 SE - 164 80 Kista Sweden

Magnus Westerlund Ericsson Farogatan 2 SE-164 80 Kistaスウェーデン

   Phone: +46107148287
   Email: magnus.westerlund@ericsson.com