[要約] RFC 5372は、JPEG 2000ビデオのペイロード形式に関する拡張とメインヘッダーの回復について説明しています。このRFCの目的は、JPEG 2000ビデオのスケーラビリティとメインヘッダーの回復を向上させるための拡張を提供することです。
Network Working Group A. Leung
Request for Comments: 5372 S. Futemma
Category: Standards Track E. Itakura
Sony
October 2008
Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
JPEG 2000のペイロード形式ビデオ：スケーラビリティとメインヘッダーリカバリのための拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This memo describes extended uses for the payload header in "RTP Payload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.
このメモでは、RFC 5371で指定されている「JPEG 2000ビデオストリームのRTPペイロード形式」のペイロードヘッダーの拡張用途について、スケーラビリティやメインヘッダーリカバリなどのJPEG 2000の機能をより適切にサポートすることについて説明しています。
This memo must be accompanied with a complete implementation of "RTP Payload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header. There is an additional media type and Session Description Protocol (SDP) marker signaling for implementations of this document.
このメモには、「JPEG 2000ビデオストリームのRTPペイロード形式」の完全な実装を添付する必要があります。このドキュメントは、ペイロードヘッダーとシグナリングの完全な説明であり、このドキュメントでは、ペイロードヘッダーの追加処理のみを説明しています。このドキュメントの実装のために、追加のメディアタイプおよびセッション説明プロトコル（SDP）マーカーシグナリングがあります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Description of the Mechanisms . . . . . . . . . . . . . . 3
1.1.1. Main Header Compensation . . . . . . . . . . . . . . . 3
1.1.2. Priority Table . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivations for Priority Field Coding . . . . . . . . . . 4
1.2.1. Scenario: Just Enough Resolution . . . . . . . . . . . 4
1.2.2. Scenario: Multiple Clients, Single Source . . . . . . 4
1.3. Conventions Used in This Document . . . . . . . . . . . . 4
2. Payload Format Enhanced Processing . . . . . . . . . . . . . . 5
2.1. Enhanced Processing Markers . . . . . . . . . . . . . . . 5
3. Priority Mapping Table . . . . . . . . . . . . . . . . . . . . 6
3.1. Packet-Number-Based Ordering . . . . . . . . . . . . . . . 7
3.2. Progression-Based Ordering . . . . . . . . . . . . . . . . 7
3.3. Layer-Based Ordering . . . . . . . . . . . . . . . . . . . 9
3.4. Resolution-Based Ordering . . . . . . . . . . . . . . . . 9
3.5. Component-Based Ordering . . . . . . . . . . . . . . . . . 10
4. JPEG 2000 Main Header Compensation Scheme . . . . . . . . . . 10
4.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 11
4.2. Receiver Processing . . . . . . . . . . . . . . . . . . . 11
5. Media Type Registration . . . . . . . . . . . . . . . . . . . 11
6. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Mapping of the Optional Parameters to SDP . . . . . . . . 12
6.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 13
6.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Sample Headers in Detail . . . . . . . . . . . . . . 17
A.1. Sample 1: Progressive Image with Single Tile, 3500
Bytes (i.e., thumbnail) . . . . . . . . . . . . . . . . . 17
A.2. Sample 2: Image with 4 Tiles . . . . . . . . . . . . . . . 19
A.3. Sample 3: Packing Multiple Tiles in Single Payload,
Fragmented Header. No Header Compensation,
Progressive Image . . . . . . . . . . . . . . . . . . . . 20
A.4. Sample 4: Interlace Image, Single Tile . . . . . . . . . . 22
This document is an extension of "RTP Payload Format for JPEG 2000 Video Streams" [RFC5371]. These are additional mechanisms that can be used with certain parts of the header in [RFC5371] to support JPEG 2000 features such as scalability and a main header compensation method. These mechanisms are described in detail in this document.
このドキュメントは、「JPEG 2000ビデオストリームのRTPペイロード形式」[RFC5371]の拡張機能です。これらは、[RFC5371]のヘッダーの特定の部分で使用できる追加のメカニズムであり、スケーラビリティやメインヘッダー補正方法などのJPEG 2000の機能をサポートしています。これらのメカニズムについては、このドキュメントで詳しく説明しています。
These are optional extensions to RFC 5371 [RFC5371], which one may use to make better use of JPEG 2000 features. These extensions are not required for any implementations of RFC 5371 [RFC5371].
これらは、RFC 5371 [RFC5371]へのオプションの拡張機能であり、JPEG 2000の機能をよりよく使用するために使用する場合があります。これらの拡張機能は、RFC 5371 [RFC5371]の実装には必要ありません。
JPEG 2000 image header contains essential decoding information for the decoder. If a JPEG 2000 decoder receives JPEG 2000 image data without a JPEG 2000 image header, it could not decode the JPEG 2000 image data properly. Encoders for JPEG 2000 video very rarely change encoding parameters between successive frames. So, the possibility of the decoder successively decoding the new JPEG 2000 image data using a prior JPEG 2000 image header is very high in this situation.
JPEG 2000イメージヘッダーには、デコーダーの必須デコード情報が含まれています。JPEG 2000デコーダーがJPEG 2000イメージヘッダーなしでJPEG 2000画像データを受信した場合、JPEG 2000画像データを適切にデコードできませんでした。JPEG 2000ビデオのエンコーダーは、連続したフレーム間でエンコードパラメーターを変更することはほとんどありません。したがって、この状況では、以前のJPEG 2000イメージヘッダーを使用して、新しいJPEG 2000イメージデータを連続的にデコードする可能性が非常に高いです。
The main header compensation scheme used in this document exploits the fact that successive JPEG 2000 video images rarely change encoding parameters. It requires receivers to save past JPEG 2000 image headers to use in case of missing JPEG 2000 image headers in the future. Signaling of changes to the JPEG 2000 image header is done through the payload header. When the mh_id value of the payload header changes, receivers should save the new JPEG 2000 header to use for main header recovery.
このドキュメントで使用されるメインヘッダー補償スキームは、連続したJPEG 2000ビデオ画像がエンコードパラメーターを変更しないという事実を活用しています。将来、JPEG 2000の画像ヘッダーが欠落している場合に使用するために、過去のJPEG 2000イメージヘッダーを保存するレシーバーが必要です。JPEG 2000イメージヘッダーの変更のシグナリングは、ペイロードヘッダーを介して行われます。ペイロードヘッダーのMH_ID値が変更された場合、受信機は新しいJPEG 2000ヘッダーを保存して、メインヘッダーリカバリに使用する必要があります。
JPEG 2000 codestream has rich functionality built into it so decoders can easily handle scalable delivery or progressive transmission. Progressive transmission allows images to be reconstructed with increasing pixel accuracy or spatial resolution. This feature allows the reconstruction of images with different resolutions and pixel accuracy, for different target devices. A single image source can provide a codestream that is easily processed for smaller image display devices.
JPEG 2000 Codestreamには豊富な機能が組み込まれているため、デコーダーはスケーラブルな配信またはプログレッシブトランスミッションを簡単に処理できます。プログレッシブトランスミッションにより、画像をピクセル精度または空間分解能を高めることで再構築できます。この機能により、さまざまなターゲットデバイスに対して、異なる解像度とピクセル精度で画像を再構築できます。単一の画像ソースは、小さな画像表示デバイス用に簡単に処理できるコードストリームを提供できます。
JPEG 2000 packets contain all compressed image data from a specific layer, component, resolution level, and/or precinct. The order in which these JPEG 2000 packets are found in the codestream is called the progression order. The ordering of the JPEG 2000 packets can progress along four axes: layer, component, resolution, and precinct (or position).
JPEG 2000パケットには、特定のレイヤー、コンポーネント、解像度レベル、および/または境内からのすべての圧縮画像データが含まれています。これらのJPEG 2000パケットがコードストリームにある順序は、進行順序と呼ばれます。JPEG 2000パケットの順序付けは、レイヤー、コンポーネント、解像度、および境内（または位置）の4つの軸に沿って進行する可能性があります。
Providing a priority field to indicate the importance of data contained in a given RTP packet can aid in usage of JPEG 2000 progressive and scalable functions.
特定のRTPパケットに含まれるデータの重要性を示す優先フィールドを提供すると、JPEG 2000の進歩的でスケーラブルな機能の使用に役立ちます。
The JPEG 2000 coding scheme allows one to reorder the codestream in many ways. Even when the coding scheme is determined and arranged by the encoder, a decoder can still re-arrange the code stream on the fly to suit decode parameters such as re-arranging from resolution progressive to quality progressive.
JPEG 2000コーディングスキームにより、Codestreamをさまざまな方法で並べ替えることができます。コードスキームがエンコーダによって決定および配置された場合でも、デコーダーは、解像度のプログレッシブから品質プログレッシブに再配置するなどのデコードパラメーターに合わせて、その場でコードストリームを再配置することができます。
Using the priority field coding, the decoder gains insight into the codestream without access to the full codestream and exposes features of JPEG 2000 to a higher level.
優先フィールドコーディングを使用して、デコーダーは完全なコードストリームにアクセスすることなくコードストリームに関する洞察を得て、JPEG 2000の機能をより高いレベルに公開します。
The authors found the scenarios below to utilize this field. The priority field allows more information about the image to be sent without more signaling between sender and receivers to leverage JPEG 2000 capabilities.
著者は、このフィールドを利用するために以下のシナリオを見つけました。優先度フィールドにより、JPEG 2000の機能を活用するために、送信者と受信機の間でより多くの信号を送信せずに、画像に関する詳細情報を送信できます。
The scenario is when rapid scene access is more important than higher image quality. By using the priority field, the receiver can decode for its own quality level. If the sender cannot determine the receiver's resolution, the receiver can select which parts of the codestream to be decoded or loaded by using the priority field.
シナリオは、迅速なシーンアクセスがより高い画質よりも重要な場合です。優先フィールドを使用することにより、受信機は独自の品質レベルでデコードできます。送信者が受信機の解像度を決定できない場合、受信者は、優先フィールドを使用してデコードまたはロードするコードストリームのどの部分を選択できます。
In a multicast environment, there are clients with better visual capability than others (i.e., TV conference versus Mobile). The respective clients can use the priority field to determine which packets are vital for their own visual presentation. The sender only has to do work on the priority field to optimally serve all the clients while only managing a single visual stream.
マルチキャスト環境では、他の環境よりも視覚的な能力が優れているクライアント（つまり、テレビカンファレンスとモバイル）があります。それぞれのクライアントは、優先度フィールドを使用して、独自の視覚的なプレゼンテーションに不可欠なパケットを決定できます。送信者は、単一の視覚的なストリームのみを管理しながら、すべてのクライアントに最適にサービスを提供するために、優先度フィールドで作業を行う必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC2119で説明されているように解釈される。[RFC2119]。
This section of the document describes additional usage in the values of mh_id and priority fields and interpretation that differ from RFC 5371 [RFC5371]. Implementations of this document should follow RFC 5371 [RFC5371] first then add additional header processing as described in this document. Implementations following this document are expected to interoperate with implementations of [RFC5371] and this document as well.
ドキュメントのこのセクションでは、MH_IDの値と優先フィールドの値とRFC 5371 [RFC5371]とは異なる解釈についての追加の使用について説明します。このドキュメントの実装は、最初にRFC 5371 [RFC5371]に従う必要があります。次に、このドキュメントで説明されているようにヘッダー処理を追加します。このドキュメントに続く実装は、[RFC5371]およびこのドキュメントの実装と相互運用することが期待されています。
The RTP payload header format for JPEG 2000 video stream is as follows:
JPEG 2000ビデオストリームのRTPペイロードヘッダー形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T| priority | tile number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved | fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP Payload Header Format for JPEG 2000
図1：JPEG 2000のRTPペイロードヘッダー形式
mh_id (Main Header Identification): 3 bits
MH_ID（メインヘッダー識別）：3ビット
Main header identification value. This is used for JPEG 2000 main header recovery.
メインヘッダー識別値。これは、JPEG 2000メインヘッダーリカバリに使用されます。
The initial value of mh_id MUST be 1 at the beginning of the session.
MH_IDの初期値は、セッションの開始時に1でなければなりません。
The same mh_id value is used as long as the coding parameters described in the main header remains unchanged between frames.
メインヘッダーで説明されているコーディングパラメーターがフレーム間で変更されていない限り、同じMH_ID値が使用されます。
The mh_id value MUST be incremented by 1 every time a new main header is transmitted. Once the mh_id value becomes greater than 7, it SHOULD roll over to 1.
新しいメインヘッダーが送信されるたびに、MH_ID値を1で増分する必要があります。MH_ID値が7を超えると、1にロールオーバーする必要があります。
When mh_id is 0, it has special usage for the receiver. This special usage is described in Section 4.2 of this document.
MH_IDが0の場合、受信機には特別な使用法があります。この特別な使用法は、このドキュメントのセクション4.2で説明されています。
Senders should follow Section 4.1 of this document for proper mh_id assignment and usage.
送信者は、適切なMH_IDの割り当てと使用について、このドキュメントのセクション4.1に従う必要があります。
priority: 8 bits
優先度：8ビット
The priority field indicates the importance of the JPEG 2000 packet included in the payload. Typically, a higher priority value is set in the packets containing JPEG 2000 packets containing the lower sub-bands.
優先フィールドは、ペイロードに含まれるJPEG 2000パケットの重要性を示しています。通常、下部サブバンドを含むJPEG 2000パケットを含むパケットには、より高い優先度値が設定されています。
Special values of priority:
優先度の特別な値：
0: This is reserved for payloads that contain a header (main or tile part header). This is considered the most important.
0：これは、ヘッダーを含むペイロード（メインまたはタイル部品ヘッダー）に予約されています。これは最も重要であると考えられています。
1 to 255: These values decrease in importance as the values increase (i.e., 1 is more important than 2, etc.). Applying priority values should correlate directly to the JPEG 2000 codestream in importance.
1から255：これらの値は、値が増加するにつれて重要性が低下します（つまり、1は2などよりも重要です）。優先度の適用を適用すると、重要なJPEG 2000コードストリームと直接相関する必要があります。
The lower the priority value, the higher the importance. A priority value of 0 is the highest importance and 255 is the lowest importance. We define the priority value 0 as a special priority value for the headers (the main header or tile-part header). If any headers (the main header or tile-part header) are packed into the RTP payload, the sender MUST set the priority value to 0.
優先度の値が低いほど、重要性が高くなります。0の優先値が最も重要であり、255は最も重要です。優先度値0をヘッダーの特別な優先順位値（メインヘッダーまたはタイルパートヘッダー）として定義します。ヘッダー（メインヘッダーまたはタイルパートヘッダー）がRTPペイロードに詰め込まれている場合、送信者は優先度値を0に設定する必要があります。
Assignment of the values is described in Section 3.
値の割り当てはセクション3で説明されています。
For the progression order, the priority value for each JPEG 2000 packet is given by the priority mapping table.
進行順序の場合、各JPEG 2000パケットの優先値は優先マッピングテーブルで与えられます。
This document specify several commonly used priority mapping tables, pre-defined priority mapping tables: packet-number-based (default), progression-based, layer-based, resolution-based, and component-based.
このドキュメントは、一般的に使用されるいくつかの優先マッピングテーブル、事前定義された優先マッピングテーブル：パケット番号ベース（デフォルト）、進行ベース、レイヤーベース、解像度ベース、コンポーネントベースを指定します。
Packet number priority mapping is REQUIRED to be supported by clients implementing this specification. Other priority mapping tables (progression, layer, resolution, and component-based) are OPTIONAL to implementations of this specification.
パケット番号の優先マッピングは、この仕様を実装するクライアントによってサポートされる必要があります。その他の優先マッピングテーブル（進行、レイヤー、解像度、コンポーネントベース）は、この仕様の実装にオプションです。
Rules that all implementations of this specification MUST follow in all priority modes:
この仕様のすべての実装がすべての優先モードで従わなければならないルール：
o When there is a header in the packet with a JPEG 2000 packet, the sender MUST set the payload packet priority value to 0.
o JPEG 2000パケットを備えたパケットにヘッダーがある場合、送信者はペイロードパケットの優先度値を0に設定する必要があります。
o When there are multiple JPEG 2000 packets in the same RTP payload packet, the sender MUST set the payload packet priority value to the lowest JPEG 2000 packet (i.e., if JPEG 2000 packets with priority: 5,6,7 are packed into a single payload, the priority value will be 5).
o 同じRTPペイロードパケットに複数のJPEG 2000パケットがある場合、送信者はペイロードパケットの優先順位値を最低のJPEG 2000パケットに設定する必要があります（つまり、優先順位を持つJPEG 2000パケット：5,6,7が単一のペイロードにパックされます、優先度の値は5になります。
Packet-number-based ordering assigns the payload packet priority value from the "JPEG 2000 packet value" (note: JPEG 2000 codestreams are stored in units of packets and each packet has a value). This method is the default method for assigning priority value. All implementations of this specification MUST support this method.
パケット番号ベースの注文は、「JPEG 2000パケット値」からペイロードパケットの優先順位値を割り当てます（注：JPEG 2000コードストリームはパケット単位に保存され、各パケットには値があります）。この方法は、優先順位を割り当てるためのデフォルトの方法です。この仕様のすべての実装は、この方法をサポートする必要があります。
If the JPEG 2000 codestream packet value is greater than 255, the sender MUST set the payload priority value to 255.
JPEG 2000 Codestreamパケット値が255を超える場合、送信者はペイロードの優先順位値を255に設定する必要があります。
The sender will assign the payload packet priority value only based on layer, resolution, and component ordering of the codestream.
送信者は、コードストリームのレイヤー、解像度、およびコンポーネントの順序付けに基づいてのみ、ペイロードパケットの優先値を割り当てます。
Progression-based ordering can assign the different priority values in the same layer or the resolution level, which it cannot do in the layer-based ordering or resolution-based ordering.
進行ベースの順序付けは、同じレイヤーまたは解像度レベルで異なる優先度値を割り当てることができます。これは、レイヤーベースの順序付けまたは解像度ベースの順序ではできません。
Unlike the packet-number-based ordering, the progression-based ordering does not assign a value in the position level, which saves the priority values. The priority value in the position level is not so important because a receiver could recognize the position by checking the tile number field. Therefore, the progression-based ordering would be useful.
パケット番号ベースの注文とは異なり、進行ベースの順序は、優先度の値を節約する位置レベルに値を割り当てません。ポジションレベルの優先度値は、レシーバーがタイル番号フィールドをチェックすることで位置を認識できるため、それほど重要ではありません。したがって、進行ベースの注文は有用です。
The general algorithm is that the ordering is based on the triple <layer, resolution, component> and the minimum priority is 1. So, if the codestream is constructed of L layers (layer value ranges from 0 to L-1), R resolutions (resolution value ranges from 0 to R-1), and C components (component value ranges from 0 to C-1), then for a triple <lval, rval, cval>:
一般的なアルゴリズムは、順序がトリプル<レイヤー、解像度、コンポーネント>に基づいており、最小優先度は1であることです。したがって、コードストリームがL層（レイヤー値の範囲が0からL-1の範囲）、R解像度で構成されている場合、（解像度値の範囲は0〜R-1）、Cコンポーネント（コンポーネント値の範囲は0〜C-1）、次にTriple <lval、rval、cval>の場合：
the priority value of the codestream in LRCP order is calculated as:
LRCP順序でのコードストリームの優先順位値は、次のように計算されます。
priority = 1 + cval + (C * rval) + (C * R * lval)
the priority value of the codestream in RLCP order is calculated as:
RLCP順序でのコードストリームの優先値は、次のように計算されます。
priority = 1 + cval + (C * lval) + (C * L * rval)
the priority value of the codestream in RPCL order is calculated as:
RPCL順序でのコードストリームの優先値は、次のように計算されます。
priority = 1 + lval + (L * cval) + (L * C * rval)
the priority value of which codestream in PCRL order is calculated as:
PCRL順序でCodestreamの優先値は次のように計算されます。
priority = 1 + lval + (L * rval) + (L * R * cval)
the priority value of which codestream in CPRL order is calculated as:
CPRL順序でCODESTREAMの優先値は次のように計算されます。
priority = 1 + lval + (L * rval) + (L * R * cval)
For example:
例えば：
If the codestream is ordered in LRCP (Layer, Resolution, Component, Position) with 1 layer (L=1), 2 resolutions (R=2), 3 components (C=3), and 2 positions, the priority value should be (1 + cval + 3*rval + 6*lval). Then an example would have packet numbering as so:
コードストリームは、1層（l = 1）、2つの解像度（r = 2）、3つのコンポーネント（c = 3）、および2位の位置を持つLRCP（レイヤー、解像度、コンポーネント、位置）で注文されている場合、優先度値は（1 cval 3*rval 6*lval）。その後、例にはパケット番号が付いています。
All the packets in:
すべてのパケット：
layer.........0
resolution....0
component.....0
position......0 or 1
then the packet priority value : 1
次に、パケットの優先度値：1
All the packets in:
すべてのパケット：
layer.........0
resolution....0
component.....1
position......0 or 1
then the packet priority value : 2 All the packets in:
次に、パケットの優先度値：2すべてのパケット：
layer.........0
resolution....0
component.....2
position......0 or 1
then the packet priority value : 3
次に、パケットの優先度値：3
All the packets in:
すべてのパケット：
layer.........0
resolution....1
component.....0
position......0 or 1
then the packet priority value : 4
次に、パケットの優先度値：4
All the packets in:
すべてのパケット：
layer.........0
resolution....1
component.....1
position......0 or 1
then the packet priority value : 5
次に、パケットの優先度値：5
The layer-based priority mapping table simplifies the default mapping to just matching JPEG 2000 packets together from the same layer.
レイヤーベースの優先順位マッピングテーブルは、デフォルトのマッピングを同じレイヤーからJPEG 2000パケットを一致させるだけに簡素化します。
For example:
例えば：
All the packets in layer 0 : packet priority value : 1
All the packets in layer 1 : packet priority value : 2
All the packets in layer 2 : packet priority value : 3
...
All the packets in layer n : packet priority value : n+1
All the packets in layer 255 : packet priority value : 255
Resolution-based priority mapping table is similar to the layer-based order but for JPEG 2000 packets of the same resolution.
解像度ベースの優先順位マッピングテーブルは、レイヤーベースの順序に似ていますが、同じ解像度のJPEG 2000パケット用です。
For example:
例えば：
All the packets in resolution 0 : packet priority value : 1
All the packets in resolution 1 : packet priority value : 2
All the packets in resolution 2 : packet priority value : 3
...
All the packets in resolution n : packet priority value : n+1
All the packets in resolution 255 : packet priority value : 255
Component-based priority mapping table is mapping together JPEG 2000 components of the same component.
コンポーネントベースの優先マッピングテーブルは、同じコンポーネントのJPEG 2000コンポーネントをマッピングしています。
For example:
例えば：
All the packets in component 0 : packet priority value : 1
All the packets in component 1 : packet priority value : 2
All the packets in component 2 : packet priority value : 3
...
All the packets in component n : packet priority value : n+1
All the packets in component 255 : packet priority value : 255
The mh_id field of the payload header is used to indicate whether the encoding parameters of the main header are the same as the encoding parameters of the previous frame. The same value is set in mh_id of the RTP packet in the same frame. The mh_id and encode parameters are not associated with each other as 1:1, but they are used to indicate whether or not the encode parameters of the previous frame are the same in the event of a lost header.
ペイロードヘッダーのMH_IDフィールドは、メインヘッダーのエンコードパラメーターが前のフレームのエンコードパラメーターと同じかどうかを示すために使用されます。同じフレームのRTPパケットのMH_IDで同じ値が設定されています。MH_IDとエンコードパラメーターは1：1として互いに関連付けられていませんが、前のフレームのエンコードパラメーターが失われた場合に同じであるかどうかを示すために使用されます。
The mh_id field value SHOULD be saved from previous frames to be used to recover the current frame's main header. If the mh_id of the current frame has the same value as the mh_id value of the previous frame, the previous frame's main header MAY be used to decode the current frame, in case of a lost header in the current frame.
MH_IDフィールド値は、現在のフレームのメインヘッダーを回復するために使用される前のフレームから保存する必要があります。現在のフレームのMH_IDが前のフレームのMH_ID値と同じ値を持っている場合、現在のフレームのヘッダーが失われた場合、前のフレームのメインヘッダーを使用して現在のフレームをデコードできます。
The sender MUST increment mh_id when parameters in the header change and send a new main header accordingly.
送信者は、ヘッダーのパラメーターが変更されたときにMH_IDを増やし、それに応じて新しいメインヘッダーを送信する必要があります。
The receiver MAY use the mh_id and MAY retain the header for such compensation.
受信者はMH_IDを使用し、そのような補償のためにヘッダーを保持することができます。
The sender MUST transmit RTP packets with the same mh_id value if the encoder parameters of the current frame are the same as the previous frame. The encoding parameters are the fixed information marker segment (SIZ marker) and functional marker segments (COD, COC, RGN, QCD, QCC, and POC) specified in JPEG 2000 Part 1, Annex A [JPEG2000Pt_1].
送信者は、現在のフレームのエンコーダーパラメーターが前のフレームと同じである場合、同じMH_ID値でRTPパケットを送信する必要があります。エンコーディングパラメーターは、JPEG 2000パート1で指定された固定情報マーカーセグメント（SIZマーカー）および機能マーカーセグメント（COD、COC、RGN、QCD、QCC、およびPOC）です。
If the encode parameters changes, the sender transmitting RTP packets MUST increment the mh_id value by one, but when the mh_id value becomes greater than 7, a sender MUST set the mh_id value back to 1.
エンコードパラメーターが変更された場合、送信者はRTPパケットを送信する必要がありますが、MH_ID値を1つずつ増加させる必要がありますが、MH_ID値が7を超える場合、送信者はMH_ID値を1に戻す必要があります。
When the receiver receives the main header completely, the RTP sequence number, the mh_id, and the main header should be saved. Only the last main header that was received completely SHOULD be saved. When the mh_id value is 0, the receiver SHOULD NOT save the header.
受信機がメインヘッダーを完全に受信する場合、RTPシーケンス番号、MH_ID、およびメインヘッダーを保存する必要があります。完全に受信された最後のメインヘッダーのみを保存する必要があります。MH_ID値が0の場合、レシーバーはヘッダーを保存しないでください。
When the main header is not received, the receiver may compare the current payload header's mh_id value with the previous saved mh_id value. If the values match, decoding may be performed by using the previously saved main header.
メインヘッダーが受信されない場合、レシーバーは現在のペイロードヘッダーのMH_ID値を以前の保存されたMH_ID値と比較できます。値が一致する場合、以前に保存したメインヘッダーを使用してデコードを実行できます。
If the mh_id field is set to 0, the receiver MUST NOT save the main header and MUST NOT compensate for lost headers.
MH_IDフィールドが0に設定されている場合、受信機はメインヘッダーを保存してはならず、失われたヘッダーを補正してはなりません。
If the mh_id value changes, receivers SHOULD save the current header and save the new mh_id value. The old saved header should be deleted from storage.
MH_ID値が変更された場合、受信機は現在のヘッダーを保存し、新しいMH_ID値を保存する必要があります。古い保存されたヘッダーは、ストレージから削除する必要があります。
Also, if the decoder detects an inconsistency between the header and payload, it is recommended to clear the saved mh_id and the saved main header. Please see Section 8 for more explanation.
また、デコーダーがヘッダーとペイロードの間の矛盾を検出する場合、保存されたMH_IDと保存されたメインヘッダーをクリアすることをお勧めします。詳細については、セクション8を参照してください。
This document extends the associated media type "video/jpeg2000" from RFC 5371 [RFC5371]. Here are additional optional parameters.
このドキュメントは、RFC 5371 [RFC5371]から関連するメディアタイプ「ビデオ/JPEG2000」を拡張します。追加のオプションパラメーターは次のとおりです。
Additional optional parameters:
追加のオプションパラメーター：
mhc: Main Header Compensation. This option is used when a sender and/or receiver is utilizing the Main Header Compensation technique as specified in this document. Acceptable values when using the Main Header Compensation technique is "1"; otherwise, it should be "0".
MHC：メインヘッダー補償。このオプションは、送信者および/またはレシーバーがこのドキュメントで指定されているメインヘッダー補償技術を利用している場合に使用されます。メインヘッダー補償手法を使用する場合の許容値は「1」です。それ以外の場合は、「0」でなければなりません。
This is a list of options to be included when the sender or receiver is utilizing the priority table option as specified in this document.
これは、送信者またはレシーバーがこのドキュメントで指定されているように優先テーブルオプションを使用している場合に含めるオプションのリストです。
pt: Priority Table. This option is followed by a comma-separated list of pre-defined priority table definitions to be used by sender or receiver.
PT：優先テーブル。このオプションの後に、送信者または受信機が使用する事前に定義された優先テーブル定義のコンマ分離されたリストが続きます。
The option appearing front most in the option line is the most important and the next are of decreasing importance.
オプションラインで最も前面に表示されるオプションが最も重要であり、次のオプションは重要性が低下します。
Acceptable values:
許容可能な値：
progression: this table follows the progression ordering of the codestream.
進行：この表は、コードストリームの進行順序に従います。
layer: this table follows the layer ordering of the codestream.
レイヤー：このテーブルは、コードストリームのレイヤー順序に従います。
resolution: this table follows the resolution ordering of the codestream.
解決策：この表は、コードストリームの解像度の順序に従います。
component: this table follows the component ordering of the codestream.
コンポーネント：このテーブルは、コードストリームのコンポーネントの順序に従います。
default: this table follows the packet ordering of the codestream.
デフォルト：このテーブルは、Codestreamのパケット注文に従います。
The new optional parameters mhc and pt, if presented, MUST be included in the "a=fmtp" line of SDP. These parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
新しいオプションのパラメーターMHCおよびPTは、提示されている場合は、SDPの「A = FMTP」行に含める必要があります。これらのパラメーターは、パラメーター=値ペアのセミコロン分離されたリストの形で、メディア型文字列として表されます。
In addition to the SDP Offer/Answer section in RFC 5371 [RFC5371]:
RFC 5371 [RFC5371]のSDPオファー/回答セクションに加えて：
When offering JPEG 2000 over RTP using SDP in an Offer/Answer model [RFC3264], the following rules and limitations apply:
オファー/回答モデル[RFC3264]でSDPを使用してRTPを介してJPEG 2000を提供する場合、次のルールと制限が適用されます。
o All parameters MUST have an acceptable value for that parameter.
o すべてのパラメーターには、そのパラメーターに対して許容可能な値が必要です。
o All parameters MUST correspond to the parameters of the payload.
o すべてのパラメーターは、ペイロードのパラメーターに対応する必要があります。
o If the optional parameter "mhc" is used, it MUST appear in the offer with value "1", and if accepted, it SHOULD appear in the answer.
o オプションのパラメーター「MHC」が使用されている場合、それはオファーに値「1」で表示される必要があり、受け入れられた場合、回答に表示されるはずです。
o If the optional parameter "pt" is used, it MUST appear in the offer containing a complete comma-separated list indicating which priority table definitions the sender supports. If accepted, it SHOULD appear in the answer containing a single priority table definition selected from the offer.
o オプションのパラメーター「PT」が使用されている場合、送信者がサポートする優先度のテーブル定義を示す完全なコンマ区切りリストを含むオファーに表示する必要があります。受け入れられた場合、オファーから選択された単一の優先度のテーブル定義を含む回答に表示されるはずです。
o If the optional parameter "mhc" is used, it MUST appear in the offer with value "1", and if accepted, it MUST appear in the answer. If the optional parameter "pt" is used, it MUST appear in the offer containing a complete comma-separated list indicating which priority table definitions the sender supports. If accepted, it MUST appear in the answer containing a single priority table definition selected from the offer.
o オプションのパラメーター「MHC」が使用されている場合、オファーには値「1」で表示され、受け入れられた場合は回答に表示する必要があります。オプションのパラメーター「PT」が使用されている場合、送信者がサポートする優先度のテーブル定義を示す完全なコンマ区切りリストを含むオファーに表示する必要があります。受け入れられた場合は、オファーから選択された単一の優先度テーブル定義を含む回答に表示する必要があります。
o In a multicast environment:
o マルチキャスト環境：
* Senders should send out one option for a priority table definition for everyone in the group.
* 送信者は、グループ内の全員に優先テーブル定義のために1つのオプションを送信する必要があります。
* Even if a single client in the group does not support the extensions outlined in this document, senders MAY use these mechanisms. A receiver that doesn't support the mechanisms would safely ignore the values.in mh_id and priority field.
* グループ内の単一のクライアントが、このドキュメントで概説されている拡張機能をサポートしていない場合でも、送信者はこれらのメカニズムを使用できます。メカニズムをサポートしていないレシーバーは、値を安全に無視します。MH_IDおよび優先度フィールド。
Offer/Answer example exchanges are provided.
オファー/回答の例交換が提供されます。
Alice offers Main Header Compensation functionality, YCbCr 422 color space, interlace image with 720-pixel width and 480-pixel height, and several priority table options (default, progression, layer, resolution, component) as below:
アリスは、メインのヘッダー補償機能、YCBCR 422カラースペース、720ピクセルの幅と480ピクセルの高さのインターレース画像、および以下にいくつかの優先テーブルオプション（デフォルト、進行、レイヤー、解像度、コンポーネント）を提供しています。
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2; interlace=1;
pt=default,progression,layer,resolution, component;
width=720;height=480
Bob accepts Main Header Compensation functionality, YCbCr-4:2:2 color space, interlace image, default mapping table and replies:
ボブは、メインヘッダー補償機能、YCBCR-4：2：2カラースペース、インターレース画像、デフォルトマッピングテーブル、および返信を受け入れます。
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:2;interlace=1;
pt=default;width=720;height=480
Alice offers Main Header Compensation, YCbCr 420 color space, progressive image with 320-pixel width and 240-pixel height, and layer priority table options as below:
アリスは、メインのヘッダー補償、YCBCR 420カラースペース、320ピクセルの幅と240ピクセルの高さのプログレッシブ画像、および以下のようにレイヤー優先テーブルオプションを提供します。
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
Bob does not accept Main Header Compensation functionality but accepts YCbCr-4:2:0 color space, layer-based priority mapping and replies:
ボブはメインヘッダー補償機能を受け入れませんが、YCBCR-4：2：0のカラースペース、レイヤーベースの優先マッピング、および返信を受け入れます。
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
Alice offers 27 MHz timestamp, Main Header Compensation, YCbCr 420 color space, progressive image with 320-pixel width and 240-pixel height, and layer priority table options as below:
アリスは、27 MHzタイムスタンプ、メインヘッダー補償、YCBCR 420カラースペース、320ピクセルの幅と240ピクセルの高さのプログレッシブ画像、および以下のレイヤー優先テーブルオプションを提供しています。
v=0
o=alice 2890844526 2890844526 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49170 RTP/AVP 98 99
a=rtpmap:98 jpeg2000/27000000
a=rtpmap:99 jpeg2000/90000
a=fmtp:98 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
a=fmtp:99 mhc=1; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
Bob can accept payload type with 27 MHz timestamp, and does not accept Main Header Compensation functionality but accepts YCbCr-4:2:0 color space, layer-based priority mapping and replies:
ボブは27 MHzタイムスタンプを使用してペイロードタイプを受け入れることができ、メインヘッダー補正機能を受け入れませんが、YCBCR-4：0のカラースペース、レイヤーベースの優先マッピング、および返信を受け入れます。
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 98
a=rtpmap:98 jpeg2000/27000000
a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0;
pt=layer;width=320;height=240
This document extends the associated media type "video/jpeg2000" from 5371 [RFC5371]. Additional parameters are specified in Section 5 of this document.
このドキュメントは、5371 [RFC5371]から関連するメディアタイプ「Video/JPEG2000」を拡張します。追加のパラメーターは、このドキュメントのセクション5で指定されています。
Please refer to Section 6 of RFC 5371 [RFC5371] for Security Considerations regarding this RTP format. The security issues regarding enhanced mechanisms presented in this document are discussed in that section.
このRTP形式に関するセキュリティに関する考慮事項については、RFC 5371 [RFC5371]のセクション6を参照してください。このドキュメントで提示された強化されたメカニズムに関するセキュリティの問題については、そのセクションで説明します。
The mh_id field can identify a maximum of 7 different main headers. If severe packet loss (either random or intentionally introduced by an attacker) causes 6 successive updates to the main header to be lost, the decoder will attempt decompression using an incorrect main header. Even if the incorrect main header is passed, the standard JPEG 2000 decoder could detect inconsistency of the codestream and process it properly. It is recommended to clear the saved mh_id and the saved main header if the decoder detects such an inconsistency.
MH_IDフィールドは、最大7つの異なるメインヘッダーを識別できます。重度のパケット損失（攻撃者によってランダムまたは意図的に導入された）により、メインヘッダーが6つの連続した更新が失われると、デコーダーは誤ったメインヘッダーを使用して減圧を試みます。誤ったメインヘッダーが渡されたとしても、標準のJPEG 2000デコーダーはコードストリームの矛盾を検出し、適切に処理できます。デコーダーがそのような矛盾を検出する場合、保存されたMH_IDと保存されたメインヘッダーをクリアすることをお勧めします。
Please refer to Section 7 of RFC 5371 [RFC5371] for Congestion Control regarding this RTP format.
このRTP形式に関する輻輳制御については、RFC 5371 [RFC5371]のセクション7を参照してください。
[RFC5371] Futemma, S., Leung, A., and E. Itakura, "RTP Payload Format for JPEG 2000 Video Streams", RFC 5371, October 2008.
[RFC5371] Futemma、S.、Leung、A。、およびE. Itakura、「JPEG 2000ビデオストリームのRTPペイロード形式」、RFC 5371、2008年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[JPEG2000Pt_1] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, "Information Technology - JPEG 2000 Image Coding System - Part 1: Core Coding System", December 2000.
[JPEG2000PT_1] ISO/IEC JTC1/SC29、ISO/IEC 15444-1 |itu-t rec。T.800、「情報技術-JPEG 2000イメージコーディングシステム - パート1：コアコーディングシステム」、2000年12月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
The following figures are sample RTP headers demonstrating values that should appear in the RTP header. The packet priority is Packet-Number-Based Priority.
次の図は、RTPヘッダーに表示される値を示すサンプルRTPヘッダーです。パケットの優先順位は、パケット番号ベースの優先度です。
For reference, the payload header is as follows:
参照のために、ペイロードヘッダーは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|tp |MHF|mh_id|T| priority | tile number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|reserved | fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: JPEG 2000 Payload Header
図2：JPEG 2000ペイロードヘッダー
First Packet: This packet will have the whole main header 210 bytes
最初のパケット：このパケットには、メインヘッダー全体の210バイトがあります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Header Sample 1-1 (First Packet)
図3：ヘッダーサンプル1-1（最初のパケット）
Second Packet: This packet will have a tile header and the first tile part LLband 1500 bytes
2番目のパケット：このパケットにはタイルヘッダーと最初のタイルパートLLBAND 1500バイトがあります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 2DB3 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Header Sample 1-2 (Second Packet)
図4：ヘッダーサンプル1-2（2番目のパケット）
Third Packet: This packet will have the next part in the tile, no tile header 1500 bytes
3番目のパケット：このパケットには、タイルの次の部分があり、タイルヘッダー1500バイトなし
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 2 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1710 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E841 4526 4556 9850 C2EA .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Header Sample 1-3 (Third Packet)
図5：ヘッダーサンプル1-3（3番目のパケット）
Fourth Packet: Last packet for the image 290 bytes
4番目のパケット：画像290バイトの最後のパケット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A55D 8B73 3B25 25C7 B9EB .... 2FBE B153|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Header Sample 1-4 (Fourth Packet)
図6：ヘッダーサンプル1-4（4番目のパケット）
First Packet: This packet will have the whole main header 210 bytes
最初のパケット：このパケットには、メインヘッダー全体の210バイトがあります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Header Sample 2-1 (First Packet)
図7：ヘッダーサンプル2-1（最初のパケット）
Second Packet: This packet will have a first tile part (tile 0) 1400 bytes
2番目のパケット：このパケットには、最初のタイル部品があります（タイル0）1400バイト
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Header Sample 2-2 (Second Packet)
図8：ヘッダーサンプル2-2（2番目のパケット）
Third Packet: This packet will have a second tile part (tile 1) 1423 bytes
3番目のパケット：このパケットには2番目のタイル部品があります（タイル1）1423バイト
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0001 0000 058F 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Header Sample 2-3 (Third Packet)
図9：ヘッダーサンプル2-3（3番目のパケット）
Fourth Packet: This packet will have a third tile part (tile 2) 1355 bytes
4番目のパケット：このパケットには3番目のタイル部品があります（タイル2）1355バイト
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3033 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 054B 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Header Sample 2-4 (4th Packet)
図10：ヘッダーサンプル2-4（4番目のパケット）
Fifth Packet: This packet will have a fourth tile part (tile 3) 1290 bytes
5番目のパケット：このパケットには4番目のタイル部品があります（タイル3）1290バイト
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 1 |0| 1 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 4388 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0003 0000 050A 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Header Sample 2-5 (5th Packet)
図11：ヘッダーサンプル2-5（5番目のパケット）
First Packet: This packet will have the first part of the main header 110 bytes
最初のパケット：このパケットには、メインヘッダー110バイトの最初の部分があります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1 | 0 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Header Sample 3-1 (First Packet)
図12：ヘッダーサンプル3-1（最初のパケット）
Second Packet: This packet has the second part of the main header. 1400 bytes
2番目のパケット：このパケットには、メインヘッダーの2番目の部分があります。1400バイト
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2 | 0 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 110 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF64 00FF .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Sample 3-2 (Second Packet)
図13：ヘッダーサンプル3-2（2番目のパケット）
Third Packet: This packet has two tiles, tile 0 and tile 1 1400 bytes
3番目のパケット：このパケットには、タイル0とタイル1 1400バイトの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1510 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 02BC 0001 FF93 ... |
// . //
|FF90 000A 0001 0000 02BC 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Header Sample 3-3 (Third Packet)
図14：ヘッダーサンプル3-3（3番目のパケット）
Fourth Packet: This packet has one tile, tile 2 1395 bytes
4番目のパケット：このパケットには1つのタイル、タイル2 1395バイトがあります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 |0| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2910 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 0573 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Header Sample 3-4 (4th Packet)
図15：ヘッダーサンプル3-4（4番目のパケット）
The codestream of each image is ordered in LRCP (Layer, Resolution, Component, Position) with 1 layer, 3 resolutions, 3 components and 1 position.
各画像のコードストリームは、1層、3つの解像度、3つのコンポーネント、1位の位置を備えたLRCP（レイヤー、解像度、コンポーネント、位置）で注文されます。
First packet: This packet will have the whole main header for the odd field 210 bytes
最初のパケット：このパケットには、オッドフィールド210バイトのメインヘッダー全体があります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Header Sample 4-1 (First Packet)
図16：ヘッダーサンプル4-1（最初のパケット）
Second packet: This packet will have the first part of the odd field's tile where three jp2-packets are included 1400 bytes
2番目のパケット：このパケットには、3つのJP2パケットが1400バイトが含まれているオッドフィールドのタイルの最初の部分があります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Header Sample 4-2 (Second Packet)
図17：ヘッダーサンプル4-2（2番目のパケット）
Third packet: This packet will have the second part of the odd field's tile 1400 bytes
3番目のパケット：このパケットには、奇妙なフィールドのタイル1400バイトの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 4 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|7F04 E708 27D9 D11D 22CB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Header Sample 4-3 (Third Packet)
図18：ヘッダーサンプル4-3（3番目のパケット）
Fourth packet: This packet will have the third part of the odd field's tile 1300 bytes
4番目のパケット：このパケットには、奇数フィールドのタイル1300バイトの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 |1| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|98BD EC9B 2826 DC62 D4AB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Header Sample 4-4 (4th Packet)
図19：ヘッダーサンプル4-4（4番目のパケット）
Fifth packet: This packet will have the whole main header for the even field 210 bytes
5番目のパケット：このパケットには、均一なフィールド210バイトのメインヘッダー全体があります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 3 | 1 |1| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 0000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Header Sample 4-5 (5th Packet)
図20：ヘッダーサンプル4-5（5番目のパケット）
Sixth packet: This packet will have the first part of the even field's tile 1400 bytes
6番目のパケット：このパケットには、均一なフィールドのタイル1400バイトの最初の部分があります
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Header Sample 4-6 (6th Packet)
図21：ヘッダーサンプル4-6（6番目のパケット）
Seventh packet: This packet will have the second part of the even field's tile 1400 bytes
7番目のパケット：このパケットには、均一なフィールドのタイル1400バイトの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 4 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|626C 42F0 166B 6BD0 F8E1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Header Sample 4-7 (7th Packet)
図22：ヘッダーサンプル4-7（7番目のパケット）
Eighth packet: This packet will have the third part of the even field's tile 1300 bytes
8番目のパケット：このパケットには、均一なフィールドのタイル1300バイトの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 0 | 1 |1| 7 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 4410 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|8114 41D5 18AB 4A1B ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Header Sample 4-8 (8th Packet)
Authors' Addresses
著者のアドレス
Andrew Leung Sony Corporation
アンドリュー・レオン・ソニー・コーポレーション
EMail: andrew@ualberta.net
Satoshi Futemma Sony Corporation 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
Satoshi Fipemma Sony Corporation 1-7-1 Konan Minato-Ku Tokyo 108-0075 Japan
Phone: +81 3 6748-2111
EMail: satosi-f@sm.sony.co.jp
URI: http://www.sony.net/
Eisaburo Itakura Sony Corporation 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
アイサブロitakuraソニーコーポレーション1-7-1 Konan Minato-Ku Tokyo 108-0075 Japan
Phone: +81 3 6748-2111
EMail: itakura@sm.sony.co.jp
URI: http://www.sony.net/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。