Internet Engineering Task Force (IETF) J. Lennox
Request for Comments: 9627 8x8 / Jitsi
Category: Standards Track D. Hong
ISSN: 2070-1721 Google
J. Uberti
OpenAI
S. Holmer
M. Flodman
Google
March 2025
This memo describes the RTCP Payload-Specific Feedback Message Layer Refresh Request (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. This document also defines its use with several RTP payloads for scalable media formats.
このメモでは、RTCPペイロード固有のフィードバックメッセージレイヤー更新リクエスト（LRR）について説明します。これは、階層化されたメディアストリームの1つ以上のサブストリームの状態リフレッシュを要求するために使用できます。このドキュメントでは、スケーラブルなメディア形式のためのいくつかのRTPペイロードでの使用も定義しています。
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 https://www.rfc-editor.org/info/rfc9627.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9627で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Terminology
2.1. Terminology
3. Layer Refresh Request
3.1. Message Format
3.2. Semantics
4. Usage with Specific Codecs
4.1. H.264 SVC
4.2. VP8
4.3. H.265
5. Usage with Different Scalability Transmission Mechanisms
6. SDP Definitions
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
This memo describes an RTCP [RFC3550] Payload-Specific Feedback Message [RFC4585] "Layer Refresh Request" (LRR), which is designed to allow a receiver of a layered media stream to request that one or more of its substreams be refreshed. The stream can then be decoded by an endpoint that previously was not receiving those layers, without requiring that the entire stream be refreshed (as it would be if the receiver sent a Full Intra Request (FIR) [RFC5104]; see also [RFC8082]).
このメモでは、RTCP [RFC3550]ペイロード固有のフィードバックメッセージ[RFC4585]「レイヤーリフレッシュリクエスト」（LRR）について説明します。これは、レイヤードメディアストリームの受信者が1つ以上のサブストリームをリフレッシュするように要求するように設計されています。その後、ストリームは、ストリーム全体を更新する必要なく、以前にこれらのレイヤーを受信していなかったエンドポイントによってデコードできます（受信者が完全なリクエスト（FIR）[RFC5104]を送信した場合のように、[RFC8082]も参照）。
The feedback message is applicable to both temporally and spatially scaled streams and to both single-stream and multi-stream scalability modes.
フィードバックメッセージは、時間的および空間的にスケーリングされたストリームの両方、およびシングルストリームおよびマルチストリームスケーラビリティモードの両方に適用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
A "layer refresh point" is a point in a scalable stream after which a decoder, which previously had been able to decode only some (possibly none) of the available layers of stream, is able to decode a greater number of the layers.
「レイヤーリフレッシュポイント」は、スケーラブルなストリームのポイントであり、その後、以前に使用可能なレイヤーの一部のみ（場合によってはありません）だけのデコーダーが、より多くのレイヤーをデコードすることができました。
For spatial (or quality) layers, in normal encoding, a subpicture can depend both on earlier pictures of that spatial layer and also on lower-layer pictures of the current picture. However, a layer refresh typically requires that a spatial-layer picture be encoded in a way that references only the lower-layer subpictures of the current picture, not any earlier pictures of that spatial layer. Additionally, the encoder must promise that no earlier pictures of that spatial layer will be used as reference in the future.
空間（または品質）層の場合、通常のエンコードでは、サブピクチャは、その空間層の以前の写真と、現在の写真の低層像の両方に依存できます。ただし、レイヤーの更新では、通常、空間層の画像を、その空間層の以前の写真ではなく、現在の画像の下層サブピクチャのみを参照する方法でエンコードする必要があります。さらに、エンコーダは、その空間層の以前の写真が将来参照として使用されないことを約束する必要があります。
However, even in a layer refresh, layers other than the ones being refreshed may still maintain dependency on earlier content of the stream. This is the difference between a layer refresh and a FIR [RFC5104]. This minimizes the coding overhead of refresh to only those parts of the stream that actually need to be refreshed at any given time.
ただし、レイヤーリフレッシュであっても、リフレッシュされているレイヤー以外のレイヤーは、ストリームの以前のコンテンツへの依存性を維持する場合があります。これは、レイヤーリフレッシュとFIR [RFC5104]の違いです。これにより、リフレッシュのコーディングオーバーヘッドが、いつでもリフレッシュする必要があるストリームの部分のみに最小限に抑えられます。
The spatial-layer refresh of an enhancement layer is shown below. The "<--" indicates a coding dependency.
強化層の空間層リフレッシュを以下に示します。「< - 」はコーディング依存関係を示します。
... <-- S1 <-- S1 S1 <-- S1 <-- ...
| | | |
\/ \/ \/ \/
... <-- S0 <-- S0 <-- S0 <-- S0 <-- ...
1 2 3 4
Figure 1: Refresh of a Spatial Enhancement Layer
図1：空間強化層の更新
In Figure 1, frame 3 is a layer refresh point for spatial layer S1; a decoder that had previously only been decoding spatial layer S0 would be able to decode layer S1 starting at frame 3.
図1では、フレーム3は空間層S1のレイヤーリフレッシュポイントです。以前は空間層S0をデコードしていたデコーダーは、フレーム3からレイヤーS1をデコードできます。
The spatial-layer refresh of a base layer is shown below. The "<--" indicates a coding dependency.
ベースレイヤーの空間層リフレッシュを以下に示します。「< - 」はコーディング依存関係を示します。
... <-- S1 <-- S1 <-- S1 <-- S1 <-- ...
| | | |
\/ \/ \/ \/
... <-- S0 <-- S0 S0 <-- S0 <-- ...
1 2 3 4
Figure 2: Refresh of a Spatial Base Layer
図2：空間ベースレイヤーの更新
In Figure 2, frame 3 is a layer refresh point for spatial layer S0; a decoder that had previously not been decoding the stream at all could decode layer S0 starting at frame 3.
図2では、フレーム3は空間層S0のレイヤーリフレッシュポイントです。以前にストリームをデコードしていなかったデコーダーは、フレーム3からレイヤーS0をデコードできます。
For temporal layers, while normal encoding allows frames to depend on earlier frames of the same temporal layer, layer refresh requires that the layer be "temporally nested", i.e., use as reference only earlier frames of a lower temporal layer, not any earlier frames of this temporal layer and promise that no future frames of this temporal layer will reference frames of this temporal layer before the refresh point. In many cases, the temporal structure of the stream will mean that all frames are temporally nested; in this case, decoders will have no need to send LRR messages for the stream.
一時的な層の場合、通常のエンコードではフレームが同じ時間レイヤーの以前のフレームに依存することができますが、レイヤーの更新では、層が「時間的にネストされた」ことを要求します。多くの場合、ストリームの時間構造は、すべてのフレームが一時的にネストされていることを意味します。この場合、デコーダーはストリームにLRRメッセージを送信する必要はありません。
The temporal layer refresh is shown below. The "<--" indicates a coding dependency.
一時的な層の更新を以下に示します。「< - 」はコーディング依存関係を示します。
... <----- T1 <------ T1 T1 <------ ...
/ / /
|_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ...
1 2 3 4 5 6 7
Figure 3: Refresh of a Temporal Layer
図3：時間層の更新
In Figure 3, frame 6 is a layer refresh point for temporal layer T1; a decoder that had previously only been decoding temporal layer T0 would be able to decode layer T1 starting at frame 6.
図3では、フレーム6は、時間層T1のレイヤーリフレッシュポイントです。以前は時間層T0をデコードしていたデコーダーは、フレーム6から層T1をデコードできます。
An inherently temporally nested stream is shown below. The "<--" indicates a coding dependency.
本質的に一時的にネストされたストリームを以下に示します。「< - 」はコーディング依存関係を示します。
T1 T1 T1
/ / /
|_ |_ |_
... <-- T0 <------ T0 <------ T0 <------ T0 <--- ...
1 2 3 4 5 6 7
Figure 4: An Inherently Temporally Nested Stream
図4：本質的に一時的にネストされたストリーム
In Figure 4, the stream is temporally nested in its ordinary structure; a decoder receiving layer T0 can begin decoding layer T1 at any point.
図4では、ストリームは通常の構造に一時的にネストされています。デコーダー受信レイヤーT0は、任意の時点でレイヤーT1のデコードを開始できます。
A "layer index" is a numeric label for a specific spatial and temporal layer of a scalable stream. It consists of both a "temporal-layer ID" identifying the temporal layer and a "layer ID" identifying the spatial or quality layer. The details of how layers of a scalable stream are labeled are codec specific. Details for several codecs are defined in Section 4.
「レイヤーインデックス」は、スケーラブルなストリームの特定の空間的および時間的層の数値ラベルです。これは、時間層を識別する「時間層ID」と、空間または品質の層を識別する「レイヤーID」の両方で構成されています。スケーラブルストリームのレイヤーがどのようにラベル付けされているかの詳細は、コーデック固有です。いくつかのコーデックの詳細は、セクション4で定義されています。
A layer refresh frame can be requested by sending a Layer Refresh Request (LRR), which is an RTCP [RFC3550] payload-specific feedback message [RFC4585] asking the encoder to encode a frame that makes it possible to upgrade to a higher layer. The LRR contains one or two tuples, indicating the temporal and spatial layer the decoder wants to upgrade to and (optionally) the currently highest temporal and spatial layer the decoder can decode.
レイヤーリフレッシュフレームは、RTCP [RFC3550]ペイロード固有のフィードバックメッセージ[RFC4585]であるレイヤーリフレッシュリクエスト（LRR）を送信することで要求できます。LRRには1つまたは2つのタプルが含まれており、デコーダーがアップグレードしたい時間および空間層、および（オプションでは）デコーダーがデコードできる現在の最高および空間層を（オプションで）示します。
The specific format of the tuples, and the mechanism by which a receiver recognizes a refresh frame, is codec dependent. Usage for several codecs is discussed in Section 4.
タプルの特定の形式、およびレシーバーが更新フレームを認識するメカニズムは、コーデックに依存します。いくつかのコーデックの使用については、セクション4で説明します。
The design of LRR follows the FIR model (Section 3.5.1 of [RFC5104]) for its retransmission, reliability, and use in multipoint conferences.
LRRの設計は、その再送信、信頼性、およびマルチポイント会議での使用に対するFIRモデル（[RFC5104]のセクション3.5.1）に従います。
The LRR message is identified by RTCP packet type value PT=PSFB and FMT=10. The Feedback Control Information (FCI) field MUST contain one or more LRR entries. Each entry applies to a different media sender, identified by its Synchronization Source (SSRC).
LRRメッセージは、RTCPパケットタイプ値PT = PSFBおよびFMT = 10によって識別されます。フィードバック制御情報（FCI）フィールドには、1つ以上のLRRエントリが含まれている必要があります。各エントリは、同期ソース（SSRC）によって識別される別のメディア送信者に適用されます。
The FCI for the Layer Refresh Request consists of one or more FCI entries, the content of which is depicted in Figure 5. The length of the LRR feedback message MUST be set to 2+3*N 32-bit words, where N is the number of FCI entries.
レイヤーリフレッシュリクエストのFCIは1つ以上のFCIエントリで構成され、その内容を図5に示します。LRRフィードバックメッセージの長さは2+3*N 32ビット単語に設定する必要があります。ここで、nはFCIエントリの数です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. |C| Payload Type| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TTID| TLID | RES | CTID| CLID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Layer Refresh Request FCI Format
図5：レイヤーリフレッシュリクエストFCI形式
Synchronization Source (SSRC) (32 bits):
同期ソース（SSRC）（32ビット）：
The SSRC value of the media sender that is requested to send a layer refresh point.
レイヤーリフレッシュポイントを送信するように要求されるメディア送信者のSSRC値。
Seq nr. (8 bits):
seq nr。（8ビット）：
The command sequence number. The sequence number space is unique for each pairing of the SSRC of command source and the SSRC of the command target. The sequence number SHALL be increased by 1 for each new command (modulo 256, so the value after 255 is 0). A repetition SHALL NOT increase the sequence number. The initial value is arbitrary.
コマンドシーケンス番号。シーケンス番号スペースは、コマンドソースのSSRCとコマンドターゲットのSSRCのペアリングごとに一意です。シーケンス番号は、新しいコマンドごとに1ずつ増加する必要があります（Modulo 256、したがって255後の値は0）。繰り返しはシーケンス番号を増やしてはなりません。初期値は任意です。
C (1 bit):
C（1ビット）：
A flag bit indicating whether the Current Temporal-layer ID (CTID) and Current Layer ID (CLID) fields are present in the FCI. If this bit is 0, the sender of the LRR message is requesting refresh of all layers up to and including the target layer.
現在の時間層ID（CTID）と現在の層ID（CLID）フィールドがFCIに存在するかどうかを示すフラグビット。このビットが0の場合、LRRメッセージの送信者は、ターゲットレイヤーまでのすべてのレイヤーの更新を要求しています。
Payload Type (7 bits):
ペイロードタイプ（7ビット）：
The RTP payload type for which the LRR is being requested. This gives the context in which the target layer index is to be interpreted.
LRRが要求されているRTPペイロードタイプ。これにより、ターゲットレイヤーインデックスが解釈されるコンテキストが得られます。
Reserved (RES) (three separate fields of 16 bits / 5 bits / 5 bits):
予約（RES）（16ビット / 5ビット / 5ビットの3つの別々のフィールド）：
All bits SHALL be set to zero by the sender and SHALL be ignored on reception.
すべてのビットは、送信者によってゼロに設定され、受信時に無視されます。
Target Temporal-layer ID (TTID) (3 bits):
ターゲット時間層ID（TTID）（3ビット）：
The temporal-layer ID of the target layer for which the receiver wishes a refresh point.
受信者がリフレッシュポイントを希望するターゲット層の時間層ID。
Target Layer ID (TLID) (8 bits):
ターゲットレイヤーID（TLID）（8ビット）：
The layer ID of the target spatial or quality layer for which the receiver wishes a refresh point. Its format is dependent on the payload type field.
レシーバーがリフレッシュポイントを希望するターゲット空間または品質レイヤーのレイヤーID。その形式は、ペイロード型フィールドに依存します。
Current Temporal-layer ID (CTID) (3 bits):
現在の時間層ID（CTID）（3ビット）：
If C is 1, the ID of the current temporal layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to zero by the sender and SHALL be ignored on reception.
Cが1の場合、現在の側頭層のIDはレシーバーによってデコードされています。このメッセージは、このレイヤー以下のレイヤーの更新を要求していません。Cが0の場合、このフィールドは送信者によってゼロに設定され、受信時に無視されます。
Current Layer ID (CLID) (8 bits):
現在のレイヤーID（CLID）（8ビット）：
If C is 1, the layer ID of the current spatial or quality layer being decoded by the receiver. This message is not requesting refresh of layers at or below this layer. If C is 0, this field SHALL be set to zero by the sender and SHALL be ignored on reception.
Cが1の場合、現在の空間または品質層のレイヤーIDがレシーバーによってデコードされています。このメッセージは、このレイヤー以下のレイヤーの更新を要求していません。Cが0の場合、このフィールドは送信者によってゼロに設定され、受信時に無視されます。
When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be less than CLID; at least one of either TTID or TLID MUST be greater than CTID or CLID, respectively. That is to say, the target layer index <TTID, TLID> MUST be a layer upgrade from the current layer index <CTID, CLID>. A sender MAY request an upgrade in both temporal and spatial or quality layers simultaneously.
Cが1の場合、TTIDはCTID以下であってはなりません。TLIDはCLIDよりも小さいものであってはなりません。TTIDまたはTLIDの少なくとも1つは、それぞれCTIDまたはCLIDよりも大きくなければなりません。つまり、ターゲットレイヤーインデックス<TTID、TLID>は、現在のレイヤーインデックス<CTID、CLID>からのレイヤーアップグレードでなければなりません。送信者は、時間的および空間的または品質の両方のレイヤーのアップグレードを同時に要求できます。
A receiver receiving an LRR feedback packet that does not satisfy the requirements of the previous paragraph, i.e., one where the C bit is present but the TTID is less than the CTID or the TLID is less than the CLID, MUST discard the request.
前の段落の要件を満たさないLRRフィードバックパケット、つまりCビットが存在するが、TTIDがCTIDよりも小さい、またはTLIDがCLIDよりも少ないレシーバーは、リクエストを破棄する必要があります。
Note: The syntax of the TTID, TLID, CTID, and CLID fields match, by design, the TID and LID fields in [RFC9626].
注：[RFC9626]のTID、TLID、CTID、およびCLIDフィールドの構文は、設計、TIDおよび蓋フィールドと一致します。
Within the common packet header for feedback messages (as defined in Section 6.1 of [RFC4585]), the "SSRC of packet sender" field indicates the source of the request, and the "SSRC of media source" is not used and SHALL be set to zero. The SSRCs of the media senders to which the LRR command applies are in the corresponding FCI entries. An LRR message MAY contain requests to multiple media senders, using one FCI entry per target media sender.
フィードバックメッセージの一般的なパケットヘッダー内（[RFC4585]のセクション6.1で定義されているように）では、「パケット送信者のSSRC」フィールドはリクエストのソースを示し、「メディアソースのSSRC」は使用されず、ゼロに設定されます。LRRコマンドが適用されるメディア送信者のSSRCは、対応するFCIエントリにあります。LRRメッセージには、ターゲットメディア送信者ごとに1つのFCIエントリを使用して、複数のメディア送信者へのリクエストが含まれる場合があります。
Upon reception of an LRR, the encoder MUST send a decoder refresh point (see Section 2.1) as soon as possible.
LRRを受信すると、エンコーダはできるだけ早くデコーダーリフレッシュポイント（セクション2.1を参照）を送信する必要があります。
The sender MUST respect bandwidth limits provided by the application of congestion control, as described in Section 5 of [RFC5104]. As layer refresh points will often be larger than non-refreshing frames, this may restrict a sender's ability to send a layer refresh point quickly.
送信者は、[RFC5104]のセクション5で説明されているように、輻輳制御の適用によって提供される帯域幅の制限を尊重する必要があります。レイヤーリフレッシュポイントは、多くの場合、再洗練されていないフレームよりも大きくなるため、これにより、レイヤーリフレッシュポイントをすばやく送信する送信者の能力が制限される場合があります。
An LRR MUST NOT be sent as a reaction to picture losses due to packet loss or corruption; it is RECOMMENDED to use a PLI (Picture Loss Indication) [RFC4585] instead. An LRR SHOULD be used only in situations where there is an explicit change in a decoder's behavior: for example, when a receiver will start decoding a layer that it previously had been discarding.
LRRは、パケットの損失または腐敗による絵の損失に対する反応として送られてはなりません。代わりに、PLI（画像損失の表示）[RFC4585]を使用することをお勧めします。LRRは、デコーダーの動作に明示的な変化がある状況でのみ使用する必要があります。たとえば、レシーバーが以前に破棄していたレイヤーの解読を開始する場合。
In order for an LRR to be used with a scalable codec, the format of the temporal and layer ID fields (for both the target and current layer indices) needs to be specified for that codec's RTP packetization. New RTP packetization specifications for scalable codecs SHOULD define how this is done. (The VP9 payload [RFC9628], for instance, has done so.) If the payload also specifies how it is used with the Video Frame Marking RTP Header Extension described in [RFC9626], the syntax MUST be defined in the same manner as the TID and LID fields in that header.
スケーラブルなコーデックでLRRを使用するには、そのコーデックのRTPパケット化には、時間的および層IDフィールド（ターゲットと電流層インデックスの両方）の形式を指定する必要があります。スケーラブルなコーデック用の新しいRTPパケット化仕様は、これがどのように行われるかを定義する必要があります。（たとえば、VP9ペイロード[RFC9628]はそうしています。）ペイロードは、[RFC9626]で説明されているビデオフレームのRTPヘッダー拡張機能で使用方法を指定する場合、そのヘッダーのTIDおよびLIDフィールドと同じ方法で構文を定義する必要があります。
H.264 SVC [RFC6190] defines temporal, dependency (spatial), and quality scalability modes.
H.264 SVC [RFC6190]は、時間的、依存関係（空間）、および品質のスケーラビリティモードを定義します。
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |R| DID | QID |
+---------------+---------------+
Figure 6: H.264 SVC Layer Index Fields Format
図6：H.264 SVCレイヤーインデックスフィールド形式
Figure 6 shows the format of the layer index fields for H.264 SVC streams. The "R" and "RES" fields MUST be set to zero on transmission and ignored on reception. See Section 1.1.3 of [RFC6190] for details on the dependency_id (DID), quality_id (QID), and temporal_id (TID) fields.
図6は、H.264 SVCストリームのレイヤーインデックスフィールドの形式を示しています。「R」および「RES」フィールドは、送信時にゼロに設定し、受信で無視する必要があります。[RFC6190]のセクション1.1.3を参照して、依存関係_ID（DID）、QUALTY_ID（QID）、およびTOMEAL_ID（TID）フィールドの詳細については。
A dependency or quality layer refresh of a given layer in H.264 SVC can be identified by the I bit (idr_flag) in the extended Network Abstraction Layer (NAL) unit header, present in NAL unit types 14 (prefix NAL unit) and 20 (coded scalable slice). Layer refresh of the base layer can also be identified by its NAL unit type of its coded slices, which is "5" rather than "1". A dependency or quality layer refresh is complete once this bit has been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index.
H.264 SVCの特定のレイヤーの依存関係または品質レイヤーの更新は、拡張ネットワーク抽象化レイヤー（NAL）ユニットヘッダーのIビット（IDR_FLAG）によって識別できます。ベースレイヤーのレイヤーリフレッシュは、「1」ではなく「5」であるコード化されたスライスのNAL単位タイプによって識別することもできます。ターゲットレイヤーインデックスを介して、現在のレイヤーインデックス（もしあれば、ベースレイヤーから始まる場合、またはベースレイヤーから始まる）上のすべての適切なレイヤー（デコード順）でこのビットが見られると、依存関係または品質レイヤーの更新が完了します。
Note that as the I bit in a Payload Content Scalability Information (PACSI) header is set if the corresponding bit is set in any of the aggregated NAL units it describes; thus, it is not sufficient to identify layer refresh when NAL units of multiple dependency or quality layers are aggregated.
ペイロードコンテンツのスケーラビリティ情報（PACSI）ヘッダーのビットが設定されると、対応するビットが記述されている集約されたNALユニットのいずれかに設定されている場合に注意してください。したがって、複数の依存関係または品質レイヤーのNALユニットが集約されている場合、レイヤーリフレッシュを識別するだけでは不十分です。
In H.264 SVC, temporal layer refresh information can be determined from various Supplemental Encoding Information (SEI) messages in the bitstream.
H.264 SVCでは、BitStreamのさまざまな補足エンコード情報（SEI）メッセージから、時間層の更新情報を決定できます。
Whether an H.264 SVC stream is scalably nested can be determined from the Scalability Information SEI message's temporal_id_nesting flag. If this flag is set in a stream's currently applicable Scalability Information SEI, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point. (The Scalability Information SEI message may also be available in the signaling negotiation of H.264 SVC as the sprop-scalability-info parameter.)
H.264 SVCストリームがスケーラブルにネストされているかどうかは、SEIメッセージのThimeaL_ID_NESTINGフラグからスケーラビリティ情報から決定できます。このフラグが現在該当するストリームのスケーラビリティ情報SEIに設定されている場合、すべてのフレームは暗黙的に時間レイヤーリフレッシュポイントであるため、受信機はそのストリームの時間的LRRメッセージを送信してはなりません。（SPROPスケーラビリティINFOパラメーターとして、H.264 SVCの信号交渉でもSPALABILITY情報SEIメッセージが利用できる場合があります。）
If a stream's temporal_id_nesting flag is not set, the Temporal Level Switching Point SEI message identifies temporal layer switching points. A temporal layer refresh is satisfied when this SEI message is present in a frame with the target layer index, if the message's delta_frame_num refers to a frame with the requested current layer index. (Alternately, temporal layer refresh can also be satisfied by a complete state refresh, such as an Instantaneous Decoding Refresh (IDR).) Senders that support receiving an LRR for streams that are not temporally nested MUST insert Temporal Level Switching Point SEI messages as appropriate.
StreamのThipalal_id_nestingフラグが設定されていない場合、時間レベルの切り替えポイントSEIメッセージは、時間レイヤースイッチングポイントを識別します。メッセージのdelta_frame_numが要求された現在のレイヤーインデックスを持つフレームを参照する場合、このSEIメッセージがターゲットレイヤーインデックスのあるフレームに存在する場合、時間レイヤーの更新が満たされます。（あるいは、一時的なデコードリフレッシュ（IDR）などの完全な状態リフレッシュ（IDR）など、一時的なレイヤーの更新も満たすことができます。）一時的にネストされていないストリームのLRRを受け取ることをサポートする送信者は、必要に応じて時間レベルのスイッチングポイントSEIメッセージを挿入する必要があります。
The VP8 RTP payload format [RFC7741] defines temporal scalability modes. It does not support spatial scalability.
VP8 RTPペイロード形式[RFC7741]は、時間的スケーラビリティモードを定義します。空間スケーラビリティはサポートしません。
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID | RES |
+---------------+---------------+
Figure 7: VP8 Layer Index Field Format
図7：VP8レイヤーインデックスフィールド形式
Figure 7 shows the format of the layer index field for VP8 streams. The "RES" fields MUST be set to zero on transmission and be ignored on reception. See Section 4.2 of [RFC7741] for details on the TID field.
図7は、VP8ストリームのレイヤーインデックスフィールドの形式を示しています。「RES」フィールドは、送信時にゼロに設定し、受信で無視する必要があります。TIDフィールドの詳細については、[RFC7741]のセクション4.2を参照してください。
A VP8 layer refresh point can be identified by the presence of the Y bit (see [RFC7741]) in the VP8 payload header. When this bit is set, this and all subsequent frames depend only on the current base temporal layer. On receipt of an LRR for a VP8 stream, a sender that supports LRRs MUST encode the stream so it can set the Y bit in a packet whose temporal layer is at or below the target layer index.
VP8レイヤーリフレッシュポイントは、VP8ペイロードヘッダーのYビット（[RFC7741]を参照）の存在によって識別できます。このビットが設定されている場合、これと後続のすべてのフレームは、現在のベース時間層のみに依存します。VP8ストリームのLRRを受信すると、LRRSをサポートする送信者は、ターゲットレイヤーインデックスのまたはそれ以下の時間層があるパケットにyビットを設定できるように、ストリームをエンコードする必要があります。
Note that in VP8, not every layer switch point can be identified by the Y bit since the Y bit implies layer switch of all layers, not just the layer in which it is sent. Thus, the use of an LRR with VP8 can result in some inefficiency in transmission. However, this is not expected to be a major issue for temporal structures in normal use.
VP8では、yビットは送信されるレイヤーだけでなく、すべてのレイヤーのレイヤースイッチを意味するため、すべてのレイヤースイッチポイントをyビットで識別できるわけではないことに注意してください。したがって、VP8でLRRを使用すると、伝播が何らかの非効率性をもたらす可能性があります。ただし、これは通常の使用における時間構造にとって大きな問題になるとは予想されていません。
The initial version of the H.265 payload format [RFC7798] defines temporal scalability, with protocol elements reserved for spatial or other scalability modes (which are expected to be defined in a future version of the specification).
H.265ペイロード形式[RFC7798]の初期バージョンは、時間的スケーラビリティを定義します。これは、空間またはその他のスケーラビリティモード（仕様の将来のバージョンで定義されると予想される）に予約されています。
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TID |RES| layer ID |
+---------------+---------------+
Figure 8: H.265 Layer Index Fields Format
図8：H.265レイヤーインデックスフィールド形式
Figure 8 shows the format of the layer index field for H.265 streams. The "RES" fields MUST be set to zero on transmission and ignored on reception. See Section 1.1.4 of [RFC7798] for details on the layer ID and TID fields.
図8は、H.265ストリームのレイヤーインデックスフィールドの形式を示しています。「RES」フィールドは、送信時にゼロに設定し、受信で無視する必要があります。レイヤーIDおよびTIDフィールドの詳細については、[RFC7798]のセクション1.1.4を参照してください。
H.265 streams signal whether they are temporally nested by using the vps_temporal_id_nesting_flag in the Video Parameter Set (VPS) and the sps_temporal_id_nesting_flag in the Sequence Parameter Set (SPS). If this flag is set in a stream's currently applicable VPS or SPS, receivers SHOULD NOT send temporal LRR messages for that stream, as every frame is implicitly a temporal layer refresh point.
H.265ストリームは、ビデオパラメーターセット（VPS）でVPS_TEMPORAL_ID_NESTING_FLAGを使用して、SPS_TEMPORAL_ID_NESTING_FLAGをシーケンスパラメーターセット（SPS）で使用して一時的にネストされているかどうかを信号します。このフラグが現在該当するストリームのVPSまたはSPSに設定されている場合、すべてのフレームが暗黙的に時間レイヤーリフレッシュポイントであるため、受信機はそのストリームの時間的LRRメッセージを送信してはなりません。
If a stream's sps_temporal_id_nesting_flag is not set, the NAL unit types 2 to 5 inclusively identify temporal layer switching points. A layer refresh to any higher target temporal layer is satisfied when a NAL unit type of 4 or 5 with TID equal to 1 more than current TID is seen. Alternatively, layer refresh to a target temporal layer can be incrementally satisfied with a NAL unit type of 2 or 3. In this case, given current TID = TO and target TID = TN, layer refresh to TN is satisfied when a NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up to TID = TN (note that TN and TO refer to nonce variables in this instance). During this incremental process, layer refresh to TN can be completely satisfied as soon as a NAL unit type of 2 or 3 is seen.
ストリームのSPS_TEMPORAL_ID_NESTING_FLAGが設定されていない場合、NALユニットタイプ2から5は、時間レイヤースイッチングポイントを包括的に識別します。より高いターゲットの時間レイヤーに対するレイヤーリフレッシュは、現在のTIDよりも1に等しいTIDを持つ4または5のNALユニットタイプが見える場合に満たされます。あるいは、ターゲットの一時的なレイヤーに層の更新は、2または3のNALユニットタイプで徐々に満たすことができます。この場合、現在のTID = toおよびターゲットTID = TNを考慮して、TNのNALユニットタイプがTID = T1、次にTID = T2、TID = TNまでのTIN（TNにはCENSに参照されている場合）に見える場合、TNのNALユニットタイプが満たされます。このインクリメンタルプロセス中に、TNのレイヤーリフレッシュは、2または3のNALユニットタイプが表示されるとすぐに完全に満たすことができます。
Of course, temporal layer refresh can also be satisfied whenever any Intra-Random Access Point (IRAP) NAL unit type (with values 16-23, inclusively) is seen. An IRAP picture is similar to an IDR picture in H.264 (NAL unit type of 5 in H.264) where decoding of the picture can start without any older pictures.
もちろん、一時的な層の更新は、ランダム内アクセスポイント（IRAP）nalユニットタイプ（値16-23、包括的に）が見られるときはいつでも満たすことができます。IRAP画像は、h.264のIDR画像（H.264の5のNALユニットタイプ5）に似ています。ここでは、古い写真なしで画像のデコードが開始できます。
In the (future) H.265 payloads that support spatial scalability, a spatial-layer refresh of a specific layer can be identified by NAL units with the requested layer ID and NAL unit types between 16 and 21, inclusive. A dependency or quality layer refresh is complete once NAL units of this type have been seen on all the appropriate layers (in decoding order) above the current layer index (if any, or beginning from the base layer if not) through the target layer index.
空間スケーラビリティをサポートする（将来の）H.265ペイロードでは、特定のレイヤーの空間層リフレッシュは、要求されたレイヤーIDとNALユニットタイプが16〜21の間に包括的であるNALユニットによって識別できます。このタイプのNALユニットが、ターゲットレイヤーインデックスを介して現在のレイヤーインデックス（もしあれば、またはベースレイヤーから始まる場合、またはベースレイヤーから始まる）上のすべての適切なレイヤー（デコード順）で見られると、依存関係または品質レイヤーの更新が完了します。
Several different mechanisms are defined for how scalable streams can be transmitted in RTP. Section 3.7 of "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" [RFC7656] defines three mechanisms: Single RTP stream on a Single media Transport (SRST), Multiple RTP streams on a Single media Transport (MRST), and Multiple RTP streams on Multiple media Transports (MRMT).
RTPでスケーラブルなストリームをどのように送信できるかについて、いくつかの異なるメカニズムが定義されています。「リアルタイム輸送プロトコル（RTP）ソースのセマンティクスとメカニズムの分類法」[RFC7656]のセクション3.7は、3つのメカニズムを定義します。単一の媒体トランスポート（SRST）の単一RTPストリーム、単一の媒体トランスポート（MRST）の複数のRTPストリーム（MRST）、および複数のRTPストリーム（MRMT）の複数のRTPストリーム。
The LRR message is applicable to all these mechanisms. For MRST and MRMT mechanisms, the "media source" field of the LRR FCI is set to the SSRC of the RTP stream containing the layer indicated by the Current Layer Index (if "C" is 1) or the stream containing the base encoded stream (if "C" is 0). For MRMT, the LRR message is sent on the RTP session on which this stream is sent. On receipt, the sender MUST refresh all the layers requested in the stream, simultaneously in decode order.
LRRメッセージは、これらすべてのメカニズムに適用できます。MRSTおよびMRMTメカニズムの場合、LRR FCIの「メディアソース」フィールドは、現在のレイヤーインデックス（「C」が1）で示されるレイヤーを含むRTPストリームのSSRCまたはベースエンコードストリーム（「C」が0の場合）を含むストリームを含むRTPストリームのSSRCに設定されます。MRMTの場合、このストリームが送信されるRTPセッションでLRRメッセージが送信されます。受領時に、送信者は、ストリームで要求されたすべてのレイヤーを、デコード順に同時に更新する必要があります。
Section 7 of [RFC5104] defines Session Description Protocol (SDP) procedures for indicating and negotiating support for Codec Control Messages (CCM) in SDP. This document extends this with a new codec control command, "lrr", which indicates support of the LRR.
[RFC5104]のセクション7では、SDPのコーデック制御メッセージ（CCM）のサポートを示すと交渉するためのセッション説明プロトコル（SDP）手順を定義しています。このドキュメントは、LRRのサポートを示す新しいコーデック制御コマンド「LRR」でこれを拡張します。
Figure 9 gives a formal Augmented Backus-Naur Form (ABNF) [RFC5234] showing this grammar extension, extending the grammar defined in [RFC5104].
図9は、[RFC5104]で定義されている文法を拡張するこの文法拡張を示す、正式な増強されたバックナウル形式（ABNF）[RFC5234]を示しています。
rtcp-fb-ccm-param =/ SP "lrr" ; Layer Refresh Request
Figure 9: Syntax of the "lrr" CCM
図9：「LRR」CCMの構文
The Offer-Answer considerations defined in Section 7.2 of [RFC5104] apply.
[RFC5104]のセクション7.2で定義されているオファー回答の考慮事項が適用されます。
All the security considerations of FIR feedback packets [RFC5104] apply to LRR feedback packets as well. Additionally, media senders receiving LRR feedback packets MUST validate that the payload types and layer indices they are receiving are valid for the stream they are currently sending, and discard the requests if not.
FIRフィードバックパケットのすべてのセキュリティに関する考慮事項[RFC5104]は、LRRフィードバックパケットにも適用されます。さらに、LRRフィードバックパケットを受け取るメディア送信者は、受信しているペイロードタイプとレイヤーインデックスが現在送信しているストリームに対して有効であることを検証し、そうでない場合はリクエストを破棄する必要があります。
This document defines a new entry to the "Codec Control Messages" registry of the "Session Description Protocol (SDP) Parameters" registry group, according to the following data:
このドキュメントでは、次のデータに従って、「セッション説明プロトコル（SDP）パラメーター」レジストリグループの「コーデック制御メッセージ」レジストリの新しいエントリを定義します。
Value Name:
値名：
lrr
LRR
Long Name:
長い名前：
Layer Refresh Request Command
レイヤー更新リクエストコマンド
Usable with:
使用可能：
ccm
CCM
Mux:
Mux:
IDENTICAL-PER-PT
同一のpt
Reference:
参照：
RFC 9627
RFC 9627
This document also defines a new entry to the "FMT Values for PSFB Payload Types" registry of the "Real-Time Transport Protocol (RTP) Parameters" registry group, according to the following data:
このドキュメントでは、次のデータに従って、「PSFBペイロードタイプのFMT値」レジストリ「リアルタイムトランスポートプロトコル（RTP）パラメーター」レジストリグループの新しいエントリも定義します。
Name:
名前：
LRR
LRR
Long Name:
長い名前：
Layer Refresh Request Command
レイヤー更新リクエストコマンド
Value:
値：
10
10
Reference:
参照：
RFC 9627
RFC 9627
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[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,
<https://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, <https://www.rfc-editor.org/info/rfc5104>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A.
Eleftheriadis, "RTP Payload Format for Scalable Video
Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,
<https://www.rfc-editor.org/info/rfc6190>.
[RFC7741] Westin, P., Lundin, H., Glover, M., Uberti, J., and F.
Galligan, "RTP Payload Format for VP8 Video", RFC 7741,
DOI 10.17487/RFC7741, March 2016,
<https://www.rfc-editor.org/info/rfc7741>.
[RFC7798] Wang, Y.-K., Sanchez, Y., Schierl, T., Wenger, S., and M.
M. Hannuksela, "RTP Payload Format for High Efficiency
Video Coding (HEVC)", RFC 7798, DOI 10.17487/RFC7798,
March 2016, <https://www.rfc-editor.org/info/rfc7798>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9626] Zanaty, M., Berger, E., and S. Nandakumar, "Video Frame
Marking RTP Header Extension", RFC 9626,
DOI 10.17487/RFC9626, March 2025,
<https://www.rfc-editor.org/info/rfc9626>.
[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,
<https://www.rfc-editor.org/info/rfc7656>.
[RFC8082] Wenger, S., Lennox, J., Burman, B., and M. Westerlund,
"Using Codec Control Messages in the RTP Audio-Visual
Profile with Feedback with Layered Codecs", RFC 8082,
DOI 10.17487/RFC8082, March 2017,
<https://www.rfc-editor.org/info/rfc8082>.
[RFC9628] Uberti, J., Holmer, S., Flodman, M., Hong, D., and J.
Lennox, "RTP Payload Format for VP9 Video", RFC 9628,
DOI 10.17487/RFC9628, March 2025,
<https://www.rfc-editor.org/info/rfc9628>.
Jonathan Lennox
8x8, Inc. / Jitsi
Jersey City, NJ 07302
United States of America
Email: jonathan.lennox@8x8.com
Danny Hong
Google, Inc.
315 Hudson St.
New York, NY 10013
United States of America
Email: dannyhong@google.com
Justin Uberti
OpenAI
1455 3rd St
San Francisco, CA 94158
United States of America
Email: justin@uberti.name
Stefan Holmer
Google, Inc.
Kungsbron 2
SE-111 22 Stockholm
Sweden
Email: holmer@google.com
Magnus Flodman
Google, Inc.
Kungsbron 2
SE-111 22 Stockholm
Sweden
Email: mflodman@google.com