Internet Engineering Task Force (IETF) M. Zanaty
Request for Comments: 9626 E. Berger
Category: Experimental S. Nandakumar
ISSN: 2070-1721 Cisco Systems
March 2025
This document describes a Video Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information.
このドキュメントでは、RTPミドルボックスまたはネットワークノードでのエラー回復とパケット転送に重要なビデオフレームに関する情報を伝えるために使用されるRTPヘッダー拡張機能をマークするビデオフレームについて説明します。これは、メディアが暗号化され、ミドルボックスまたはノードがメディア復号化キーにアクセスできない場合に不可欠な場合に最も便利です。また、暗号化または暗号化されていないメディアのCodecに依存しない処理にも役立ちますが、コーデック固有の情報の拡張もサポートしています。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9626.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9626で取得できます。
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. Requirements Language
3. Video Frame Marking RTP Header Extension
3.1. Long Extension for Scalable Streams
3.2. Short Extension for Non-Scalable Streams
3.3. LID Mappings for Scalable Streams
3.3.1. VP9 LID Mapping
3.3.2. H265 LID Mapping
3.3.3. H264 Scalable Video Coding (SVC) LID Mapping
3.3.4. H264 Advanced Video Coding (AVC) LID Mapping
3.3.5. VP8 LID Mapping
3.3.6. Future Codec LID Mapping
3.4. Signaling Information
3.5. Usage Considerations
3.5.1. Relation to Layer Refresh Request (LRR)
3.5.2. Scalability Structures
4. Security and Privacy Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
Many widely deployed RTP [RFC3550] topologies [RFC7667] used in modern voice and video conferencing systems include a centralized component that acts as an RTP switch. It receives voice and video streams from each participant, which may be encrypted using Secure Real-time Transport Protocol (SRTP) [RFC3711] or extensions that provide participants with private media [RFC8871] via end-to-end encryption where the switch has no access to media decryption keys. The goal is to provide a set of streams back to the participants, which enable them to render the right media content. For example, in a simple video configuration, the goal will be that each participant sees and hears just the active speaker. In that case, the goal of the switch is to receive the voice and video streams from each participant, determine the active speaker based on energy in the voice packets, possibly using the client-to-mixer audio level RTP header extension [RFC6464], and select the corresponding video stream for transmission to participants; see Figure 1.
最新の音声およびビデオ会議システムで使用される多くの広く展開されたRTP [RFC3550]トポロジ[RFC7667]には、RTPスイッチとして機能する集中コンポーネントが含まれています。各参加者から音声とビデオのストリームを受け取ります。これは、セキュアリアルタイムトランスポートプロトコル（SRTP）[RFC3711]を使用して暗号化される場合があります。目標は、一連のストリームを参加者に提供することです。これにより、適切なメディアコンテンツをレンダリングできるようになります。たとえば、単純なビデオ構成では、各参加者がアクティブなスピーカーだけを見て聞くことが目標です。その場合、スイッチの目標は、各参加者から音声ストリームとビデオストリームを受信し、音声パケットのエネルギーに基づいてアクティブなスピーカーを決定し、おそらくクライアントからミキサへのオーディオレベルRTPヘッダー拡張[RFC6464]を使用し、参加者への送信用の対応するビデオストリームを選択することです。図1を参照してください。
In this document, an "RTP switch" is used as shorthand for the terms "switching RTP mixer", "source projecting middlebox", "source forwarding unit/middlebox" and "video switching Multipoint Control Unit (MCU)", as discussed in [RFC7667].
このドキュメントでは、[RFC7667]で説明されているように、「RTPスイッチ」は「RTPミキサー」、「ソースプロジェクトミドルボックス」、「ソース転送ユニット/ミドルボックス」、「ビデオスイッチングマルチポイントコントロールユニット（MCU）」の用語の速記として使用されます。
+---+ +------------+ +---+
| A |<---->| |<---->| B |
+---+ | | +---+
| RTP |
+---+ | Switch | +---+
| C |<---->| |<---->| D |
+---+ +------------+ +---+
Figure 1: RTP Switch
図1：RTPスイッチ
In order to properly support the switching of video streams, the RTP switch typically needs some critical information about video frames in order to start and stop forwarding streams.
ビデオストリームの切り替えを適切にサポートするために、RTPスイッチは通常、ストリームを開始および停止するためにビデオフレームに関するいくつかの重要な情報が必要です。
* Because of inter-frame dependencies, it should ideally switch video streams at a point where the first frame from the new speaker can be decoded by recipients without prior frames, e.g., switch on an intra-frame.
* インターフレームの依存関係のため、新しいスピーカーからの最初のフレームを以前のフレームなしで受信者がデコードできるポイントで、ビデオストリームを理想的に切り替える必要があります。
* In many cases, the switch may need to drop frames in order to realize congestion control techniques, and it needs to know which frames can be dropped with minimal impact to video quality.
* 多くの場合、混雑制御技術を実現するためにスイッチをドロップする必要がある場合があり、ビデオ品質への影響を最小限に抑えてドロップできるフレームを知る必要があります。
* For scalable streams with dependent layers, the switch may need to selectively forward specific layers to specific recipients due to recipient bandwidth or decoder limits.
* 従属層を備えたスケーラブルなストリームの場合、スイッチは、受信者の帯域幅またはデコーダーの制限により、特定のレイヤーを特定の受信者に選択的に転送する必要がある場合があります。
Furthermore, it is highly desirable to do this in a payload format-agnostic way that is not specific to each different video codec. Most modern video codecs share common concepts around frame types and other critical information to make this codec-agnostic handling possible.
さらに、それぞれの異なるビデオコーデックに固有のペイロード形式に依存しない方法でこれを行うことが非常に望ましいです。ほとんどの最新のビデオコーデックは、このコーデックに依存しない処理を可能にするために、フレームタイプやその他の重要な情報を中心に共通の概念を共有しています。
It is also desirable to be able to do this for SRTP without requiring the video switch to decrypt the packets. SRTP will encrypt the RTP payload format contents; consequently, this data is not usable for the switching function without decryption, which may not even be possible in the case of end-to-end encryption of private media [RFC8871].
また、パケットを復号化するためにビデオスイッチを必要とせずに、SRTPのためにこれを行うことができることも望ましいです。SRTPは、RTPペイロード形式のコンテンツを暗号化します。その結果、このデータは、復号化なしでスイッチング関数に使用できません。これは、プライベートメディアのエンドツーエンドの暗号化の場合でも不可能かもしれません[RFC8871]。
By providing meta-information about the RTP streams outside the encrypted media payload, an RTP switch can do codec-agnostic selective forwarding without decrypting the payload. This document specifies the necessary meta-information in an RTP header extension.
暗号化されたメディアペイロードの外側のRTPストリームに関するメタ情報を提供することにより、RTPスイッチはペイロードを復号化することなくコーデックに依存しない選択的転送を行うことができます。このドキュメントは、RTPヘッダー拡張機能に必要なメタ情報を指定します。
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] で説明されているように解釈されます。
This specification uses RTP header extensions as defined in [RFC8285]. A subset of meta-information from the video stream is provided as an RTP header extension to allow an RTP switch to do generic selective forwarding of video streams encoded with potentially different video codecs.
この仕様では、[RFC8285]で定義されているRTPヘッダー拡張機能を使用します。ビデオストリームからのメタ情報のサブセットは、RTPヘッダー拡張機能として提供され、RTPスイッチが潜在的に異なるビデオコーデックでエンコードされたビデオストリームの一般的な選択的転送を行うことができます。
The Video Frame Marking RTP header extension is encoded using the one-byte header or two-byte header as described in [RFC8285]. The one-byte header format is used for examples in this document. The two-byte header format is used when other two-byte header extensions are present in the same RTP packet since mixing one-byte and two-byte extensions is not possible in the same RTP packet.
[RFC8285]で説明されているように、ビデオフレームマーキングRTPヘッダー拡張機能は、1バイトヘッダーまたは2バイトヘッダーを使用してエンコードされます。1バイトのヘッダー形式は、このドキュメントの例に使用されます。同じRTPパケットでは1バイトと2バイトの拡張機能を混合することができないため、他の2バイトヘッダー拡張機能が同じRTPパケットに存在する場合、2バイトヘッダー形式が使用されます。
This extension is only specified for Source (not Redundancy) RTP Streams [RFC7656] that carry video payloads. It is not specified for audio payloads, nor is it specified for Redundancy RTP Streams. The (separate) specifications for Redundancy RTP Streams often include provisions for recovering any header extensions that were part of the original source packet. Such provisions can be followed to recover the Video Frame Marking RTP header extension of the original source packet. Source packet frame markings may be useful when generating Redundancy RTP Streams; for example, the I (Independent Frame) and D (Discardable Frame) bits, defined in Section 3.1, can be used to generate extra or no redundancy, respectively, and redundancy schemes with source blocks can align source block boundaries with independent frame boundaries as marked by the I bit.
この拡張機能は、ビデオペイロードを運ぶソース（冗長性ではない）RTPストリーム[RFC7656]に対してのみ指定されます。オーディオペイロードには指定されておらず、冗長性RTPストリームにも指定されていません。冗長性RTPストリームの（個別の）仕様には、多くの場合、元のソースパケットの一部であるヘッダー拡張機能を回復するための規定が含まれます。このような規定に従って、元のソースパケットのRTPヘッダー拡張機能をマークするビデオフレームを回復できます。ソースパケットフレームマーキングは、冗長性RTPストリームを生成する場合に役立ちます。たとえば、セクション3.1で定義されているI（独立フレーム）およびD（廃棄可能フレーム）ビットをそれぞれ使用して、それぞれ追加またはNO冗長性を生成できます。ソースブロックを使用した冗長性スキームは、Iビットによってマークされた独立したフレーム境界にソースブロック境界を整列できます。
A frame, in the context of this specification, is the set of RTP packets with the same RTP timestamp from a specific RTP Synchronization Source (SSRC). A frame within a layer is the set of RTP packets with the same RTP timestamp, SSRC, Temporal-layer ID (TID), and Layer ID (LID).
この仕様のコンテキストでのフレームは、特定のRTP同期ソース（SSRC）から同じRTPタイムスタンプを備えたRTPパケットのセットです。レイヤー内のフレームは、同じRTPタイムスタンプ、SSRC、時間層ID（TID）、およびレイヤーID（LID）を備えたRTPパケットのセットです。
The following RTP header extension is RECOMMENDED for scalable streams. It MAY also be used for non-scalable streams, in which case the TID, LID, and TL0PICIDX MUST be 0 or omitted. The ID is assigned per [RFC8285]. The length is encoded as follows:
スケーラブルなストリームには、次のRTPヘッダー拡張が推奨されます。また、非スケーラブルなストリームにも使用される場合があります。この場合、TID、LID、およびTL0PICIDXは0または省略する必要があります。IDは[RFC8285]ごとに割り当てられます。長さは次のようにエンコードされます。
* L=2 to indicate 3 octets of data when nothing is omitted,
* L = 2は、省略されていない場合に3オクテットのデータを示すために、
* L=1 for 2 octets when TL0PICIDX is omitted, or
* tl0picidxが省略されている場合の2オクテットの場合はl = 1、または
* L=0 for 1 octet when both the LID and TL0PICIDX are omitted.
* lidとtl0picidxの両方が省略されている場合の1オクテットの場合l = 0。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=2 |S|E|I|D|B| TID | LID | TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=1 |S|E|I|D|B| TID | LID | (TL0PICIDX omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
or
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=0 |S|E|I|D|B| TID | (LID and TL0PICIDX omitted)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following information is extracted from the media payload and sent in the Video Frame Marking RTP header extension.
次の情報は、メディアペイロードから抽出され、RTPヘッダー拡張機能をマークするビデオフレームに送信されます。
S: Start of Frame (1 bit)
S：フレームの開始（1ビット）
MUST be 1 in the first packet in a frame within a layer; otherwise, MUST be 0.
レイヤー内のフレーム内の最初のパケットの1でなければなりません。それ以外の場合は、0でなければなりません。
E: End of Frame (1 bit)
E：フレームの終わり（1ビット）
MUST be 1 in the last packet in a frame within a layer; otherwise, MUST be 0. Note that the RTP header marker bit MAY be used to infer the last packet of the highest enhancement layer in payload formats with such semantics.
レイヤー内のフレーム内の最後のパケットの1でなければなりません。それ以外の場合は、0でなければなりません。RTPヘッダーマーカービットを使用して、このようなセマンティクスを備えたペイロード形式の最高拡張レイヤーの最後のパケットを推測することに注意してください。
I: Independent Frame (1 bit)
I：独立したフレーム（1ビット）
MUST be 1 for a frame within a layer that can be decoded independent of temporally prior frames, e.g., intra-frame, VPX keyframe, H.264 Instantaneous Decoding Refresh (IDR) [RFC6184], or H.265 IDR / Clean Random Access (CRA) / Broken Link Access (BLA) / Random Access Point (RAP) [RFC7798]; otherwise, MUST be 0. Note that this bit only signals temporal independence, so it can be 1 in spatial or quality enhancement layers that depend on temporally co-located layers but not temporally prior frames.
一時的に以前のフレーム、たとえば、フレーム内、VPXキーフレーム、H.264インスタンスデコードリフレッシュ（IDR）[RFC6184]、またはH.265 IDR /クリーンランダムアクセス（CRA） /ランダムアクセス（BLA） /ランダムアクセスポイント（RAP）[RFC7798年にかけてのフレーム内のフレームのフレームの場合は1でなければなりません。それ以外の場合は、0でなければなりません。このビットは時間の独立性のみを信号することに注意してください。したがって、時間的に共同配置された層に依存するが、時間的に前のフレームではなく、空間的または品質強化層で1になる可能性があることに注意してください。
D: Discardable Frame (1 bit)
D：破棄可能なフレーム（1ビット）
MUST be 1 for a frame within a layer the sender knows can be discarded and still provide a decodable media stream; otherwise, MUST be 0.
送信者が知っているレイヤー内のフレームの場合は1でなければなりません。それ以外の場合は、0でなければなりません。
B: Base Layer Sync (1 bit)
B：ベースレイヤー同期（1ビット）
When the TID is not 0, this MUST be 1 if the sender knows this frame within a layer only depends on the base temporal layer; otherwise, MUST be 0. When the TID is 0 or if no scalability is used, this MUST be 0.
TIDが0でない場合、レイヤー内のこのフレームがベースの時間層にのみ依存することを送信者が知っている場合、これは1でなければなりません。それ以外の場合は、0でなければなりません。TIDが0の場合、またはスケーラビリティが使用されない場合、これは0でなければなりません。
TID: Temporal-layer ID (3 bits)
TID：時間層ID（3ビット）
Identifies the temporal layer/sub-layer encoded, starting with 0 for the base layer and increasing with higher temporal fidelity. If no scalability is used, this MUST be 0. It is implicitly 0 in the short extension format.
ベースレイヤーの0から始まり、より高い時間的忠実度とともに増加する時間層/サブレイヤーエンコードを識別します。スケーラビリティが使用されない場合、これは0でなければなりません。短い拡張形式で暗黙的に0です。
LID: Layer ID (8 bits)
蓋：レイヤーID（8ビット）
Identifies the spatial and quality layer encoded, starting with 0 for the base layer and increasing with higher fidelity. If no scalability is used, this MUST be 0 or omitted to reduce length. When the LID is omitted, TL0PICIDX MUST also be omitted. It is implicitly 0 in the short extension format or when omitted in the long extension format.
ベースレイヤーの0から始まり、より高い忠実度とともに増加する空間および品質の層を識別します。スケーラビリティが使用されない場合、これは0であるか、長さを短縮するために省略する必要があります。蓋を省略する場合、TL0PICIDXも省略する必要があります。短い拡張形式では暗黙的に0です。または、長い拡張形式で省略した場合。
TL0PICIDX: Temporal Layer 0 Picture Index (8 bits)
TL0PICIDX：時間レイヤー0画像インデックス（8ビット）
When the TID is 0 and the LID is 0, this is a cyclic counter labeling base layer frames. When the TID is not 0 or the LID is not 0, the indication is that a dependency on the given index, such that this frame within this layer depends on the frame with this label in the layer with a TID 0 and LID 0. If no scalability is used, or the cyclic counter is unknown, TL0PICIDX MUST be omitted to reduce length. Note that 0 is a valid index value for TL0PICIDX.
TIDが0で、蓋が0の場合、これは循環カウンターラベルベースレイヤーフレームです。TIDが0であるか、蓋が0でない場合、指定されたインデックスに依存することです。このレイヤー内のこのフレームは、TID 0と蓋のレイヤーのこのラベルを持つフレームに依存します。0はTL0PICIDXの有効なインデックス値であることに注意してください。
The layer information contained in the TID and LID convey useful aspects of the layer structure that can be utilized in selective forwarding.
TIDとLIDに含まれるレイヤー情報は、選択的転送で利用できるレイヤー構造の有用な側面を伝えます。
Without further information about the layer structure, these TID/LID identifiers can only be used for relative priority of layers and implicit dependencies between layers. They convey a layer hierarchy with TID = 0 and LID = 0 identifying the base layer. Higher values of TID identify higher temporal layers with higher frame rates. Higher values of LID identify higher spatial and/or quality layers with higher resolutions and/or bitrates. Implicit dependencies between layers assume that a layer with a given TID/LID MAY depend on a layer or layers with the same or lower TID/LID, but they MUST NOT depend on a layer or layers with higher TID/LID.
レイヤー構造の詳細がなければ、これらのTID/蓋の識別子は、レイヤーの相対的な優先度とレイヤー間の暗黙の依存関係にのみ使用できます。それらは、ベースレイヤーを識別するTid = 0とlid = 0でレイヤー階層を伝達します。TIDの値が高いほど、より高いフレームレートの高い時間層が識別されます。蓋の値が高いほど、高分解能および/またはビットレートを備えたより高い空間的および/または品質層が識別されます。レイヤー間の暗黙的な依存関係、特定のTID/蓋を持つレイヤーは、同じまたは低いTID/蓋のあるレイヤーまたはレイヤーに依存する可能性があるが、より高いTID/蓋のあるレイヤーまたはレイヤーに依存してはならないと仮定します。
With further information, for example, possible future RTCP source description (SDES) items that convey full layer structure information, it may be possible to map these TIDs and LIDs to specific absolute frame rates, resolutions, bitrates, and explicit dependencies between layers. Such additional layer information may be useful for forwarding decisions in the RTP switch but is beyond the scope of this document. The relative layer information is still useful for many selective forwarding decisions, even without such additional layer information.
たとえば、完全なレイヤー構造情報を伝える可能性のある将来のRTCPソース説明（SDES）項目を使用すると、これらのTIDと蓋を特定の絶対フレームレート、解像度、ビットレート、および層間の明示的な依存関係にマッピングすることができます。このような追加のレイヤー情報は、RTPスイッチの決定を転送するのに役立つ場合がありますが、このドキュメントの範囲を超えています。相対層情報は、このような追加の層情報がなくても、多くの選択的転送の決定に依然として役立ちます。
The following RTP header extension is RECOMMENDED for non-scalable streams. It is identical to the shortest form of the extension for scalable streams, except the last four bits (B and TID) are replaced with zeros. It MAY also be used for scalable streams if the sender has limited or no information about stream scalability. The ID is assigned per [RFC8285]; the length is encoded as L=0, which indicates 1 octet of data.
非スケーラブルストリームには、次のRTPヘッダー拡張が推奨されます。これは、最後の4つのビット（BおよびTID）がゼロに置き換えられていることを除いて、スケーラブルストリームの拡張機能の最短形式と同じです。また、送信者がストリームのスケーラビリティに関する情報が制限されているか、またはない場合、スケーラブルストリームにも使用される場合があります。IDは[RFC8285]に従って割り当てられます。長さはl = 0としてエンコードされ、1オクテットのデータを示します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=0 |S|E|I|D|0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following information is extracted from the media payload and sent in the Video Frame Marking RTP header extension.
次の情報は、メディアペイロードから抽出され、RTPヘッダー拡張機能をマークするビデオフレームに送信されます。
S: Start of Frame (1 bit)
S：フレームの開始（1ビット）
MUST be 1 in the first packet in a frame; otherwise, MUST be 0.
フレーム内の最初のパケットに1でなければなりません。それ以外の場合は、0でなければなりません。
E: End of Frame (1 bit)
E：フレームの終わり（1ビット）
MUST be 1 in the last packet in a frame; otherwise, MUST be 0. SHOULD match the RTP header marker bit in payload formats with such semantics for marking end of frame.
フレーム内の最後のパケットの1でなければなりません。それ以外の場合は、0でなければなりません。ペイロード形式のRTPヘッダーマーカービットを、フレームの端をマークするためのこのようなセマンティクスと一致させる必要があります。
I: Independent Frame (1 bit)
I：独立したフレーム（1ビット）
MUST be 1 for frames that can be decoded independent of temporally prior frames, e.g., intra-frame, VPX keyframe, H.264 IDR [RFC6184], or H.265 IDR/CRA/BLA/IRAP [RFC7798]; otherwise, MUST be 0.
一時的に以前のフレーム、たとえば、フレーム内、VPXキーフレーム、H.264 IDR [RFC6184]、またはH.265 IDR/CRA/BLA/IRAP [RFC7798]に依存してデコードできるフレームの1でなければなりません。それ以外の場合は、0でなければなりません。
D: Discardable Frame (1 bit)
D：破棄可能なフレーム（1ビット）
MUST be 1 for frames the sender knows can be discarded and still provide a decodable media stream; otherwise, MUST be 0.
送信者が廃棄し、さらにデコード可能なメディアストリームを提供できるフレームに対して1でなければなりません。それ以外の場合は、0でなければなりません。
The remaining (4 bits)
残りの（4ビット）
These are reserved/fixed values and not used for non-scalable streams; they MUST be set to zero upon transmission and ignored upon reception.
これらは予約/固定値であり、非スケーラブルストリームには使用されていません。伝送時にゼロに設定し、受信時に無視する必要があります。
This section maps the specific Layer ID (LID) information contained in specific scalable codecs to the generic LID and TID fields.
このセクションは、特定のスケーラブルなコーデックに含まれる特定のレイヤーID（蓋）情報を、一般的な蓋とTIDフィールドにマッピングします。
Note that non-scalable streams have no LID information; thus, they have no mappings.
非スケーラブルなストリームには蓋情報がないことに注意してください。したがって、それらにはマッピングがありません。
The VP9 [RFC9628] Spatial-layer ID (SID, 3 bits) and Temporal-layer ID (TID, 3 bits) in the VP9 payload descriptor are mapped to the generic LID and TID fields in the header extension as shown in the following figure.
VP9 [RFC9628] VP9ペイロード記述子のVP9 [RFC9628]空間層ID（SID、3ビット）および時間層ID（TID、3ビット）は、次の図に示すように、ヘッダーエクステンションのジェネリックリッドおよびTIDフィールドにマッピングされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=2 |S|E|I|D|B| TID |0|0|0|0|0| SID | TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The S bit MUST match the B bit in the VP9 payload descriptor.
Sビットは、VP9ペイロード記述子のBビットと一致する必要があります。
The E bit MUST match the E bit in the VP9 payload descriptor.
Eビットは、VP9ペイロード記述子のEビットと一致する必要があります。
The I bit MUST match the inverse of the P bit in the VP9 payload descriptor.
Iビットは、VP9ペイロード記述子のPビットの逆と一致する必要があります。
The D bit MUST be 1 if the refresh_frame_flags bits in the VP9 payload uncompressed header are all 0; otherwise, it MUST be 0.
VP9ペイロードの非圧縮ヘッダーのREFRESH_FRAME_FLAGSビットがすべて0である場合、Dビットは1でなければなりません。それ以外の場合は、0でなければなりません。
The B bit MUST be 0 if the TID is 0; if the TID is not 0, it MUST match the U bit in the VP9 payload descriptor.
TIDが0の場合、Bビットは0でなければなりません。TIDが0でない場合、VP9ペイロード記述子のUビットと一致する必要があります。
Note: when using temporally nested scalability structures as recommended in Section 3.5.2, the B bit and VP9 U bit will always be 1 if the TID is not 0 since it is always possible to switch up to a higher temporal layer in such nested structures.
注：セクション3.5.2で推奨されているように、時間的にネストされたスケーラビリティ構造を使用する場合、TIDが0でない場合、BビットとVP9 Uビットは常に1になります。そのようなネストされた構造のより高い時間層に切り替えることができるため、常に0があります。
The TID, SID, and TL0PICIDX MUST match the correspondingly named fields in the VP9 payload descriptor, with SID aligned in the least significant 3 bits of the 8-bit LID field and zeros in the most significant 5 bits.
TID、SID、およびTL0PICIDXは、VP9ペイロード記述子の対応する名前のフィールドと一致する必要があります。SIDは、8ビット蓋フィールドの最も重要な3ビットと最も重要な5ビットのゼロに揃っています。
The H265 [RFC7798] layer ID (6 bits), and TID (3 bits) from the Network Abstraction Layer (NAL) unit header are mapped to the generic LID and TID fields in the header extension as shown in the following figure.
次の図に示すように、ネットワーク抽象化レイヤー（NAL）ユニットヘッダーからのH265 [RFC7798]レイヤーID（6ビット）、およびネットワーク抽象レイヤー（NAL）ユニットヘッダーからのTID（3ビット）は、ヘッダー拡張機能の一般的な蓋とTIDフィールドにマッピングされます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=2 |S|E|I|D|B| TID |0|0| layer ID | TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The S and E bits MUST match the correspondingly named bits in PACI:PHES:TSCI payload structures.
SおよびEビットは、Paci：Phes：TSCIペイロード構造の対応する名前のビットと一致する必要があります。
The I bit MUST be 1 when the NAL unit type is 16-23 (inclusive) or 32-34 (inclusive), or an aggregation packet or fragmentation unit encapsulating any of these types; otherwise, it MUST be 0. These ranges cover intra (IRAP) frames as well as critical parameter sets (Video Parameter Set (VPS), Sequence Parameter Set (SPS), Picture Parameter Set (PPS)).
NALユニットタイプが16-23（包括的）または32-34（包括的）の場合、またはこれらのタイプのいずれかをカプセル化する集約パケットまたはフラグメンテーションユニットの場合、iビットは1でなければなりません。それ以外の場合は、0でなければなりません。これらの範囲は、内部（IRAP）フレームと批判的なパラメーターセット（ビデオパラメーターセット（VPS）、シーケンスパラメーターセット（SPS）、画像パラメーターセット（PPS））をカバーしています。
The D bit MUST be 1 if either:
どちらかの場合、Dビットは1でなければなりません。
* the payload's NAL unit header's NRI field is 0, or
* ペイロードのNALユニットヘッダーのNRIフィールドは0または
* the payload is an aggregation packet or fragmentation unit encapsulating only NAL units with NRI = 0.
* ペイロードは、NRI = 0のNALユニットのみをカプセル化する集約パケットまたはフラグメンテーションユニットです。
Otherwise, it MUST be 0.
それ以外の場合は、0でなければなりません。
The NRI = 0 condition signals non-reference frames.
NRI = 0条件は、非参照フレームを信号します。
The B bit cannot be determined reliably from simple inspection of payload headers; therefore, it is determined by implementation-specific means. For example, internal codec interfaces may provide information to set this reliably.
ペイロードヘッダーの簡単な検査からBビットを確実に決定することはできません。したがって、実装固有の手段によって決定されます。たとえば、内部コーデックインターフェイスは、これを確実に設定するための情報を提供する場合があります。
The TID and layer ID MUST match the correspondingly named fields in the H265 NAL unit header, with layer ID aligned in the least significant 6 bits of the 8-bit LID field and zeros in the most significant 2 bits.
TIDおよびレイヤーIDは、H265 NALユニットヘッダーの対応する名前付きフィールドと一致する必要があります。レイヤーIDは、8ビット蓋フィールドの最も重要な6ビット、および最も重要な2ビットのゼロに揃っています。
The following shows H264-SVC [RFC6190] Layer encoding information (3 bits for spatial/dependency layer (DID), 4 bits for quality layer (QID), and 3 bits for temporal layer) mapped to the generic LID and TID fields.
以下は、H264-SVC [RFC6190]レイヤーエンコード情報（空間/依存レイヤーの3ビット（DID）、品質レイヤーの4ビット（QID）、およびジェネリックリッドおよびTIDフィールドにマッピングされた3ビット）を示しています。
The S, E, I, and D bits MUST match the correspondingly named bits in Payload Content Scalability Information (PACSI) payload structures.
S、E、I、およびDビットは、ペイロードコンテンツスケーラビリティ情報（PACSI）ペイロード構造の対応する名前のビットと一致する必要があります。
The I bit MUST be 1 when the NAL unit type is 5, 7, 8, 13, 15, or an aggregation packet or fragmentation unit encapsulating any of these types; otherwise, it MUST be 0. These ranges cover intra (IDR) frames as well as critical parameter sets (SPS/PPS variants).
NALユニットタイプが5、7、8、13、15、またはこれらのタイプのカプセル化をカプセル化する集約パケットまたはフラグメンテーションユニットの場合、iビットは1でなければなりません。それ以外の場合は、0でなければなりません。これらの範囲は、重要なパラメーターセット（SPS/PPSバリアント）だけでなく、内部（IDR）フレームをカバーしています。
The D bit MUST be 1 if either:
どちらかの場合、Dビットは1でなければなりません。
* the payload's NAL unit header's NRI field is 0, or
* ペイロードのNALユニットヘッダーのNRIフィールドは0または
* the payload is an aggregation packet or fragmentation unit encapsulating only NAL units with NRI = 0.
* ペイロードは、NRI = 0のNALユニットのみをカプセル化する集約パケットまたはフラグメンテーションユニットです。
Otherwise, it MUST be 0.
それ以外の場合は、0でなければなりません。
The NRI = 0 condition signals non-reference frames.
NRI = 0条件は、非参照フレームを信号します。
The B bit cannot be determined reliably from simple inspection of payload headers; therefore, it is determined by implementation-specific means. For example, internal codec interfaces may provide information to set this reliably.
ペイロードヘッダーの簡単な検査からBビットを確実に決定することはできません。したがって、実装固有の手段によって決定されます。たとえば、内部コーデックインターフェイスは、これを確実に設定するための情報を提供する場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=2 |S|E|I|D|B| TID |0| DID | QID | TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following shows the header extension for H264 (AVC) [RFC6184] that contains only temporal layer information.
以下は、時間層情報のみを含むH264（AVC）[RFC6184]のヘッダー拡張を示しています。
The S bit MUST be 1 when the timestamp in the RTP header differs from the timestamp in the prior RTP sequence number from the same SSRC; otherwise, it MUST be 0.
RTPヘッダーのタイムスタンプが、同じSSRCの以前のRTPシーケンス番号のタイムスタンプとは異なる場合、Sビットは1でなければなりません。それ以外の場合は、0でなければなりません。
The E bit MUST match the M bit in the RTP header.
eビットは、RTPヘッダーのMビットと一致する必要があります。
The I bit MUST be 1 when the NAL unit type is 5, 7, or 8, or an aggregation packet or fragmentation unit encapsulating any of these types; otherwise, it MUST be 0. These ranges cover intra (IDR) frames as well as critical parameter sets (SPS/PPS).
NALユニットタイプが5、7、または8の場合、Iビットは1でなければなりません。または、これらのタイプのいずれかをカプセル化する集約パケットまたはフラグメンテーションユニット。それ以外の場合は、0でなければなりません。これらの範囲は、内部（IDR）フレームと重要なパラメーターセット（SPS/PPS）をカバーしています。
The D bit MUST be 1 if either:
どちらかの場合、Dビットは1でなければなりません。
* the payload's NAL unit header's NRI field is 0, or
* ペイロードのNALユニットヘッダーのNRIフィールドは0または
* the payload is an aggregation packet or fragmentation unit encapsulating only NAL units with NRI = 0.
* ペイロードは、NRI = 0のNALユニットのみをカプセル化する集約パケットまたはフラグメンテーションユニットです。
Otherwise, it MUST be 0.
それ以外の場合は、0でなければなりません。
The NRI = 0 condition signals non-reference frames.
NRI = 0条件は、非参照フレームを信号します。
The B bit cannot be determined reliably from simple inspection of payload headers; therefore, it is determined by implementation-specific means. For example, internal codec interfaces may provide information to set this reliably.
ペイロードヘッダーの簡単な検査からBビットを確実に決定することはできません。したがって、実装固有の手段によって決定されます。たとえば、内部コーデックインターフェイスは、これを確実に設定するための情報を提供する場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following shows the header extension for VP8 [RFC7741] that contains only temporal layer information.
以下は、時間層情報のみを含むVP8 [RFC7741]のヘッダー拡張機能を示しています。
The S bit MUST match the correspondingly named bit in the VP8 payload descriptor when PID=0; otherwise, it MUST be 0.
sビットは、pid = 0の場合、VP8ペイロード記述子の対応する名前のビットと一致する必要があります。それ以外の場合は、0でなければなりません。
The E bit MUST match the M bit in the RTP header.
eビットは、RTPヘッダーのMビットと一致する必要があります。
The I bit MUST match the inverse of the P bit in the VP8 payload header.
Iビットは、VP8ペイロードヘッダーのPビットの逆と一致する必要があります。
The D bit MUST match the N bit in the VP8 payload descriptor.
Dビットは、VP8ペイロード記述子のNビットと一致する必要があります。
The B bit MUST match the Y bit in the VP8 payload descriptor.
Bビットは、VP8ペイロード記述子のYビットと一致する必要があります。
Note: when using temporally nested scalability structures as recommended in Section 3.5.2, the B bit and VP8 Y bit will always be 1 if the TID is not 0 since it is always possible to switch up to a higher temporal layer in such nested structures.
注：セクション3.5.2で推奨されているように、時間的にネストされたスケーラビリティ構造を使用する場合、TIDが0でない場合、Bビットとvp8 yビットは常に1になります。そのようなネストされた構造のより高い時間層に切り替えることができるため、常に0があります。
The TID and TL0PICIDX MUST match the correspondingly named fields in the VP8 payload descriptor.
TIDとTL0PICIDXは、VP8ペイロード記述子の対応する名前のフィールドと一致する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID=? | L=2 |S|E|I|D|B| TID |0|0|0|0|0|0|0|0| TL0PICIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTP payload format specification for future video codecs SHOULD include a section describing the LID mapping and TID mapping for the codec.
将来のビデオコーデックのRTPペイロード形式の仕様には、コーデックの蓋マッピングとTIDマッピングを説明するセクションを含める必要があります。
The URI for declaring this header extension in an extmap attribute is "urn:ietf:params:rtp-hdrext:framemarking". It does not contain any extension attributes.
ExtMap属性でこのヘッダー拡張機能を宣言するURIは、「urn：ietf：params：rtp-hdrext：framemarking」です。拡張属性は含まれていません。
An example attribute line in SDP:
SDPの属性行の例：
a=extmap:3 urn:ietf:params:rtp-hdrext:framemarking
The header extension values MUST represent what is already in the RTP payload.
ヘッダー拡張値は、すでにRTPペイロードにあるものを表す必要があります。
When an RTP switch needs to discard received video frames due to congestion control considerations, it is RECOMMENDED that it drop:
RTPスイッチが、混雑制御の考慮事項のために受信したビデオフレームを破棄する必要がある場合、それがドロップすることをお勧めします。
* frames marked with the D bit set, or
* dビットセットでマークされたフレーム、または
* frames with the highest values of TID and LID (which indicate the highest temporal and spatial/quality enhancement layers) since those typically have fewer dependencies on them than lower layers.
* TIDとLIDの最高値を持つフレーム（これは、最高の時間的および空間/品質の強化層を示すものです）。これは、通常、低レイヤーよりも依存関係が少ないためです。
When an RTP switch wants to forward a new video stream to a receiver, it is RECOMMENDED to select the new video stream from the first switching point with the I bit set in all spatial layers and forward the video stream from that point on. An RTP switch can request that a media source generate a switching point by sending an RTCP Full Intra Request (FIR) as defined in [RFC5104], for example.
RTPスイッチが新しいビデオストリームを受信機に転送する場合、すべての空間レイヤーに設定されたIビットを使用して、最初のスイッチングポイントから新しいビデオストリームを選択し、そのポイントからビデオストリームを転送することをお勧めします。RTPスイッチは、たとえば[RFC5104]で定義されているようにRTCPフルリクエスト（FIR）を送信することにより、メディアソースがスイッチングポイントを生成するように要求できます。
Receivers can use the Layer Refresh Request (LRR) [RFC9627] RTCP feedback message to upgrade to a higher layer in scalable encodings. The TID/LID values and formats used in LRR messages MUST correspond to the same values and formats specified in Section 3.1.
受信機は、レイヤーリフレッシュリクエスト（LRR）[RFC9627] RTCPフィードバックメッセージを使用して、スケーラブルなエンコーディングでより高いレイヤーにアップグレードできます。LRRメッセージで使用されるTID/LID値と形式は、セクション3.1で指定された同じ値と形式に対応する必要があります。
Because frame marking can only be used with temporally nested streams, temporal-layer refreshes requested with an LRR message are unnecessary for frame-marked streams. Other refreshes can be detected based on the I bit being set for the specific spatial layers.
フレームマーキングは一時的にネストされたストリームでのみ使用できるため、LRRメッセージで要求された時間層のリフレッシュは、フレームマークされたストリームでは不要です。他のリフレッシュは、特定の空間層に設定されているiビットに基づいて検出できます。
The LID and TID information is most useful for fixed scalability structures, such as nested hierarchical temporal layering structures, where each temporal layer only references lower temporal layers or the base temporal layer. The LID and TID information is less useful, or even not useful at all, for complex, irregular scalability structures that do not conform to common, fixed patterns of inter-layer dependencies and referencing structures. Therefore, it is RECOMMENDED to use LID and TID information for RTP switch forwarding decisions only in the case of temporally nested scalability structures, and it is NOT RECOMMENDED for other (more complex or irregular) scalability structures.
蓋とTIDの情報は、各側頭層がより低い側頭層または基本側頭層のみを参照する、ネストされた階層的な時間階層構造などの固定されたスケーラビリティ構造に最も役立ちます。蓋とTIDの情報は、複雑で不規則なスケーラビリティ構造の場合は、一般的で固定されたパターンの一般的な固定パターンと参照構造に適合していない場合、まったく有用ではありません。したがって、一時的にネストされたスケーラビリティ構造の場合にのみ、RTPスイッチ転送の決定に蓋とTID情報を使用することをお勧めします。また、他の（より複雑または不規則な）スケーラビリティ構造には推奨されません。
In "The Secure Real-time Transport Protocol (SRTP)" [RFC3711], RTP header extensions are authenticated and optionally encrypted [RFC9335]. When unencrypted header extensions are used, some metadata is exposed and visible to middleboxes on the network path, while encrypted media data and metadata in encrypted header extensions are not exposed.
「セキュアリアルタイムトランスポートプロトコル（SRTP）」[RFC3711]では、RTPヘッダー拡張機能が認証され、オプションで暗号化されます[RFC9335]。暗号化されていないヘッダー拡張機能を使用すると、いくつかのメタデータが露出し、ネットワークパス上のミドルボックスに表示されますが、暗号化されたメディアデータと暗号化されたヘッダー拡張機能のメタデータは露出していません。
The primary utility of this specification is for RTP switches to make proper media forwarding decisions. RTP switches are the SRTP peers of endpoints, so they can access encrypted header extensions, but not end-to-end encrypted private media payloads. Other middleboxes on the network path can only access unencrypted header extensions since they are not SRTP peers.
この仕様の主なユーティリティは、RTPスイッチが適切なメディア転送の決定を下すためです。RTPスイッチは、エンドポイントのSRTPピアであるため、暗号化されたヘッダー拡張機能にアクセスできますが、エンドツーエンドの暗号化されたプライベートメディアペイロードではありません。ネットワークパス上の他のミドルボックスは、SRTPピアではないため、暗号化されていないヘッダー拡張機能のみにアクセスできます。
RTP endpoints that negotiate this extension should consider whether:
この拡張機能を交渉するRTPエンドポイントは、次のかどうかを考慮する必要があります。
* this video frame marking metadata needs to be exposed to the SRTP peer only, in which case the header extension can be encrypted; or
* このビデオフレームマーキングメタデータは、SRTPピアのみにさらされる必要があります。その場合、ヘッダー拡張機能を暗号化できます。または
* other middleboxes on the network path also need this metadata, for example, to optimize packet drop decisions that minimize media quality impacts, in which case the header extension can be unencrypted, if the endpoint accepts the potential privacy leakage of this metadata.
* ネットワークパス上の他のミドルボックスは、たとえば、メディアの品質への影響を最小限に抑えるパケットドロップの決定を最適化するために、このメタデータも必要です。この場合、エンドポイントがこのメタデータの潜在的なプライバシー漏れを受け入れる場合、ヘッダー拡張機能を非暗号化できます。
For example, it would be possible to determine keyframes and their frequency in unencrypted header extensions. This information can often be obtained via statistical analysis of encrypted data. For example, keyframes are usually much larger than other frames, so frame size alone can leak this in the absence of any unencrypted metadata. However, unencrypted metadata provides a reliable signal rather than a statistical probability; so endpoints should take that into consideration to balance the privacy leakage risk against the potential benefit of optimized media delivery when deciding whether to negotiate and encrypt this header extension.
たとえば、暗号化されていないヘッダー拡張機能のキーフレームとその頻度を決定することが可能です。この情報は、暗号化されたデータの統計分析を介してしばしば取得できます。たとえば、キーフレームは通常、他のフレームよりもはるかに大きいため、暗号化されていないメタデータがない場合、フレームサイズだけでこれを漏らすことができます。ただし、暗号化されていないメタデータは、統計的確率ではなく信頼できる信号を提供します。したがって、エンドポイントは、このヘッダー拡張機能を交渉して暗号化するかどうかを決定する際に、最適化されたメディア配信の潜在的な利点とプライバシー漏れリスクのバランスをとるためにそれを考慮する必要があります。
This document defines a new extension URI listed in the "RTP Compact Header Extensions" registry of the "Real-Time Transport Protocol (RTP) Parameters" registry group, according to the following data:
このドキュメントでは、次のデータに従って、「RTP Compact Header Extensions」レジストリ「リアルタイムトランスポートプロトコル（RTP）パラメーター」レジストリグループのレジストリにリストされている新しい拡張機能URIを定義します。
Extension URI: urn:ietf:params:rtp-hdrext:framemarking
拡張uri：urn：ietf：params：rtp-hdrext：framemarking
Description: Frame marking information for video streams
説明：ビデオストリームのフレームマーキング情報
Contact: mzanaty@cisco.com
連絡先：mzanaty@cisco.com
Reference: RFC 9626
参照：RFC 9626
[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>.
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP
Payload Format for H.264 Video", RFC 6184,
DOI 10.17487/RFC6184, May 2011,
<https://www.rfc-editor.org/info/rfc6184>.
[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>.
[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General
Mechanism for RTP Header Extensions", RFC 8285,
DOI 10.17487/RFC8285, October 2017,
<https://www.rfc-editor.org/info/rfc8285>.
[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>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[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>.
[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", RFC 6464,
DOI 10.17487/RFC6464, December 2011,
<https://www.rfc-editor.org/info/rfc6464>.
[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>.
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
DOI 10.17487/RFC7667, November 2015,
<https://www.rfc-editor.org/info/rfc7667>.
[RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution
Framework for Private Media in Privacy-Enhanced RTP
Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871,
January 2021, <https://www.rfc-editor.org/info/rfc8871>.
[RFC9335] Uberti, J., Jennings, C., and S. Murillo, "Completely
Encrypting RTP Header Extensions and Contributing
Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023,
<https://www.rfc-editor.org/info/rfc9335>.
[RFC9627] Lennox, J., Hong, D., Uberti, J., Holmer, S., and M.
Flodman, "The Layer Refresh Request (LRR) RTCP Feedback
Message", RFC 9627, DOI 10.17487/RFC9627, March 2025,
<https://www.rfc-editor.org/info/rfc9627>.
[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>.
Many thanks to Bernard Aboba, Jonathan Lennox, Stephan Wenger, Dale Worley, and Magnus Westerlund for their inputs.
Bernard Aboba、Jonathan Lennox、Stephan Wenger、Dale Worley、Magnus Westerlundの意見に感謝します。
Mo Zanaty
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: mzanaty@cisco.com
Espen Berger
Cisco Systems
Email: espeberg@cisco.com
Suhas Nandakumar
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: snandaku@cisco.com