Internet Engineering Task Force (IETF) P.-A. Lemieux, Ed.
Request for Comments: 9828 Sandflow Consulting LLC
Category: Standards Track D. Taubman
ISSN: 2070-1721 University of New South Wales
August 2025
This document defines the RTP payload format for the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams. The format allows sub-codestream latency, such that the first RTP packet for a given image can be emitted before the entire image is available to or encoded by the sender.
このドキュメントでは、JPEG 2000コードストリームのシーケンスとしてエンコードされたビデオ信号のストリーミングのRTPペイロード形式を定義しています。この形式により、サブコデストリームのレイテンシが可能になり、特定の画像の最初の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/rfc9828.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9828で取得できます。
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. Media Format Description
4. Video Signal Description
5. Payload Format
5.1. General
5.2. RTP Fixed Header Usage
5.3. Main Packet Payload Header
5.4. Body Packet Payload Header
6. JPEG 2000 Codestream
7. Sender
7.1. Main Packet
7.2. RTP Packet Filtering
7.3. Resync Point
7.4. PTSTAMP Field
7.5. RES Field
7.6. Extra Information
7.7. Unassigned Values
7.8. Extension Values
7.9. Code-Block Caching
8. Receiver
8.1. PTSTAMP
8.2. QUAL
8.3. RES
8.4. Extra Information
8.5. Unassigned Values
8.6. Extension Values
8.7. Code-Block Caching
9. Media Type
9.1. General
9.2. Definition
10. Mapping to the Session Description Protocol (SDP)
11. Congestion Control
12. IANA Considerations
13. Security Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Pixel Formats
Appendix B. Signal Formats
Appendix C. Sample Formats
Authors' Addresses
The Real-time Transport Protocol (RTP), which is specified in [RFC3550], provides end-to-end network transport functions for transmitting real-time data but does not define the characteristics of the data itself (the payload), which varies across applications and is defined in companion RTP payload format documents.
[RFC3550]で指定されているリアルタイムトランスポートプロトコル（RTP）は、リアルタイムデータを送信するためのエンドツーエンドネットワークトランスポート機能を提供しますが、アプリケーションによって異なり、コンパニオンRTPペイロード形式のドキュメントで定義されているデータ自体（ペイロード）の特性（ペイロード）を定義しません。
This RTP payload format specifies the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams (see Section 3 for a primer on the structure of JPEG 2000 codestreams). JPEG 2000 is a flexible image codec that supports resolution and quality scalability, lossy-to-lossless coding, non-iterative optimal rate control, and high dynamic range, multi-channel, and subsampled images. These features have made it a mainstay in high-performance applications, including medical, geospatial, archival, cinema, studio post-production, and TV production.
このRTPペイロード形式は、JPEG 2000コードストリームのシーケンスとしてエンコードされたビデオ信号のストリーミングを指定します（JPEG 2000コードストリームの構造に関するプライマーについてはセクション3を参照）。JPEG 2000は、解像度と品質のスケーラビリティ、損失から失われないコーディング、非適格最適レート制御、高ダイナミックレンジ、マルチチャネル、およびサブサンプリング画像をサポートする柔軟な画像コーデックです。これらの機能により、医療、地理空間、アーカイブ、映画、スタジオポストプロダクション、テレビ制作など、高性能アプリケーションの主力となっています。
In addition to supporting a variety of frame-scanning techniques (progressive, interlaced, and progressive segmented frame) and image characteristics, the payload format supports real-time image transmission (live streaming), where image content is encoded, transmitted, and decoded continuously as it is being produced, with minimal latency. Target applications include real-time TV production over IP [OV2110-0], remote presence, surveillance, etc. Specifically:
さまざまなフレームスキャンテクニック（プログレッシブ、インターレース、およびプログレッシブセグメントフレーム）と画像特性をサポートすることに加えて、ペイロード形式は、最小レイテンシーで生成されているように、画像コンテンツがエンコード、送信され、継続的にデコードされるリアルタイム画像伝送（ライブストリーミング）をサポートします。ターゲットアプリケーションには、IP [OV2110-0]、リモートプレゼンス、監視などのリアルタイムテレビ制作が含まれます。具体的には：
* The payload format allows sub-codestream latency such that the first RTP packet of a given codestream can be emitted before the entire codestream is available. Specifically, the payload format does not rely on the JPEG 2000 PLM (Packet length, main header) and PLT (Packet length, tile-part header) marker segments for recovery after RTP packet loss since these markers can only be written after the codestream is complete and are thus incompatible with sub-codestream latency. Instead, the payload format includes payload header fields (ORDH, ORDB, POS, and PID) that indicate whether the RTP packet contains a resynchronization (resync) point and how a recipient can restart codestream processing from that resync point. This contrasts with [RFC5371], which also specifies an RTP payload format for JPEG 2000 but relies on codestream structures that cannot be emitted until the entire codestream is available.
* ペイロード形式により、サブコデストリームのレイテンシが可能になり、コードストリーム全体が利用可能になる前に、特定のコードストリームの最初のRTPパケットを放射できます。具体的には、ペイロード形式は、JPEG 2000 PLM（パケット長、メインヘッダー）およびPLT（パケット長、タイルパートヘッダー）マーカーセグメントに依存していません。RTPパケット損失後の回復のために、これらのマーカーはコードストリームが完了した後にのみ記述でき、したがってサブコードストリーム潜伏期と互換性がありません。代わりに、ペイロード形式には、RTPパケットに再同期（RESYNC）ポイントが含まれているかどうか、およびレシピエントがその再配置ポイントからコードストリーム処理を再起動する方法を示すペイロードヘッダーフィールド（ORDH、ORDB、POS、およびPID）が含まれます。これは[RFC5371]とは対照的です。これは、JPEG 2000のRTPペイロード形式も指定していますが、コードストリーム全体が利用可能になるまで放出できないコードストリーム構造に依存しています。
* As in [RFC4175], the payload format defines an extended sequence number, which extends the standard (16-bit) sequence number of the RTP Fixed Header by storing additional (high-order) bits in the payload header (ESEQ field). This enables the payload format to accommodate high data rates without ambiguity, since the standard sequence number will roll over very quickly for high data rates likely to be encountered in this application. For example, the standard sequence number will roll over in 0.5 seconds with a 1 Gbps video stream with RTP packet sizes of at least 1000 octets, which can be a problem for detecting loss and out-of-order RTP packets, particularly in instances where the round-trip time is greater than the rollover period (0.5 seconds in this example).
* [RFC4175]と同様に、ペイロード形式は拡張シーケンス番号を定義し、ペイロードヘッダー（ESEQフィールド）に追加（高次）ビットを保存することにより、RTP固定ヘッダーの標準（16ビット）シーケンス番号を拡張します。これにより、ペイロード形式はあいまいさのない高データレートに対応できます。これは、標準のシーケンス番号が非常に迅速にロールオーバーし、このアプリケーションで発生する可能性が高いため、非常に迅速にロールオーバーするからです。たとえば、標準シーケンス番号は、少なくとも1000オクテットのRTPパケットサイズを備えた1 Gbpsビデオストリームで0.5秒でロールオーバーされます。これは、特に往復時間がロールオーバー期間（この例では0.5秒）よりも大きい場合に、損失と注文外のRTPパケットを検出するための問題になる可能性があります。
* The payload header optionally contains a temporal offset (PTSTAMP) relative to the first RTP packet with the same value of RTP timestamp field (Section 5.2). The higher resolution of PTSTAMP compared to the timestamp allows receivers to recover the sender's clock more rapidly.
* ペイロードヘッダーは、オプションで、RTPタイムスタンプフィールドと同じ値を持つ最初のRTPパケットに対する時間的オフセット（PTStamp）を含んでいます（セクション5.2）。タイムスタンプと比較してPTSTAMPのより高い解像度により、受信機は送信者の時計をより迅速に回復することができます。
In addition to support for sub-codestream latency and high-precision sender clock recovery, the payload format improves on [RFC5371] by supporting:
サブコデストリームのレイテンシと高精度の送信者クロック回復のサポートに加えて、ペイロード形式は[RFC5371]で改善します。
* code-block caching for screen content (see Section 7.9);
* 画面コンテンツのコードブロックキャッシュ（セクション7.9を参照）。
* progressive segmented frame (PsF) video support (see Appendix B); and
* プログレッシブセグメントフレーム（PSF）ビデオサポート（付録Bを参照）。そして
* explicit colorspace signaling (see Section 5.3).
* 明示的なカラースペースシグナル伝達（セクション5.3を参照）。
Finally, the payload format also makes use of the unique scalability features of JPEG 2000 to allow an intermediate system or recipient to discard resolution levels and/or quality layers merely by inspecting RTP packet headers (QUAL and RES fields), without having to parse the underlying codestream (see Section 7.2).
最後に、ペイロード形式は、JPEG 2000の一意のスケーラビリティ機能を使用して、中間システムまたは受信者が、基礎となるコードストリームを解析することなく、RTPパケットヘッダー（QUALおよびRESフィールド）を検査するだけで解像度レベルおよび/または品質層を破棄できるようにします（セクション7.2を参照）。
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] で説明されているように解釈されます。
In case of conflict between the contents of a figure and the prose, the prose takes precedence.
人物の内容と散文の間に矛盾がある場合、散文が優先されます。
The following summarizes the structure of the JPEG 2000 codestream, which is specified in detail in [JPEG2000-1].
以下は、[JPEG2000-1]で詳細に指定されているJPEG 2000 Codestreamの構造をまとめたものです。
NOTE: As described in Section 6, a JPEG 2000 codestream allows capabilities defined in any part of the JPEG 2000 family of standards, including those specified in [JPEG2000-2] and [JPEG2000-15].
注：セクション6で説明されているように、JPEG 2000 Codestreamは、[JPEG2000-2]および[JPEG2000-15]で指定されているものを含む、JPEG 2000基準ファミリーの一部で定義される機能を許可します。
JPEG 2000 represents an image as one or more components, each uniformly sampled on a common rectangular reference grid. For example, an image can consist of the customary Y (luma), C_b (blue-difference chroma), and C_r (red-difference chroma) components, with the C_b and C_r being subsampled by a factor of two compared to the Y component.
JPEG 2000は、1つ以上のコンポーネントとして画像を表し、それぞれが一般的な長方形の参照グリッドで均一にサンプリングされます。たとえば、画像は、慣習的なy（luma）、c_b（青偏光クロマ）、およびc_r（red-difference chroma）コンポーネントで構成され、c_bとc_rはy成分と比較して2倍の係数でサブサンプリングされます。
An image can be further divided into contiguous rectangular tiles that are each independently coded and decoded.
画像は、それぞれ独立してコード化されてデコードされた隣接する長方形のタイルにさらに分割できます。
JPEG 2000 codes each image as a standalone codestream. A codestream consists of (i) marker segments, which contain coding parameters and metadata, and (ii) coded data.
JPEG 2000は、各画像をスタンドアロンコードストリームとしてコードします。コードストリームは、（i）コーディングパラメーターとメタデータを含むマーカーセグメント、および（ii）コード化されたデータで構成されています。
For convenience to the reader, the following lists both the abbreviated and full names of marker segments that are mentioned in this specification (several other marker segments are defined by JPEG 2000 and can be present in a codestream):
読者に便利なため、次のリストには、この仕様に記載されているマーカーセグメントの略語とフルネームの両方をリストします（他のいくつかのマーカーセグメントはJPEG 2000で定義され、コードストリームに存在することができます）。
CAP:
キャップ：
Extended Capabilities
拡張機能
COC:
COC：
Coding style component
コーディングスタイルコンポーネント
COD:
タラ：
Coding style default
コーディングスタイルのデフォルト
COM:
com：
Comment
コメント
EOC:
EOC：
End of codestream
コードストリームの終わり
PLM:
PLM：
Packet length, main header
パケット長、メインヘッダー
PLT:
PLT：
Packet length, tile-part header
パケット長、タイルパートヘッダー
SOC:
SOC：
Start of codestream
Codestreamの始まり
SOD:
SOD：
Start of data
データの開始
SOT:
sot：
Start of tile-part
タイルパートの開始
The codestream starts with an SOC marker segment and ends with an EOC marker segment. The main header of the codestream consists of marker segments between the SOC and first SOT marker segment and contains information that applies to the codestream in its entirety. It is generally impossible to decode a codestream without its main header.
CodestreamはSOCマーカーセグメントから始まり、EOCマーカーセグメントで終了します。コードストリームのメインヘッダーは、SOCとFirst SOTマーカーセグメントの間のマーカーセグメントで構成されており、Codestream全体に適用される情報が含まれています。メインヘッダーなしでコードストリームをデコードすることは一般に不可能です。
The rest of the codestream consists of additional marker segments (tile-part headers) interleaved with coded image data.
コードストリームの残りの部分は、コード化された画像データとインターリーブされる追加のマーカーセグメント（タイルパートヘッダー）で構成されています。
At the heart of JPEG 2000 coding is the wavelet transform, which decomposes the image into successive resolution levels, with each level related to the next one by a spatial factor of two, i.e., each successive resolution level has half the horizontal and half the vertical resolution of the previous one.
JPEG 2000コーディングの中心にあるのはウェーブレット変換であり、画像を連続した解像度レベルに分解し、各レベルは次のレベルに2つの空間係数で関連しています。
The coded image data ultimately consists of code-blocks, each containing coded samples belonging to a rectangular (spatial) region within one resolution level of one component. Code-blocks are further collected into precincts, which, accordingly, represent code-blocks belonging to a spatial region within one resolution level of one component.
コード化された画像データは、最終的にコードブロックで構成され、それぞれが1つのコンポーネントの1つの解像度レベル内で長方形（空間）領域に属するコード化されたサンプルを含みます。コードブロックはさらに境内に収集され、それに応じて、1つのコンポーネントの1つの解像度レベル内の空間領域に属するコードブロックを表します。
The coded image data can be arranged into several progression orders, which dictates which aspect of the image appears first in the codestream (in terms of byte offset). The progression orders are parameterized according to:
コード化された画像データは、いくつかの進行順序に配置できます。これにより、画像のどの側面がCodestreamで最初に表示されるか（バイトオフセットの観点から）を指示します。進行順序は、次のことに従ってパラメーター化されます。
Position (P)
位置（p）
The first lines of the image come before the last lines of the image.
画像の最初の行は、画像の最後の行の前に来ます。
Component (C)
コンポーネント（c）
The first component of the image comes before the last component of the image.
画像の最初のコンポーネントは、画像の最後のコンポーネントの前にあります。
Resolution Level (R)
解像度レベル（R）
The information needed to reconstruct the lower spatial resolutions of the image come before the information needed to reconstruct the higher spatial resolutions of the image.
画像のより高い空間解像度を再構築するために必要な情報の前に、画像のより低い空間解像度を再構築するために必要な情報が必要です。
Quality Layer (L)
品質レイヤー（L）
The information needed to reconstruct the most significant bits of each sample come before the information needed to reconstruct the least significant bit of each sample.
各サンプルの最も重要なビットを再構築するために必要な情報は、各サンプルの最も重要なビットを再構築するために必要な情報が必要です。
For example, in the PRCL progression order, the information needed to reconstruct the first lines of the image come before that needed to reconstruct the last lines of the image, and within a collection of lines, the information needed to reconstruct the lower spatial resolutions of the image come before the information needed to reconstruct the higher spatial resolutions. This progression order is particularly useful for subframe latency operations.
たとえば、PRCLの進行順序では、画像の最初の行を再構築するために必要な情報は、画像の最後の行を再構築するために必要な前に来る必要があり、行のコレクション内で、より高い空間解像度を再構築するために必要な情報が必要になる前に、画像の低い空間解像度を再構築するために必要な情報が必要です。この進行順序は、サブフレームの遅延操作に特に役立ちます。
This RTP payload format supports three distinct techniques for scanning video frames:
このRTPペイロード形式は、ビデオフレームをスキャンするための3つの異なる手法をサポートしています。
* Progressive frame
* プログレッシブフレーム
* Interlaced frame, where each frame consists of two fields. Field 1 occurs earlier in time than Field 2. The height in lines of each field is half the height of the image.
* 各フレームが2つのフィールドで構成されているインターレースフレーム。フィールド1は、フィールド2よりも早い時期に発生します。各フィールドの線の高さは、画像の高さの半分です。
* Progressive segmented frame (PsF), where each frame consists of two segments. Segment 1 contains the odd lines (1, 3, 5, 7, ...) of a frame, and Segment 2 contains the even lines (2, 4, 6, 8, ...) of the same frame, where lines from the top of the frame to the bottom of the frame are numbered sequentially starting at 1.
* 各フレームは2つのセグメントで構成されているプログレッシブセグメントフレーム（PSF）。セグメント1には、フレームの奇数線（1、3、5、7、...）が含まれ、セグメント2には同じフレームの均一な線（2、4、6、8、...）が含まれています。
All frames are scanned left to right, top to bottom.
すべてのフレームは、左から右、上から下にスキャンされます。
<--------------- Codestream (image) -------------->
| |
<----- Extended Header -----> |
| | |
+-----+-//-+-----+-//-+-----+--------//-----+-----+-----+---------
| SOC | .. | SOT | .. | SOD | ............. | EOC | P | SOC ...
+-----+-//-+-----+-//-+-----+--------//-----+-----+-----+---------
| | |
<----------> Main header |
| |
+------------------------------+------+--//-+-----------+---------
| Main | Body | ... | Body | Main ...
+------------------------------+------+--//-+-----------+---------
| |
<--------- RTP Packet --------->
Figure 1: Packetization of a Sequence of JPEG 2000 Codestreams (Not to Scale)
図1：JPEG 2000コードストリームのシーケンスのパケット化（スケーリングしない）
In Figure 1, P denotes (optional) padding bytes. See Section 3 for expansions of SOC, SOD, SOT, and EOC.
図1では、pは（オプション）パディングバイトを示します。SOC、SOD、SOT、およびEOCの拡張については、セクション3を参照してください。
Each RTP packet, as specified in [RFC3550], is either a Main Packet or a Body Packet.
[RFC3550]で指定されている各RTPパケットは、メインパケットまたはボディパケットのいずれかです。
A Main Packet consists of the following ordered sequence of structures concatenated without gaps:
メインパケットは、ギャップなしで連結された構造の次の順序付けられたシーケンスで構成されています。
* the RTP Fixed Header;
* RTP固定ヘッダー。
* a Main Packet Payload Header, as specified in Section 5.3; and
* セクション5.3で指定されているメインパケットペイロードヘッダー。そして
* the payload, which consists of a JPEG 2000 codestream fragment.
* JPEG 2000 Codestreamフラグメントで構成されるペイロード。
A Body Packet consists of the following ordered sequence of structures concatenated without gaps:
ボディパケットは、ギャップなしで連結された構造の次の順序付けられたシーケンスで構成されています。
* the RTP Fixed Header;
* RTP固定ヘッダー。
* a Body Packet Payload Header, as specified in Section 5.4; and
* セクション5.4で指定されているボディパケットペイロードヘッダー。そして
* the payload, which consists of a JPEG 2000 codestream fragment.
* JPEG 2000 Codestreamフラグメントで構成されるペイロード。
When concatenated, the sequence of JPEG 2000 codestream fragments emitted by the sender MUST be a sequence of JPEG 2000 codestreams where two successive JPEG 2000 codestreams MAY be separated by one or more padding bytes (see Figure 1).
連結すると、送信者によって放出されるJPEG 2000コードストリームフラグメントのシーケンスは、2つの連続したJPEG 2000コードストリームが1つ以上のパディングバイトによって分離される可能性があるJPEG 2000コードストリームのシーケンスでなければなりません（図1を参照）。
The sender MUST set the value of each padding byte to zero.
送信者は、各パディングバイトの値をゼロに設定する必要があります。
The receiver MUST ignore the values of the padding bytes.
受信機は、パディングバイトの値を無視する必要があります。
The JPEG 2000 codestreams MUST conform to Section 6.
JPEG 2000コードストリームは、セクション6に準拠する必要があります。
NOTE 1: Padding bytes can be used to achieve constant bit rate transmission.
注1：パディングバイトを使用して、一定のビットレート伝送を実現できます。
A JPEG 2000 codestream fragment, and thus an RTP packet, does not necessarily contain complete JPEG 2000 packets, as defined in [JPEG2000-1].
JPEG 2000 Codestreamフラグメント、したがってRTPパケットは、[JPEG2000-1]で定義されているように、必ずしも完全なJPEG 2000パケットを含むとは限りません。
A JPEG 2000 codestream Extended Header consists of the bytes between, and including, the SOC marker and the first SOD marker.
JPEG 2000 Codestream拡張ヘッダーは、SOCマーカーと最初のSODマーカーの間で、それを含むバイトで構成されています。
NOTE 2: The concept of the JPEG 2000 codestream Extended Header is specific to this document and is distinct from the JPEG 2000 codestream main header, which is defined in [JPEG2000-1]. The codestream main header consists of the bytes between, and including, the SOC marker and the first SOT marker. The codestream main header is a subset of the codestream Extended Header (see Figure 1).
注2：JPEG 2000 Codestream拡張ヘッダーの概念はこのドキュメントに固有であり、[JPEG2000-1]で定義されているJPEG 2000 Codestreamメインヘッダーとは異なります。CODESTREAMメインヘッダーは、SOCマーカーと最初のSOTマーカーの間、および含まれるバイトで構成されています。Codestream Main Headerは、Codestream拡張ヘッダーのサブセットです（図1を参照）。
The payload of a Body Packet MUST NOT contain any bytes of the JPEG 2000 codestream Extended Header.
ボディパケットのペイロードには、JPEG 2000 Codestream拡張ヘッダーのバイトを含めてはなりません。
The payload of a Main Packet MUST contain at least one byte of the JPEG 2000 codestream Extended Header and MAY contain bytes other than those of the JPEG 2000 codestream Extended Header.
メインパケットのペイロードには、JPEG 2000 Codestream拡張ヘッダーの少なくとも1つのバイトが含まれている必要があり、JPEG 2000 Codestream拡張ヘッダーのバイト以外のバイトを含めることができます。
A payload MUST NOT contain bytes from more than one JPEG 2000 codestream.
ペイロードには、複数のJPEG 2000 Codestreamからのバイトを含めてはなりません。
The following RTP header fields have a specific meaning in the context of this payload format:
次のRTPヘッダーフィールドには、このペイロード形式のコンテキストで特定の意味があります。
marker
マーカー
1
1
The payload contains an EOC marker.
ペイロードにはEOCマーカーが含まれています。
0
0
Otherwise
さもないと
timestamp
タイムスタンプ
The timestamp is the presentation time of the image to which the payload belongs.
タイムスタンプは、ペイロードが属する画像のプレゼンテーション時間です。
The timestamp clock rate is 90 kHz.
タイムスタンプクロックレートは90 kHzです。
The timestamp of successive progressive frames MUST advance at regular increments based on the instantaneous video frame rate.
連続したプログレッシブフレームのタイムスタンプは、瞬間的なビデオフレームレートに基づいて定期的に進む必要があります。
The timestamp of Field 1 of successive interlaced frames MUST advance at regular increments based on the instantaneous video frame rate, and the Timestamp of Field 2 MUST be offset from the timestamp of Field 1 by one half of the instantaneous frame period.
連続したインターレースフレームのフィールド1のタイムスタンプは、瞬間的なビデオフレームレートに基づいて定期的に進む必要があり、フィールド2のタイムスタンプは、フィールド1のタイムスタンプから瞬時フレーム期間の半分でオフセットする必要があります。
The timestamp of both segments of a progressive segmented frame MUST be equal.
プログレッシブセグメント化されたフレームの両方のセグメントのタイムスタンプは等しくなければなりません。
The timestamp of all RTP packets of a given image MUST be equal.
特定の画像のすべてのRTPパケットのタイムスタンプは等しくなければなりません。
sequence number
シーケンス番号
The low-order bits of the extended sequence number.
拡張シーケンス番号の低次ビット。
The high-order bits of the extended sequence number are contained in the ESEQ field, which is specified in Section 5.3.
拡張シーケンス番号の高次ビットは、セクション5.3で指定されているESEQフィールドに含まれています。
The extended sequence number is calculated as follows:
拡張シーケンス番号は次のように計算されます。
<extended sequence number> = <ESEQ field> * 65536 + <sequence
number field of the RTP Fixed Header>
Figure 2 specifies the structure of the payload header. Fields are interpreted as unsigned binary integers in network order.
図2は、ペイロードヘッダーの構造を指定しています。フィールドは、ネットワークの順序で符号なしのバイナリ整数として解釈されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MH | TP |ORDH |P|XTRAC| PTSTAMP | ESEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|C| RSVD |*| PRIMS | TRANS | MAT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| XTRAB |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* RANGE
Figure 2: Structure of the Main Packet Payload Header
図2：メインパケットペイロードヘッダーの構造
MH (Codestream Main Header Presence):
MH（Codestream Main Headerの存在）：
2 bits
2ビット
0
0
The RTP packet is a Body Packet.
RTPパケットはボディパケットです。
1
1
The RTP packet is a Main Packet, and the codestream has more than one Main Packet. The next RTP packet is a Main Packet.
RTPパケットはメインパケットであり、コードストリームには複数のメインパケットがあります。次のRTPパケットはメインパケットです。
2
2
The RTP packet is a Main Packet, and the codestream has more than one Main Packet. The next RTP packet is a Body Packet.
RTPパケットはメインパケットであり、コードストリームには複数のメインパケットがあります。次のRTPパケットはボディパケットです。
3
3
The RTP packet is a Main Packet, and the codestream has exactly one Main Packet.
RTPパケットはメインパケットであり、Codestreamにはちょうど1つのメインパケットがあります。
TP (Image Type):
TP（画像タイプ）：
3 bits
3ビット
Indicates the scanning structure of the image to which the payload belongs.
ペイロードが属する画像のスキャン構造を示します。
0
0
Progressive frame.
プログレッシブフレーム。
1
1
Field 1 of an interlaced frame, where the first line of the field is the first line of the frame.
インターレースフレームのフィールド1。フィールドの最初の行はフレームの最初の行です。
2
2
Field 2 of an interlaced frame, where the first line of the field is the second line of the frame.
インターレースフレームのフィールド2。フィールドの最初の行はフレームの2行目です。
3
3
Field 1 of an interlaced frame, where the first line of the field is the second line of the frame.
インターレースフレームのフィールド1。フィールドの最初の行はフレームの2行目です。
4
4
Field 2 of an interlaced frame, where the first line of the field is the first line of the frame.
インターレースフレームのフィールド2。フィールドの最初の行はフレームの最初の行です。
5
5
Segment 1 of a progressive segmented frame, where the first line of the image is the first line of the frame.
画像の最初の行はフレームの最初の行があります。
6
6
Segment 2 of a progressive segmented frame, where the first line of the image is the second line of the frame.
プログレッシブセグメントフレームのセグメント2。画像の最初の行はフレームの2行目です。
7
7
Extension value. See Sections 8.6 and 7.8.
拡張値。セクション8.6および7.8を参照してください。
ORDH (Progression Order Flag, Main Packet):
ORDH（進行順序フラグ、メインパケット）：
3 bits
3ビット
Specifies the progression order used by the codestream and whether resync points are signaled. See Section 3 for details about progression orders.
Codestreamが使用する進行順序と、再同期ポイントが信号を受けるかどうかを指定します。進行順序の詳細については、セクション3を参照してください。
0
0
Resync points are not necessarily signaled. The progression order can vary over the codestream.
再配置点は必ずしも信号ではありません。進行順序は、コードストリームによって異なる場合があります。
1
1
The progression order is LRCP for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.
進行順序は、コードストリーム全体のLRCPです。最初の再配置点は、1つ以上の再配置点を含むすべてのボディパケットで指定されています。
2
2
The progression order is RLCP for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.
進行順序は、コードストリーム全体のRLCPです。最初の再配置点は、1つ以上の再配置点を含むすべてのボディパケットで指定されています。
3
3
The progression order is RPCL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.
進行順序は、コードストリーム全体のRPCLです。最初の再配置点は、1つ以上の再配置点を含むすべてのボディパケットで指定されています。
4
4
The progression order is PCRL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.
進行順序は、コードストリーム全体のPCRLです。最初の再配置点は、1つ以上の再配置点を含むすべてのボディパケットで指定されています。
5
5
The progression order is CPRL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.
進行順序は、コードストリーム全体のCPRLです。最初の再配置点は、1つ以上の再配置点を含むすべてのボディパケットで指定されています。
6
6
The progression order is PRCL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.
進行順序は、コードストリーム全体のPRCLです。最初の再配置点は、1つ以上の再配置点を含むすべてのボディパケットで指定されています。
7
7
The progression order can vary over the codestream. The first resync point is specified in every Body Packet that contains one or more resync points.
進行順序は、コードストリームによって異なる場合があります。最初の再配置点は、1つ以上の再配置点を含むすべてのボディパケットで指定されています。
ORDH MUST be 0 if the codestream consists of more than one tile.
コードストリームが複数のタイルで構成されている場合、ORDHは0でなければなりません。
NOTE 1: Only ORDH = 4 and ORDH = 6 allow sub-codestream latency streaming.
注1：ORDH = 4とORDH = 6のみがサブコデストリームのレイテンシストリーミングを許可します。
NOTE 2: Progression order PRCL is defined in [JPEG2000-2]. The other progression orders are specified in [JPEG2000-1].
注2：進行順序PRCLは[JPEG2000-2]で定義されています。他の進行順序は[JPEG2000-1]で指定されています。
P (Precision Timestamp Presence):
P（精密タイムスタンプの存在）：
1 bit
1ビット
0
0
PTSTAMP is not used.
PTStampは使用されていません。
1
1
PTSTAMP is used.
PTStampが使用されます。
XTRAC (Extension Payload Length):
Xtrac（拡張ペイロード長）：
3 bits
3ビット
Length, in multiples of 4 bytes, of the XTRAB field.
長さ、4バイトの倍数、Xtrabフィールド。
PTSTAMP (Precision Timestamp):
ptStamp（精密タイムスタンプ）：
12 bits
12ビット
PTSTAMP = (timestamp + TOFF) mod 4096, if P = 1 in the Main Packet of this codestream.
ptStamp =（タイムスタンプ + toff）mod 4096、このコードストリームのメインパケットのp = 1の場合。
TOFF is the transmission time of this RTP packet, in the timebase of the timestamp clock and relative to the first RTP packet with the same timestamp value.
Toffは、このRTPパケットの送信時間であり、タイムスタンプクロックのタイムベースで、同じタイムスタンプ値を持つ最初のRTPパケットに対するものです。
TOFF = 0 in the first RTP packet with the same timestamp value.
同じタイムスタンプ値を持つ最初のRTPパケットのtoff = 0。
PTSTAMP = 0, if P = 0 in the Main Packet of this codestream.
ptStamp = 0、このコードストリームのメインパケットのp = 0の場合。
NOTE 3: As described in Sections 7.4 and 8.1, PTSTAMP is intended to improve clock recovery at the receiver and only applies when the transmission time of two consecutive RTP packets with identical timestamp fields differ by no more than 45 ms (which is 4095/90,000). [RFC5450] addresses the general case when an RTP packet is transmitted at a time other than its nominal transmission time.
注3：セクション7.4および8.1で説明されているように、PTStampはレシーバーでのクロックリカバリを改善することを目的としており、同一のタイムスタンプフィールドを持つ2つの連続したRTPパケットの送信時間が45ミリ秒以下（4095/90,000）が異なる場合にのみ適用されます。[RFC5450]は、RTPパケットが公称送信時間以外に送信される場合の一般的なケースに対処します。
ESEQ (Extended Sequence Number High-Order Bits):
ESEQ（拡張シーケンス番号高次ビット）：
8 bits
8ビット
The high-order bits of the extended sequence number.
拡張シーケンス番号の高次ビット。
NOTE 4: The low-order bits of the extended sequence number are stored in the sequence number field of the RTP Fixed Header.
注4：拡張シーケンス番号の低次ビットは、RTP固定ヘッダーのシーケンス番号フィールドに保存されます。
Section 5.2 specifies the formula to compute the extended sequence number.
セクション5.2は、拡張シーケンス番号を計算する式を指定します。
R (Codestream Main Header Reuse):
R（Codestream Main Header Reuse）：
1 bit
1ビット
Determines whether Main Packet and codestream main header information can be reused across codestreams.
メインパケットとコードストリームのメインヘッダー情報をコードストリーム間で再利用できるかどうかを判断します。
1
1
All Main Packets in this stream, as identified by the value of the SSRC field in the RTP Fixed Header:
RTP固定ヘッダーのSSRCフィールドの値によって識別されるように、このストリーム内のすべてのメインパケット：
* MUST have identical Main Packet Payload Headers, with the exception of their TP, MH, ESEQ, and PTSTAMP fields;
* TP、MH、ESEQ、およびPTSTAMPフィールドを除き、同じメインパケットペイロードヘッダーが必要です。
* MUST contain the same codestream main header information (with the exception of the SOT and COM marker segments and any pointer marker segments); and
* 同じコードストリームメインヘッダー情報を含める必要があります（SOTおよびCOMマーカーセグメントとポインターマーカーセグメントを除く）。そして
* MUST NOT contain bytes other than Extended Header bytes.
* 拡張ヘッダーバイト以外のバイトを含めてはなりません。
0
0
Otherwise
さもないと
S (Parameterized Colorspace Presence):
s（パラメーター化されたカラースペースの存在）：
1 bit
1ビット
0
0
Component colorimetry is not specified; it is left to the session or the application.
コンポーネントの比色測定は指定されていません。セッションまたはアプリケーションに任されています。
PRIMS, TRANS, MAT, and RANGE MUST be zero.
プライム、トランス、マット、および範囲はゼロでなければなりません。
1
1
Component colorimetry is specified by the PRIMS, TRANS, MAT, and RANGE fields.
コンポーネントの比色測定は、プリム、トランス、マット、および範囲フィールドによって指定されています。
The codestream components MUST conform to one of the combinations in Table 1.
Codestreamコンポーネントは、表1の組み合わせの1つに準拠する必要があります。
+==================+====================+
| Combination Name | Component Index |
| +====+=====+=====+===+
| | 0 | 1 | 2 | 3 |
+==================+====+=====+=====+===+
| Y | Y | | | |
+==================+----+-----+-----+---+
| YA | Y | A | | |
+==================+----+-----+-----+---+
| RGB | R | G | B | |
+==================+----+-----+-----+---+
| RGBA | R | G | B | A |
+==================+----+-----+-----+---+
| YCbCr | Y | C_B | C_R | |
+==================+----+-----+-----+---+
| YCbCrA | Y | C_B | C_R | A |
+==================+----+-----+-----+---+
Table 1: Mapping of Codestream Components to Color Channels
表1：Codestreamコンポーネントのカラーチャネルへのマッピング
Channel A is an opacity channel. The minimum sample value (0) indicates a completely transparent sample, and the maximum sample value (as determined by the bit depth of the codestream component) indicates a completely opaque sample. The opacity channel MUST map to a component with unsigned samples.
チャネルAは不透明なチャネルです。最小サンプル値（0）は完全に透明なサンプルを示し、最大サンプル値（コードストリームコンポーネントのビット深度で決定）は完全に不透明なサンプルを示します。不透明チャネルは、署名されていないサンプルを持つコンポーネントにマッピングする必要があります。
C (Code-Block Caching Usage):
C（コードブロックキャッシングの使用）：
1 bit
1ビット
0
0
Code-block caching is not in use.
コードブロックキャッシュは使用されていません。
1
1
Code-block caching is in use.
コードブロックキャッシュが使用されています。
R MUST be equal to 1.
rは1に等しくなければなりません。
RSVD (Reserved):
RSVD（予約済み）：
4 bits
4ビット
Unassigned value. See Sections 8.5 and 7.7.
割り当てられていない値。セクション8.5および7.7を参照してください。
RANGE (Video Full Range Usage):
範囲（ビデオフルレンジの使用）：
1 bit
1ビット
Value of the VideoFullRangeFlag specified in [REC-ITU-T-H273].
[Rec-Itu-T-H273]で指定されたVideoFullrangeFlagの値。
PRIMS (Color Primaries):
プリム（色のプライマリー）：
8 bits
8ビット
One of the ColourPrimaries values specified in [REC-ITU-T-H273].
[rec-itu-t-H273]で指定されている色の値の1つ。
TRANS (Transfer Characteristics):
trans（転送特性）：
8 bits
8ビット
One of the TransferCharacteristics values specified in [REC-ITU-T-H273].
[rec-itu-t-H273]で指定されたトランスファーチャレクテリーの値の1つ。
MAT (Color Matrix Coefficients):
MAT（カラーマトリックス係数）：
8 bits
8ビット
One of the MatrixCoefficients values specified in [REC-ITU-T-H273].
[rec-itu-t-H273]で指定されたマトリックスコーチエンス値の1つ。
XTRAB (Extension Payload):
Xtrab（拡張ペイロード）：
variable
変数
Allows the contents of the Main Packet Payload Header to be extended in the future. The size of the field is determined by Section 5.3. See also Sections 8.4 and 7.6.
メインパケットペイロードヘッダーのコンテンツを将来拡張できるようにします。フィールドのサイズは、セクション5.3で決定されます。セクション8.4および7.6も参照してください。
Figure 3 specifies the structure of the Body Packet Payload Header. Fields are interpreted as unsigned binary integers in network order.
図3ボディパケットペイロードヘッダーの構造を指定します。フィールドは、ネットワークの順序で符号なしのバイナリ整数として解釈されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MH | TP |RES |*|QUAL | PTSTAMP | ESEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS | PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* ORDB
Figure 3: Structure of the Body Packet Payload Header
図3：ボディパケットペイロードヘッダーの構造
MH:
MH:
See Section 5.3.
セクション5.3を参照してください。
TP:
TP:
See Section 5.3.
セクション5.3を参照してください。
RES (Resolution Levels):
解像度（解像度レベル）：
3 bits
3ビット
0
0
The payload can contribute to all resolution levels.
ペイロードは、すべての解像度レベルに寄与する可能性があります。
Otherwise
さもないと
The payload contains at least one byte of one JPEG 2000 packet belonging to resolution level (N_L + RES - 7) but does not contain any byte of any JPEG 2000 packet belonging to lower resolution levels. N_L is the number of decomposition levels of the codestream.
ペイロードには、解像度レベル（N_L + RES -7）に属する1つのJPEG 2000パケットの少なくとも1つのバイトが含まれていますが、低解像度レベルに属するJPEG 2000パケットのバイトは含まれていません。N_Lは、コードストリームの分解レベルの数です。
ORDB (Progression Order Flag, Body Packet):
ORDB（進行順序フラグ、ボディパケット）：
1 bit
1ビット
0
0
No resync point is specified for the payload.
ペイロードには再配置点が指定されていません。
1
1
The payload contains a resync point.
ペイロードには再配置点が含まれています。
ORDB MUST be 0 if the codestream consists of more than one tile.
コードストリームが複数のタイルで構成されている場合、ORDBは0でなければなりません。
QUAL (Quality Layers):
qual（Quality Layers）：
3 bits
3ビット
0
0
The payload can contribute to all quality layers.
ペイロードは、すべての品質レイヤーに寄与する可能性があります。
Otherwise
さもないと
The payload contributes only to quality layer index QUAL or above.
ペイロードは、品質レイヤーインデックスの品質以上にのみ貢献します。
PTSTAMP:
ptStamp：
See Section 5.3.
セクション5.3を参照してください。
ESEQ:
ESEQ：
See Section 5.3.
セクション5.3を参照してください。
POS (Resync Point Offset):
POS（Resync Pointオフセット）：
12 bits
12ビット
Byte offset from the start of the payload to the first byte of the resync point belonging to the precinct identified by PID.
ペイロードの開始から、PIDによって識別された境内に属するレジンポイントの最初のバイトへのバイトオフセット。
POS MUST be 0 if ORDB = 0.
ordb = 0の場合、posは0でなければなりません。
PID (Precinct Identifier):
PID（境内識別子）：
20 bits
20ビット
Unique identifier of the precinct of the resync point.
再同期ポイントの境内の一意の識別子。
PID = c + s * num_components
where:
ただし：
c:
c:
Index (starting from 0) of the image component to which the precinct belongs.
境内が属する画像コンポーネントのインデックス（0から始まる）。
s:
s:
Sequence number that identifies the precinct within its tile-component.
タイルコンポーネント内の境内を識別するシーケンス番号。
num_components:
num_components：
Number of components of the codestream.
Codestreamのコンポーネント数。
If PID is present, the payload MUST NOT contain codestream bytes from more than one precinct.
PIDが存在する場合、ペイロードには複数の境内からのコードストリームバイトが含まれてはなりません。
PID MUST be 0 if ORDB = 0.
ordb = 0の場合、pidは0でなければなりません。
NOTE: PID is identical to precinct identifier I specified in [JPEG2000-9].
注：PIDは、[jpeg2000-9]で指定された境内識別子と同一です。
A JPEG 2000 codestream consists of the bytes between, and including, the SOC and EOC markers, as defined in [JPEG2000-1].
JPEG 2000 Codestreamは、[JPEG2000-1]で定義されているように、SOCマーカーとEOCマーカーの間でバイトを含むバイトで構成されています。
The JPEG 2000 codestream MAY include capabilities beyond those specified in [JPEG2000-1], including those specified in [JPEG2000-2] and [JPEG2000-15].
JPEG 2000 Codestreamには、[JPEG2000-2]および[JPEG2000-15]で指定されたものを含む[JPEG2000-1]で指定されたものを超えた機能を含む機能が含まれている場合があります。
NOTE 1: The Rsiz parameter and CAP marker segments of each JPEG 2000 codestream contain detailed information on the capabilities necessary to decode the codestream.
注1：各JPEG 2000 CodestreamのRSIZパラメーターとキャップマーカーセグメントには、コードストリームのデコードに必要な機能に関する詳細情報が含まれています。
NOTE 2: The caps media type parameter defined in Section 9.2 allows applications to signal required device capabilities.
注2：セクション9.2で定義されているCAPSメディアタイプパラメーターを使用すると、アプリケーションが必要なデバイス機能を信号することができます。
NOTE 3: The block coder specified in [JPEG2000-15] improves throughput and reduces latency compared to the original arithmetic block coder defined in [JPEG2000-1].
注3：[jpeg2000-15]で指定されたブロックコーダーは、[JPEG2000-1]で定義された元の算術ブロックコーダーと比較して、スループットを改善し、レイテンシを減らします。
For interlaced or progressive segmented frames, the height specified in the JPEG 2000 main header MUST be the height in lines of the field or the segment, respectively.
インターレースまたはプログレッシブセグメント化されたフレームの場合、JPEG 2000メインヘッダーで指定された高さは、それぞれフィールドまたはセグメントのラインの高さでなければなりません。
If any decomposition level involves only horizontal decomposition, then no decomposition level MUST involve only vertical decomposition; conversely, if any decomposition level involves only vertical decomposition, then no decomposition level MUST involve only horizontal decomposition.
分解レベルが水平分解のみを伴う場合、分解レベルは垂直分解のみを伴う必要はありません。逆に、分解レベルが垂直分解のみを伴う場合、分解レベルは水平分解のみを伴う必要がありません。
A Main Packet MAY contain zero or more bytes of the JPEG 2000 codestream Extended Header.
メインパケットには、JPEG 2000 Codestream拡張ヘッダーのゼロ以上のバイトが含まれている場合があります。
The sender MUST emit either a single Main Packet with MH = 3, or one or more Main Packets with MH = 1 followed by a single Main Packet with MH = 2.
送信者は、MH = 3の単一のメインパケット、またはMH = 1の1つ以上のメインパケットのいずれかを放出する必要があります。その後、MH = 2の単一のメインパケットが続きます。
The Main Packet Payload Headers fields MUST be identical in all Main Packets of a given codestream, with the exception of:
メインパケットペイロードヘッダーフィールドは、次のことを除いて、特定のコードストリームのすべてのメインパケットで同じでなければなりません。
* MH;
* MH;
* ESEQ; and
* ESEQ;そして
* PTSTAMP.
* ptStamp。
An intermediate system MAY strip out RTP packets from a codestream that are of no interest to a particular client, e.g., based on a resolution or a spatial region of interest.
中間システムは、特定のクライアントにとって興味のないコードストリームからRTPパケットを取り除くことができます。
A resync point is the first byte of JPEG 2000 packet header data for a precinct and for which PID < 2^24.
再配置点は、境内のJPEG 2000パケットヘッダーデータの最初のバイトであり、PID <2^24です。
NOTE 1: Resync points cannot be specified if the codestream consists of more than one tile (ORDB and ORDH are both equal to zero).
注1：コードストリームが複数のタイルで構成されている場合、再同期ポイントを指定できません（ORDBとORDHは両方ともゼロに等しい）。
NOTE 2: A resync point can be used by a receiver to process a codestream even if earlier RTP packets in the codestream have been corrupted, lost, or deliberately discarded by an intermediate system. As a corollary, resync points can be used by an intermediate system to discard RTP packets that are not relevant to a given rendering resolution or region of interest. Resync points play a role similar to pointer marker segments, albeit tailored for high-bandwidth, low-latency streaming applications.
注2：コードストリームの以前のRTPパケットが中間システムによって破損、紛失、または意図的に破棄された場合でも、コードストリームを処理するためにレシーバーが再配置点を使用できます。結果として、中間システムでは、特定のレンダリング解像度または関心地域に関連しないRTPパケットを破棄するために、中間システムでレジンポイントを使用できます。リセンツポイントは、高帯域幅の低遅延ストリーミングアプリケーションに合わせて調整されていますが、ポインターマーカーセグメントと同様の役割を果たします。
A sender SHOULD set P = 1, but only if it can generate PTSTAMP accurately.
送信者はp = 1を設定する必要がありますが、PTStampを正確に生成できる場合のみです。
PTSTAMP can be derived from the same clock that is used to produce the 32-bit timestamp field in the RTP Fixed Header. Specifically, a sender maintains, at least conceptually, a 32-bit counter that is incremented by a 90 kHz clock. The counter is sampled at the point in time when each RTP packet is transmitted and the 12 least significant bits of the sample are stored in the PTSTAMP field.
PTStampは、RTP固定ヘッダーで32ビットタイムスタンプフィールドを生成するために使用される同じクロックから導出できます。具体的には、送信者は、少なくとも概念的には、90 kHzの時計で増加する32ビットカウンターを維持します。カウンターは、各RTPパケットが送信される時点でサンプリングされ、サンプルの12ビットがPTStampフィールドに保存されます。
If P = 1, then the transmission time TOFF (as defined in Section 5.3) for two consecutive RTP packets with identical timestamp fields MUST NOT differ by more than 4095.
p = 1の場合、同一のタイムスタンプフィールドを持つ2つの連続したRTPパケットの伝送時間toff（セクション5.3で定義）は、4095を超えて違いはありません。
A sender SHOULD set RES > 0 whenever possible.
送信者は、可能な限りRES> 0を設定する必要があります。
NOTE: While a sender can always safely set RES = 0, this makes it more difficult to discard RTP packets based on resolution, as described in Section 8.3.
注：送信者はいつでもRES = 0を安全に設定できますが、セクション8.3で説明されているように、解像度に基づいてRTPパケットを破棄することがより困難になります。
The sender MUST set the value of XTRAC to 0.
送信者は、XTRACの値を0に設定する必要があります。
Future updates to this RTP payload format can permit other values.
このRTPペイロード形式の将来の更新により、他の値が許可されます。
The sender MUST set unassigned values to 0.
送信者は、未割り当ての値を0に設定する必要があります。
Unassigned values are available for assignment by future updates to this RTP payload format. As specified in Section 8.5, these future assigned values are ignored by receivers that conform to this specification. In contrast to extension values (see Section 7.8), this mechanism allows updates to this RTP payload format that remain compatible with receivers that conform to this specification.
このRTPペイロード形式の将来の更新により、割り当てされていない値が割り当てられます。セクション8.5で指定されているように、これらの将来の割り当てられた値は、この仕様に準拠する受信機によって無視されます。拡張値とは対照的に（セクション7.8を参照）、このメカニズムは、この仕様に準拠した受信機と互換性があるこのRTPペイロード形式の更新を許可します。
A sender MUST NOT use an extension value.
送信者は拡張値を使用してはなりません。
This section only applies if C = 1.
このセクションは、C = 1の場合にのみ適用されます。
A sender can improve bandwidth efficiency by only occasionally transmitting code-blocks corresponding to static portions of the video and otherwise transmitting empty code-blocks. When C = 1, a receiver maintains a simple cache of previously received code-blocks, which it uses to replace empty code-blocks (see Section 8.7).
送信者は、ビデオの静的部分に対応するコードブロックを送信し、その他の場合は空のコードブロックを送信することにより、帯域幅の効率を改善できます。C = 1の場合、受信者は、空のコードブロックを置き換えるために使用される以前に受信したコードブロックの単純なキャッシュを維持します（セクション8.7を参照）。
A sender alone determines which code-blocks are replaced with empty code-blocks and when the replacement occurs.
送信者だけが、どのコードブロックが空のコードブロックに置き換えられ、いつ交換が発生するかを決定します。
The sender cannot, however, determine with certainty the state of the receiver's cache; for example, some code-blocks might have been lost in transit, the sender doesn't know exactly when the receiver started processing the stream, etc.
ただし、送信者は、受信者のキャッシュの状態を確実に決定することはできません。たとえば、一部のコードブロックは輸送中に失われた可能性があり、送信者はレシーバーがいつストリームの処理を開始したかなどを正確に知りません。
A code-block is _empty_ if:
コードブロックは_empty_ if：
* it does not contribute code-bytes as specified in the parent JPEG 2000 packet header; or
* 親JPEG 2000パケットヘッダーで指定されているように、コードバイトには寄与しません。または
* it contains an HT cleanup segment and the first two bytes of the Magsgn byte-stream are between 0xFF80 and 0xFF8F (if the code-block conforms to [JPEG2000-15]).
* HTクリーンアップセグメントが含まれており、MAGSGNバイトストリームの最初の2バイトは0xff80〜0xff8fの間です（コードブロックが[jpeg2000-15]に適合している場合）。
NOTE: The last condition allows the encoder to insert padding bytes to achieve a constant bit rate even when a code-block does not contribute code-bytes, as suggested in Annex F.4 of [JPEG2000-15].
注：最後の条件により、エンコーダは、[JPEG2000-15]の付録F.4で示唆されているように、コードブロックがコードバイに寄与していない場合でも、パディングバイトを挿入して一定のビットレートを実現できます。
Receivers can use PTSTAMP values to accelerate sender clock recovery since PTSTAMP typically updates more regularly than timestamp.
PTStampは通常、タイムスタンプよりも定期的に更新されるため、受信者はPTStamp値を使用して送信者時計回復を加速できます。
A receiver can discard RTP packets where QUAL > N if it is interested in reconstructing an image that only incorporates quality layers N and below.
レシーバーは、品質のレイヤーN以下のみを組み込んだ画像の再構築に関心がある場合、QUAL> Nの場合、RTPパケットを廃棄できます。
The JPEG 2000 coding process decomposes an image using a sequence of discrete wavelet transform (DWT) stages.
JPEG 2000コーディングプロセスは、一連の離散ウェーブレット変換（DWT）段階を使用して画像を分解します。
+===============+============+=============+===========+============+
| Decomposition | Resolution | Sub-bands | Keep all | ...to |
| Level | Level | | Body | decode an |
| | | | Packets | image with |
| | | | with RES | at most |
| | | | equal to | these |
| | | | or less | dimensions |
| | | | than | |
| | | | this | |
| | | | value... | |
+===============+============+=============+===========+============+
| 1 | 5 | HL1,LH1,HH1 | 7 | W x H |
+---------------+------------+-------------+-----------+------------+
| 2 | 4 | HL2,LH2,HH2 | 6 | (W/2) x |
| | | | | (H/2) |
+---------------+------------+-------------+-----------+------------+
| 3 | 3 | HL3,LH3,HH3 | 5 | (W/4) x |
| | | | | (H/4) |
+---------------+------------+-------------+-----------+------------+
| 4 | 2 | HL4,LH4,HH4 | 4 | (W/8) x |
| | | | | (H/8) |
+---------------+------------+-------------+-----------+------------+
| 5 | 1 | HL5,LH5,HH5 | 3 | (W/16) x |
| | | | | (H/16) |
+---------------+------------+-------------+-----------+------------+
| 5 | 0 | LL5 | 2 | (W/32) x |
| | | | | (H/32) |
+---------------+------------+-------------+-----------+------------+
Table 2: Optional discarding of Body Packets based on the value of the RES field when decoding a reduced resolution image, in the case where N_L = 5 and all DWT stages consist of both horizontal and vertical transforms. The image has nominal width and height of W x H.
表2：N_L = 5およびすべてのDWTステージが水平変換と垂直変換の両方で構成されている場合、RESフィールドの値に基づいて、RESフィールドの値に基づいてボディパケットのオプションの破棄。画像は、w x Hの公称幅と高さを持っています。
Table 2 illustrates the case where each DWT stage consists of both horizontal and vertical transforms, which is the only mode supported in [JPEG2000-1]. The first stage transforms the image into (i) the image at half-resolution (LL1 sub-bands) and (ii) residual high-frequency data (HH1, LH1, HL1 sub-bands). The second stage transforms the image at half-resolution (LL1 sub-bands) into the image at quarter resolution (LL2 sub-bands) and residual high-frequency data (HH2, LH2, HL2 sub-bands). This process is repeated N_L times, where N_L is the number of decomposition levels as defined in the COD and COC marker segments of the codestream.
表2は、各DWT段階が水平変換と垂直変換の両方で構成されている場合を示しています。これは[JPEG2000-1]でサポートされている唯一のモードです。最初の段階では、画像を（i）半分分解能（LL1サブバンド）および（II）残留高周波データ（HH1、LH1、HL1サブバンド）の画像に変換します。第2段階では、半解像度（LL1サブバンド）で画像を四半期解像度（LL2サブバンド）および残留高周波データ（HH2、LH2、HL2サブバンド）の画像に変換します。このプロセスは繰り返されます。N_Lは、コードストリームのCODおよびCOCマーカーセグメントで定義されている分解レベルの数です。
The decoding process reconstructs the image by reversing the coding process, starting with the lowest resolution image stored in the codestream (LL_(N_L)).
デコードプロセスは、コードストリーム（LL_（N_L））に保存されている最低解像度画像から始まるコーディングプロセスを逆にすることにより、画像を再構築します。
As a result, it is possible to reconstruct a lower resolution of the image by stopping the decoding process at a selected stage. For example, in order to reconstruct the image at quarter resolution (LL2), only sub-bands with index greater than 2 (e.g., HL3, LH3, HH3, HL4, LH4, HH4, etc.) are necessary. In other words, a receiver that wishes to reconstruct an image at quarter resolution could discard all RTP packets where RES >= 6 since those RTP packets can only contribute to HL1, LH1, HH1, HL2, LH2, and HH2 sub-bands.
その結果、選択した段階でデコードプロセスを停止することにより、画像の低解像度を再構築することができます。たとえば、四半期解像度（LL2）で画像を再構築するには、インデックスが2を超えるサブバンドのみ（例：HL3、LH3、HH3、HL4、LH4、HH4など）が必要です。言い換えれば、四半期解像度で画像を再構築したいレシーバーは、これらのRTPパケットがHL1、LH1、HH1、HL2、LH2、LH2、およびHH2サブバンドのみに寄与できるため、RES> = 6ですべてのRTPパケットを破棄できます。
In the case where all DWT stages consist of both horizontal and vertical transforms, the maximum decodable resolution is reduced by a factor of 2^(7 - N) if all Body Packets where RES > N are discarded.
すべてのDWTステージが水平変換と垂直変換の両方で構成されている場合、RES> nが破棄されるすべてのボディパケットの場合、最大デコード可能な解像度は2^（7 -n）係数を減らします。
+===============+============+=============+===========+============+
| Decomposition | Resolution | Sub-bands | Keep all | ...to |
| Level | Level | | Body | decode an |
| | | | Packets | image with |
| | | | with RES | at most |
| | | | equal to | these |
| | | | or less | dimensions |
| | | | than | |
| | | | this | |
| | | | value... | |
+===============+============+=============+===========+============+
| 1 | 5 | HL1,LH1,HH1 | 7 | W x H |
+---------------+------------+-------------+-----------+------------+
| 2 | 4 | HL2,LH2,HH2 | 6 | (W/2) x |
| | | | | (H/2) |
+---------------+------------+-------------+-----------+------------+
| 3 | 3 | HX3 | 5 | (W/4) x |
| | | | | (H/2) |
+---------------+------------+-------------+-----------+------------+
| 4 | 2 | HX4 | 4 | (W/8) x |
| | | | | (H/2) |
+---------------+------------+-------------+-----------+------------+
| 5 | 1 | HX5 | 3 | (W/16) x |
| | | | | (H/2) |
+---------------+------------+-------------+-----------+------------+
| 5 | 0 | LX5 | 2 | (W/32) x |
| | | | | (H/2) |
+---------------+------------+-------------+-----------+------------+
Table 3: Optional discarding of Body Packets based on the value of the RES field when decoding a reduced resolution image, in the case where N_L = 5 and some DWT stages consist of only horizontal transforms. The image has nominal width and height of W x H.
表3：N_L = 5および一部のDWTステージが水平変換のみで構成されている場合、RESフィールドの値に基づいて、RESフィールドの値に基づいてボディパケットのオプションの破棄。画像は、w x Hの公称幅と高さを持っています。
Table 3 illustrates the case where some DWT stages consist of only horizontal transforms, as specified in Annex F of [JPEG2000-2].
表3は、[JPEG2000-2]の付録Fで指定されているように、いくつかのDWTステージが水平変換のみで構成される場合を示しています。
A receiver can therefore discard all Body Packets where RES is greater than some threshold value if it is interested in decoding an image with its resolution reduced by a factor determined by the threshold value, as illustrated in Tables 2 and 3.
したがって、レシーバーは、表2および3に示すように、しきい値値によって決定される係数によって解像度を減らして画像をデコードすることに関心がある場合、RESが一部のしきい値よりも大きい場合のすべてのボディパケットを廃棄できます。
The receiver MUST accept values of XTRAC other than 0 and MUST ignore the value of XTRAB, whose length is given by XTRAC.
受信者は、0以外のXTRACの値を受け入れる必要があり、長さがXTRACによって与えられるXTRABの値を無視する必要があります。
Future updates to this RTP payload format can specify XTRAB contents such that this content can be ignored by receivers that conform to this specification.
このRTPペイロード形式の将来の更新では、この仕様に準拠した受信機によってこのコンテンツを無視できるように、Xtrabコンテンツを指定できます。
The receiver MUST ignore unassigned values (see additional discussion in Section 7.7).
受信者は、未割り当ての値を無視する必要があります（セクション7.7の追加の説明を参照）。
The receiver MUST discard an RTP packet that contains any extension value.
レシーバーは、拡張値を含むRTPパケットを廃棄する必要があります。
This section only applies if C = 1.
このセクションは、C = 1の場合にのみ適用されます。
When C = 1, the sender can improve bandwidth efficiency by only occasionally transmitting code-blocks corresponding to static portions of the video and otherwise transmitting empty code-blocks (see Section 7.9).
C = 1の場合、送信者は、ビデオの静的部分に対応するコードブロックを送信し、その他の場合は空のコードブロックを送信することにより、帯域幅の効率を改善できます（セクション7.9を参照）。
When decoding a codestream, the following procedures apply for each code-block in the codestream:
コードストリームをデコードするとき、コードストリームの各コードブロックに次の手順が適用されます。
* If the code-block in the codestream is empty, the receiver MUST replace it with a matching code-block from the cache, if one exists.
* コードストリームのコードブロックが空の場合、レシーバーは、存在する場合、キャッシュから一致するコードブロックに置き換える必要があります。
* If the code-block in the codestream is not empty, the receiver MUST replace any matching code-block from the cache with the code-block in the codestream.
* コードストリームのコードブロックが空でない場合、レシーバーは、キャッシュから一致するコードブロックをコードストリームのコードブロックに置き換える必要があります。
Two code-blocks are _matching_ if the following characteristics are identical for both: spatial coordinates, resolution level, component, sub-band, and value of the TP field of the parent RTP packet.
次の特性が両方の場合に同一である場合、2つのコードブロックは_Matching_です。親RTPパケットのTPフィールドの分解レベル、コンポーネント、サブバンド、および値。
This RTP payload format is identified using the media type defined in Section 9.2. This media type has been registered in accordance with [RFC4855] using the template in [RFC6838].
このRTPペイロード形式は、セクション9.2で定義されているメディアタイプを使用して識別されます。このメディアタイプは、[RFC6838]のテンプレートを使用して[RFC4855]に従って登録されています。
Type name:
タイプ名：
video
ビデオ
Subtype name:
サブタイプ名：
jpeg2000-scl
JPEG2000-SCL
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
pixel:
ピクセル：
Specifies the pixel format used by the video sequence.
ビデオシーケンスで使用されるピクセル形式を指定します。
The parameter MUST be a URI-reference as specified in [RFC3986].
[RFC3986]で指定されているように、パラメーターはURI参照でなければなりません。
If the parameter is a relative-ref as specified in [RFC3986], then it MUST be equal to one of the pixel formats specified in Table 4, and the RTP header and payload MUST conform to the characteristics of that pixel format.
パラメーターが[RFC3986]で指定されている相対REFである場合、表4で指定されたピクセル形式のいずれかに等しく、RTPヘッダーとペイロードはそのピクセル形式の特性に準拠する必要があります。
If the parameter is not a relative-ref, the specification of the pixel format is left to the application that defined the URI.
パラメーターが相対REFでない場合、Pixel形式の仕様はURIを定義したアプリケーションに任されます。
If the parameter is not specified, the pixel format is unspecified.
パラメーターが指定されていない場合、ピクセル形式は特定されていません。
sample:
サンプル：
Specifies the format of the samples in each component of the codestream.
Codestreamの各コンポーネントのサンプルの形式を指定します。
The parameter MUST be a URI-reference as specified in [RFC3986].
[RFC3986]で指定されているように、パラメーターはURI参照でなければなりません。
If the parameter is a relative-ref as specified in [RFC3986], then it MUST be equal to one of the formats specified in Appendix C, and the stream MUST conform to the characteristics of that format.
パラメーターが[RFC3986]で指定されている相対REFである場合、付録Cで指定された形式の1つに等しく、ストリームはその形式の特性に適合する必要があります。
If the parameter is not a relative-ref, the specification of the sample format is left to the application that defined the URI.
パラメーターが相対REFでない場合、サンプル形式の仕様はURIを定義したアプリケーションに任されます。
If the parameter is not specified, the sample format is unspecified.
パラメーターが指定されていない場合、サンプル形式は特定されていません。
width:
幅：
Maximum width in pixels of each image. Integer between 0 and 4,294,967,295.
各画像のピクセルの最大幅。0〜4,294,967,295の整数。
The parameter MUST be a sequence of 1 or more digits.
パラメーターは、1桁以上のシーケンスでなければなりません。
If the parameter is not specified, the maximum width is unspecified.
パラメーターが指定されていない場合、最大幅は特定されていません。
height:
身長：
Maximum height in pixels of each image. Integer between 0 and 4,294,967,295.
各画像のピクセルの最大高さ。0〜4,294,967,295の整数。
The parameter MUST be a sequence of 1 or more digits.
パラメーターは、1桁以上のシーケンスでなければなりません。
If the parameter is not specified, the maximum height is unspecified.
パラメーターが指定されていない場合、最大高さは特定されていません。
signal:
信号：
Specifies the sequence of image types.
画像タイプのシーケンスを指定します。
The parameter MUST be a URI-reference as specified in [RFC3986].
[RFC3986]で指定されているように、パラメーターはURI参照でなければなりません。
If the parameter is a relative-ref as specified in [RFC3986], then it MUST be equal to one of the signal formats specified in Appendix B, and the image sequence MUST conform to that signal format.
パラメーターが[RFC3986]で指定されている相対REFである場合、付録Bで指定された信号形式のいずれかに等しく、画像シーケンスはその信号形式に準拠する必要があります。
If the parameter is not a relative-ref, the specification of the pixel format is left to the application that defined the URI.
パラメーターが相対REFでない場合、Pixel形式の仕様はURIを定義したアプリケーションに任されます。
If the parameter is not specified, the stream consists of an arbitrary sequence of image types.
パラメーターが指定されていない場合、ストリームは画像タイプの任意のシーケンスで構成されます。
caps:
キャップ：
The parameter contains a list of sets of constraints to which the stream conforms, with each set of constraints identified using an absolute-URI defined by an application.
パラメーターには、ストリームが適合する制約のセットのリストが含まれており、アプリケーションによって定義された絶対尿を使用して識別される制約の各セットが含まれています。
The parameter MUST conform to the uri-list syntax expressed as follows using ABNF [RFC5234]:
パラメーターは、ABNF [RFC5234]を使用して、次のように表されるURI-List構文に準拠する必要があります。
uri-list = absolute-URI *(";" absolute-URI)
The application that defines the absolute-URI MUST ensure that it does not contain any ";" character and MUST associate it with a set of constraints to which the stream conforms. Such constraints can, for example, include the maximum height and width of images.
絶対尿を定義するアプリケーションは、「;」が含まれていないことを確認する必要があります。キャラクターと、ストリームが適合する一連の制約に関連付けなければなりません。このような制約には、たとえば、画像の最大高さと幅を含めることができます。
If the parameter is not specified, constraints beyond those specified in this document are unspecified.
パラメーターが指定されていない場合、このドキュメントで指定されたものを超える制約は不特定です。
cache:
キャッシュ：
The value of the parameter MUST be either false or true.
パラメーターの値は、falseまたはtrueのいずれかでなければなりません。
If the parameter is true, the field C MAY be 0 or 1; otherwise, the field C MUST be 0.
パラメーターがtrueの場合、フィールドCは0または1になる場合があります。それ以外の場合、フィールドCは0でなければなりません。
If the parameter is not specified, then the parameter is equal to false.
パラメーターが指定されていない場合、パラメーターはfalseに等しくなります。
Encoding considerations:
考慮事項のエンコード：
This media type is framed and binary. See Section 4.8 of [RFC6838].
このメディアタイプはフレームとバイナリです。[RFC6838]のセクション4.8を参照してください。
Security considerations:
セキュリティ上の考慮事項：
JPEG 2000 is a flexible image format. As a result, the size of the memory structures required to process JPEG 2000 images can vary greatly depending on the characteristics of the image and the encoding parameters. For example, the JPEG 2000 syntax allows image height and width up to 2^32 - 1 pixels, which is also captured in the syntax of the height and width parameters of this media type. Therefore, implementations SHOULD take care when processing input that influences the size of memory structures and SHOULD fail gracefully when resource constraints are exceeded.
JPEG 2000は柔軟な画像形式です。その結果、JPEG 2000の画像を処理するために必要なメモリ構造のサイズは、画像の特性とエンコーディングパラメーターによって大きく異なります。たとえば、JPEG 2000構文により、画像の高さと幅が最大2^32-1ピクセルを可能にします。これは、このメディアタイプの高さと幅のパラメーターの構文にもキャプチャされます。したがって、メモリ構造のサイズに影響を与える入力を処理し、リソースの制約を超えたときに優雅に失敗するはずの入力を処理する場合は、実装が注意する必要があります。
See also Section 13.
セクション13も参照してください。
Interoperability considerations:
相互運用性の考慮事項：
The RTP stream is a sequence of JPEG 2000 images. An implementation that conforms to the family of JPEG 2000 standards can decode and attempt to display each image.
RTPストリームは、JPEG 2000画像のシーケンスです。JPEG 2000標準のファミリーに準拠する実装は、各画像をデコードして表示しようとすることができます。
Published specification:
公開された仕様：
RFC 9828
RFC 9828
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
video streaming and communication
ビデオストリーミングとコミュニケーション
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Pierre-Anthony Lemieux <pal@sandflow.com>
Pierre-Anthony lemieux <pal@sandflow.com>
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on Usage:
使用に関する制限：
This media type depends on RTP framing and hence is only defined for use with RTP as specified in [RFC3550]. Transport within other framing protocols is not defined at the time.
このメディアタイプはRTPフレーミングに依存するため、[RFC3550]で指定されているようにRTPで使用するためにのみ定義されます。他のフレーミングプロトコル内の輸送は、当時定義されていません。
Author:
著者：
Pierre-Anthony Lemieux <pal@sandflow.com>
Pierre-Anthony lemieux <pal@sandflow.com>
Change controller:
Change Controller：
IETF
IETF
The mapping of the payload format media type and its parameters to SDP, as specified in [RFC8866], MUST be done according to Section 3 of [RFC4855].
[RFC8866]で指定されているように、ペイロード形式のメディアタイプとそのパラメーターのSDPへのマッピングは、[RFC4855]のセクション3に従って行う必要があります。
Since this RTP payload format can be used in a variety of applications across many different contexts, there is no single congestion control mechanism that will work for all. Below is a non-exhaustive list of example mechanisms that can be used:
このRTPペイロード形式は、さまざまなコンテキストでさまざまなアプリケーションで使用できるため、すべての場合に機能する単一の輻輳制御メカニズムはありません。以下は、使用できるメカニズムの例の非網羅的なリストです。
* a sender can offer several alternative streams for a given video signal, each with a different data rate corresponding to a different compression ratio;
* 送信者は、特定のビデオ信号にいくつかの代替ストリームを提供できます。それぞれが異なる圧縮比に対応する異なるデータレートを持つ。
* a sender can modulate the data rate within a stream by modulating the resolution, frame rate, or compression ratio of the underlying video signal; or
* 送信者は、基礎となるビデオ信号の解像度、フレームレート、または圧縮比を変調することにより、ストリーム内のデータレートを変調できます。または
* an intermediate system can lower the data rate of a stream by discarding resolution levels and/or quality layers, as specified in Section 7.2.
* 中間システムは、セクション7.2で指定されているように、解像度レベルおよび/または品質層を破棄することにより、ストリームのデータレートを下げることができます。
As suggested in Section 10 of [RFC3550], RTCP feedback can be used in the data rate adaptation process.
[RFC3550]のセクション10で示唆されているように、RTCPフィードバックはデータレート適応プロセスで使用できます。
IANA has registered the media type specified in Section 9.
IANAは、セクション9で指定されたメディアタイプを登録しています。
RTP packets using the payload format specified in this document are subject to the security considerations discussed in [RFC3550] and in any applicable RTP profile such as [RFC3551], [RFC4585], [RFC3711], and [RFC5124]. However, as [RFC7202] discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibility lies with anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in [RFC7201]. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this section discusses the security impacting properties of the payload format itself.
このドキュメントで指定されたペイロード形式を使用したRTPパケットは、[RFC3550]で説明されているセキュリティ上の考慮事項の対象となり、[RFC3551]、[RFC4585]、[RFC3711]、[RFC5124]などの[RFC3551]、[RFC4585]、[RFC5124]などの該当するRTPプロファイルが適用されます。ただし、[RFC7202]が議論するように、RTP全般の機密性、整合性、ソースの信頼性などの基本的なセキュリティ目標を満たすために使用されるソリューションを議論または義務付けることは、RTPペイロード形式の責任ではありません。この責任は、アプリケーションでRTPを使用している人にあります。[RFC7201]で利用可能なセキュリティメカニズムと重要な考慮事項に関するガイダンスを見つけることができます。アプリケーションは、1つ以上の適切な強力なセキュリティメカニズムを使用する必要があります。このセクションの残りの部分では、ペイロード形式自体のセキュリティに影響を与えるプロパティについて説明します。
This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for RTP packet processing and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. In addition, the RTP payload format does not contain any active content.
このRTPペイロード形式とそのメディアデコーダーは、RTPパケット処理のレシーバー側の計算の複雑さに有意な不均一性を示さないため、病理学的データの受領によりサービス拒否の脅威をもたらすことはほとんどありません。さらに、RTPペイロード形式にはアクティブなコンテンツは含まれていません。
Security considerations related to the JPEG 2000 codestream contained in the payload are discussed in Section 3 of [RFC3745].
ペイロードに含まれるJPEG 2000コードストリームに関連するセキュリティ上の考慮事項については、[RFC3745]のセクション3で説明します。
[JPEG2000-1]
ITU-T, "Information technology - JPEG 2000 image coding
system: Core coding system", ITU-T Recommendation T.800,
July 2024, <https://www.itu.int/rec/T-REC-T.800/>.
[JPEG2000-15]
ITU-T, "Information technology - JPEG 2000 image coding
system: High-throughput JPEG 2000", ITU-T
Recommendation T.814, June 2019,
<https://www.itu.int/rec/T-REC-T.814/>.
[JPEG2000-2]
ITU-T, "Information Technology - JPEG 2000 image coding
system - Extensions", ITU-T Recommendation T.801, August
2023, <https://www.itu.int/rec/T-REC-T.801>.
[JPEG2000-9]
ITU-T, "Information technology - JPEG 2000 image coding
system: Interactivity tools, APIs and protocols", ITU-T
Recommendation T.808, December 2022,
<https://www.itu.int/rec/T-REC-T.808>.
[REC-ITU-T-H273]
ITU-T, "Coding-independent code points for video signal
type identification", ITU-T Recommendation H.273, July
2024, <https://www.itu.int/rec/T-REC-H.273>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>.
[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>.
[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>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
[OV2110-0] SMPTE, "Professional Media Over Managed IP Networks,
Roadmap for the 2110 Document Suite", 4 December 2018,
<https://pub.smpte.org/doc/ov2110-0/20181204-pub/>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>.
[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>.
[RFC3745] Singer, D., Clark, R., and D. Lee, "MIME Type
Registrations for JPEG 2000 (ISO/IEC 15444)", RFC 3745,
DOI 10.17487/RFC3745, April 2004,
<https://www.rfc-editor.org/info/rfc3745>.
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175,
September 2005, <https://www.rfc-editor.org/info/rfc4175>.
[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>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload
Format for JPEG 2000 Video Streams", RFC 5371,
DOI 10.17487/RFC5371, October 2008,
<https://www.rfc-editor.org/info/rfc5371>.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009,
<https://www.rfc-editor.org/info/rfc5450>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <https://www.rfc-editor.org/info/rfc7202>.
Table 4 defines pixel formats.
表4は、ピクセル形式を定義しています。
+=============+=======+=======+=======+=======+===+=====+=========+
| NAME | SAMP | COMPS | TRANS | PRIMS |MAT| VFR | Mapping |
| | | | | | | | in |
| | | | | | | | Table 1 |
+=============+=======+=======+=======+=======+===+=====+=========+
| rgb444sdr | 4:4:4 | RGB | 1 | 1 |0 | 0, | RGB |
| | | | | | | 1 | |
+-------------+-------+-------+-------+-------+---+-----+---------+
| rgb444wcg | 4:4:4 | RGB | 1 | 9 |0 | 0, | RGB |
| | | | | | | 1 | |
+-------------+-------+-------+-------+-------+---+-----+---------+
| rgb444pq | 4:4:4 | RGB | 16 | 9 |0 | 0, | RGB |
| | | | | | | 1 | |
+-------------+-------+-------+-------+-------+---+-----+---------+
| rgb444hlg | 4:4:4 | RGB | 18 | 9 |0 | 0, | RGB |
| | | | | | | 1 | |
+-------------+-------+-------+-------+-------+---+-----+---------+
| ycbcr420sdr | 4:2:0 | YCbCr | 1 | 1 |1 | 0 | YCbCr |
+-------------+-------+-------+-------+-------+---+-----+---------+
| ycbcr422sdr | 4:2:2 | YCbCr | 1 | 1 |1 | 0 | YCbCr |
+-------------+-------+-------+-------+-------+---+-----+---------+
| ycbcr422wcg | 4:2:2 | YCbCr | 1 | 9 |9 | 0 | YCbCr |
+-------------+-------+-------+-------+-------+---+-----+---------+
| ycbcr422pq | 4:2:2 | YCbCr | 16 | 9 |9 | 0 | YCbCr |
+-------------+-------+-------+-------+-------+---+-----+---------+
| ycbcr422hlg | 4:2:2 | YCbCr | 18 | 9 |9 | 0 | YCbCr |
+-------------+-------+-------+-------+-------+---+-----+---------+
Table 4: Defined Pixel Formats
表4：定義されたピクセル形式
Each pixel format is characterized by the following:
各ピクセル形式は、以下によって特徴付けられます。
NAME:
名前：
Identifies the pixel format
ピクセル形式を識別します
SAMP:
samp：
4:2:0
4：2：0
The C_b and C_r color channels are subsampled horizontally and vertically by 1/2.
C_BおよびC_Rカラーチャネルは、水平および垂直に1/2でサブサンプリングされます。
4:2:2
4：2：2
The C_b and C_r color channels are subsampled horizontally by 1/2.
C_BおよびC_Rカラーチャネルは、水平に1/2でサブサンプリングされます。
4:4:4
4：4：4
No color channels are subsampled.
サブサンプリングされたカラーチャネルはありません。
COMPS:
comps：
RGB:
RGB：
Each codestream contains exactly three components, associated with the R, G, and B color channels, in order.
各コードストリームには、R、G、およびBカラーチャネルに関連付けられた正確に3つのコンポーネントが含まれています。
YCbCr:
ycbcr：
Each codestream contains exactly three components, associated with the Y, C_b, and C_r color channels, in order.
各コードストリームには、y、c_b、およびc_rのカラーチャネルに関連付けられた正確な3つのコンポーネントが含まれています。
TRANS:
トランス：
Identifies the transfer characteristics allowed by the pixel format, as defined in [REC-ITU-T-H273].
[rec-itu-t-H273]で定義されているように、ピクセル形式で許可される伝達特性を識別します。
PRIMS:
プライム：
Identifies the color primaries allowed by the pixel format, as defined in [REC-ITU-T-H273].
[rec-itu-t-H273]で定義されているように、ピクセル形式で許可された色プライマーを識別します。
MAT:
MAT:
Identifies the matrix coefficients allowed by the pixel format, as defined in [REC-ITU-T-H273].
[rec-itu-t-H273]で定義されているように、ピクセル形式で許可されたマトリックス係数を識別します。
VFR:
VFR:
Allows values of the VideoFullRangeFlag defined in [REC-ITU-T-H273].
[rec-itu-t-H273]で定義されたVideoFullrangeFlagの値を許可します。
prog:
Prog：
The stream MUST only consist of a sequence of progressive frames.
ストリームは、プログレッシブフレームのシーケンスでのみ構成する必要があります。
psf:
psf:
Progressive segmented frame (PsF) stream. The stream MUST only consist of an alternating sequence of first segment and second segment.
プログレッシブセグメントフレーム（PSF）ストリーム。ストリームは、最初のセグメントと2番目のセグメントの交互のシーケンスでのみ構成する必要があります。
tff:
tff:
Interlaced stream. The stream MUST only consist of an alternating sequence of first field and second field, where the first line of the first field is the first line of the frame.
インターレースストリーム。ストリームは、最初のフィールドと2番目のフィールドの交互のシーケンスでのみ構成する必要があります。最初のフィールドの最初の行はフレームの最初の行です。
bff:
bff:
Interlaced stream. The stream MUST only consist of an alternating sequence of first field and second field, where the first line of the first field is the second line of the frame.
インターレースストリーム。ストリームは、最初のフィールドと2番目のフィールドの交互のシーケンスでのみ構成する必要があります。最初のフィールドの最初の行はフレームの2行目です。
8
8
All components consist of unsigned 8-bit integer samples.
すべてのコンポーネントは、署名されていない8ビット整数サンプルで構成されています。
10
10
All components consist of unsigned 10-bit integer samples.
すべてのコンポーネントは、署名されていない10ビット整数サンプルで構成されています。
12
12
All components consist of unsigned 12-bit integer samples.
すべてのコンポーネントは、署名されていない12ビット整数サンプルで構成されています。
16
16
All components consist of unsigned 16-bit integer samples.
すべてのコンポーネントは、署名されていない16ビット整数サンプルで構成されています。
Pierre-Anthony Lemieux (editor)
Sandflow Consulting LLC
San Mateo, CA
United States of America
Email: pal@sandflow.com
David Scott Taubman
University of New South Wales
Sydney
Australia
Email: d.taubman@unsw.edu.au