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
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.
そのような拡張性とメインヘッダ回復などJPEG 2000の機能のより良いサポートのために、RFC 5371で指定されたこのメモは、「JPEG 2000ビデオストリームのためのRTPペイロードフォーマット」のペイロードヘッダの拡張使用法を説明します。
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]の拡張です。これらは、拡張性とメインヘッダ補償方式としてJPEG 2000の機能をサポートするために、[RFC5371]のヘッダの特定の部分で使用することができ、追加の機構です。これらのメカニズムは、この文書に詳細に記載されています。
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].
これらは1つがJPEG 2000の機能をより有効に活用するために使用することができRFC 5371 [RFC 5371]にオプションの拡張機能です。これらの拡張機能は、RFC 5371 [RFC 5371]のいずれかの実装に必要とされていません。
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.
JPEG2000の画像ヘッダが復号のために必須の復号情報を含んでいます。 JPEG2000のデコーダは、JPEG2000画像のヘッダなしで、JPEG2000画像データを受信した場合、それは適切に、JPEG2000画像データを復号することができませんでした。 JPEG 2000ビデオのためのエンコーダは、非常にまれに、連続するフレーム間のエンコードパラメータを変更しません。だから、順次前のJPEG2000画像ヘッダを使用して、新しい、JPEG2000画像データを復号するデコーダの可能性は、この状況では非常に高いです。
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画像ヘッダを保存するために受信機を必要とします。 JPEG2000の画像ヘッダの変更のシグナリングは、ペイロードヘッダを介して行われます。ペイロードヘッダの変更の場合は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.
JPEG2000コードストリームは、デコーダが容易に拡張配信やプログレッシブ伝送を処理することができるので、それに組み込まれた豊富な機能を持っています。プログレッシブ伝送は、画像が増加画素精度や空間解像度で再構成されることを可能にします。この機能は、異なるターゲットデバイスに対して、異なる解像度及びピクセル精度で画像の再構成を可能にします。単一の画像源は容易小さい画像表示装置のために処理された符号ストリームを提供することができます。
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).
JPEG2000のパケットは、特定の層、コンポーネント、解像度レベル、および/またはプレシンクトから全ての圧縮画像データを含みます。これらのJPEG 2000のパケットはコードストリームで発見される順番は、プログレッション順序と呼ばれています。層、コンポーネント、解像度、およびプレシンクト（または位置）：JPEG2000のパケットの順序付けは、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符号化方式は、1つの多くの方法でコードストリームの順序を変更することができます。符号化方式を決定し、エンコーダによって配置されている場合でも、デコーダは、まだこのような漸進的な品質にプログレッシブ解像度の再配置などのデコードパラメータに適合するようにオンザフライでコードストリームを再配置することができます。
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.
マルチキャスト環境では、他のものよりも優れて視覚的な機能（モバイル対すなわち、TV会議）でのクライアントがあります。各クライアントは、独自の視覚的なプレゼンテーションのために不可欠であるパケットを決定するために優先順位フィールドを使用することができます。送信者は、唯一の最適な単一のビジュアルストリームを管理しながら、すべてのクライアントにサービスを提供するために優先順位フィールド上で作業を行う必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [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.
文書のこのセクションでは、RFC 5371 [RFC5371]異なるmh_id及び優先順位フィールドと解釈の値の追加の使用を記載しています。この文書の実装は、この文書に記載されているように、追加のヘッダ処理を追加最初にRFC 5371 [RFC5371]を従わなければなりません。この文書を以下の実装は同様に、[RFC5371]と、この文書の実装と相互運用することが期待されます。
The RTP payload header format for JPEG 2000 video stream is as follows:
次のように、JPEG2000ビデオストリームの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パケットの重要性を示しています。典型的には、より高い優先度の値が低いサブバンドを含むJPEG2000のパケットを含むパケットに設定されています。
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よりも重要です）。優先順位の値を適用することは重要でJPEG2000コードストリームに直接関連付ける必要があります。
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.
プログレッションオーダのために、各JPEG2000のパケットの優先順位値は、優先順位マッピングテーブルによって与えられます。
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.
JPEG2000のパケットとパケットのヘッダが存在する場合にO、送信者は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).
5,6,7シングルにパックされます。o同じRTPペイロードパケットで複数のJPEG 2000個のパケットが存在する場合、送信者はすなわち、JPEG場合は優先順位の2000個のパケットが最低JPEG 2000パケット（のペイロードパケットの優先順位の値を設定しなければなりませんペイロード、優先値が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.
パケット数に基づく順序付けは、「JPEG2000のパケット値」からペイロード・パケットの優先順位値を割り当てる（注：JPEG2000のコードストリームをパケット単位で格納され、各パケットは、値を有します）。この方法は、優先順位値を割り当てるためのデフォルトの方法です。この仕様のすべての実装がこのメソッドをサポートしなければなりません。
If the JPEG 2000 codestream packet value is greater than 255, the sender MUST set the payload priority value to 255.
JPEG2000コードストリームのパケット値が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>:
一般的なアルゴリズムは、順序が三重<レイヤ、解像度、コンポーネント>およびコードストリームがL層から構成されている場合は最小の優先順位は、したがって1である（レイヤ値は0からL-1の範囲である）、R解像度に基づいていることです<LVAL、rvalに、CVAL>三重、次いで、（解像度値は、0からR-1の範囲である）、およびC成分（成分値は0からC-1の範囲です）。
the priority value of the codestream in LRCP order is calculated as:
LRCP順序でコードストリームの優先度の値は次のように計算されます。
priority = 1 + cval + (C * rval) + (C * R * lval)
優先順位= 1 +キャンターの+（C *を引き裂く）+（C *のR * LVAL）
the priority value of the codestream in RLCP order is calculated as:
RLCP順にコードストリームの優先度の値は次のように計算されます。
priority = 1 + cval + (C * lval) + (C * L * rval)
優先順位= 1 +キャンター+（C *とLVAL）+（C * 1 *は廃棄）
the priority value of the codestream in RPCL order is calculated as:
RPCL順序でコードストリームの優先度の値は次のように計算されます。
priority = 1 + lval + (L * cval) + (L * C * rval)
優先順位= 1 + LVAL +（のL *キャンター）+（のL * C *スクラップ）
the priority value of which codestream in PCRL order is calculated as:
PCRLのためにコードストリームその優先順位の値は次のように計算されます。
priority = 1 + lval + (L * rval) + (L * R * cval)
優先順位= 1 + LVAL +（L *を引き裂く）+（のL * R *キャンター）
the priority value of which codestream in CPRL order is calculated as:
CPRL順にコードストリームその優先順位の値は次のように計算されます。
priority = 1 + lval + (L * rval) + (L * R * cval)
優先順位= 1 + LVAL +（L *を引き裂く）+（のL * R *キャンター）
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
その後、パケットの優先値：2
All the packets in:
すべてのパケットで：
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.
レイヤーベースの優先順位マッピングテーブルはちょうど同じ層から一緒に、JPEG2000パケットを照合するデフォルトのマッピングを単純化します。
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
パケット優先値：層0における全てのパケットのパケットプライオリティ値：レイヤ1における1つのすべてのパケットのパケットの優先値：層2における2つのすべてのパケット3 ...層nのすべてのパケット：パケットの優先値： N + 1層255のすべてのパケット：パケットの優先値：255
Resolution-based priority mapping table is similar to the layer-based order but for JPEG 2000 packets of the same resolution.
解像度ベースの優先順位マッピングテーブルは、層ベースために同じ解像度のJPEG2000のパケットについても同様です。
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
パケット優先値：解像度0のすべてのパケットのパケットの優先値：分解能1 1つの全てのパケットのパケットの優先値：解像度2で2つのすべてのパケット3 ...解像度Nのすべてのパケット：パケットの優先値： N + 1解像度255のすべてのパケット：パケットの優先値：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
成分0のすべてのパケット：パケットの優先値：成分1 1つの全てのパケット：パケットの優先値：パケットの優先値：成分2の2つのすべてのパケット3 ...成分Nのすべてのパケット：パケットの優先値： N + 1構成要素255のすべてのパケット：パケットの優先値：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パケットを送信しなければなりません。符号化パラメータは、JPEG2000パート1、附属書A [JPEG2000Pt_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値をインクリメントしなければならないが、mh_id値が7より大きくなると、送信側はバック1にmh_id値を設定する必要があります。
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.
デフォルト：この表は、コードストリームのパケット順序に従います。
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にSDPオファー/アンサーセクションに加えて、[RFC5371]：
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.
オプションのパラメータ「PT」が使用されている場合は、O、それは優先度テーブルは、送信者がサポートを画成示す完全なカンマ区切りのリストを含むプランに表示される必要があります。受け入れた場合、それはプランから選択された1つの優先順位テーブル定義を含む答えに表示されます。
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」が使用されている場合は、優先度テーブルは、送信者がサポートを画成示す完全なカンマ区切りのリストを含むプランに表示される必要があります。受け入れた場合、それはプランから選択された1つの優先順位テーブル定義を含む答えに現れなければなりません。
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.
*グループ内の単一のクライアントは、このドキュメントで概説拡張をサポートしていない場合であっても、送信者は、これらのメカニズムを使用するかもしれません。メカニズムをサポートしていない受信機が安全にvalues.inの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:
2：2色空間、インターレース画像、デフォルトのマッピングテーブルおよび応答ボブは、メインヘッダ補償機能、YCbCrの-4を受け入れます。
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
V = 0 0 = IP4ボブ2890844730 2890844731 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49920 RTP / AVP 98 A = rtpmap：98 JPEG2000 / 90000 A =のfmtp：98、MHC = 1 ;サンプリング=たYCbCr-4：2：2;インターレース= 1。 PT =デフォルト;幅= 720;高さ= 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
V = 0 0 = IP4アリス2890844526 2890844526 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49170 RTP / AVP 98 A = rtpmap：98 JPEG2000 / 90000 A =のfmtp：98、MHC = 1 ;サンプリング=たYCbCr-4：2：0。 PT =層;幅= 320;高さ= 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
V = 0 0 = IP4ボブ2890844730 2890844731 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49920 RTP / AVP 98 A = rtpmap：98 JPEG2000 / 90000 A =のfmtp：98、MHC = 0 ;サンプリング=たYCbCr-4：2：0。 PT =層;幅= 320;高さ= 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:
アリスは、27MHzのタイムスタンプを提供し、メインヘッダ報酬、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:
ボブは、27MHzのタイムスタンプを持つペイロードタイプを受け入れることができ、及びメインヘッダ補償機能を受け入れないが、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/27000000 a=fmtp:98 mhc=0; sampling=YCbCr-4:2:0; pt=layer;width=320;height=240
98 JPEG2000 /2700万A =のfmtp：98、MHC = 0 = rtpmap IP4 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49920 RTP / AVP 98 AにおけるV = 0 0 =ボブ2890844730 2890844731 ;サンプリング=たYCbCr-4：2：0。 PT =層;幅= 320;高さ= 240
This document extends the associated media type "video/jpeg2000" from 5371 [RFC5371]. Additional parameters are specified in Section 5 of this document.
このドキュメントは、関連付けられたメディア・タイプ5371から「ビデオ/ JPEG2000」[RFC5371]を延びています。追加のパラメータは、このドキュメントのセクション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回の連続更新が失われた場合、デコーダは、誤ったメインヘッダを使用して復元を試みます。間違ったメインヘッダが渡される場合でも、標準のJPEG2000復号器は、コードストリームの矛盾を検出し、適切に処理できます。デコーダは、このような矛盾を検出した場合に保存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]普天間、S.、レオン、A.、およびE.板倉、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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勧告。 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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
Appendix A. Sample Headers in Detail
詳細の付録A.サンプル・ヘッダ
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ペイロードヘッダー
A.1. Sample 1: Progressive Image with Single Tile, 3500 Bytes (i.e., thumbnail)
A.1。サンプル1：単一のタイルとプログレッシブ画像、3500バイト（すなわち、サムネイル）
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番目のパケット）
A.2. Sample 2: Image with 4 Tiles
A.2。サンプル2：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のパケットは、このパケットは、第1の時間部分（時間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のパケット：このパケットは二タイルパート（タイル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番目のパケット：このパケットは、第三タイルパート（タイル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
第五パケット：このパケットは第四タイルパート（タイル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パケット）
A.3. Sample 3: Packing Multiple Tiles in Single Payload, Fragmented Header. No Header Compensation, Progressive Image
A.3。サンプル3：シングルペイロード、断片化されたヘッダに複数のタイルをパッキング。ヘッダーなし報酬、プログレッシブ画像
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のパケットこのパケットは、メインヘッダの第二の部分を有しています。 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のパケット：このパケットは、2枚のタイル、タイル0とタイル1 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 | 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パケット）
A.4. Sample 4: Interlace Image, Single Tile
A.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バイトの第二の部分を持っています
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
第五パケット：このパケットは偶数フィールドのために全体のメインヘッダ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
第六パケット：このパケットは偶数フィールドのタイル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
第七パケット：このパケットは偶数フィールドのタイル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| 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
第八パケット：このパケットは偶数フィールドのタイル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)
図23：ヘッダサンプル4-8（8パケット）
Authors' Addresses
著者のアドレス
Andrew Leung Sony Corporation
アンドリュー・レオンソニー株式会社
EMail: andrew@ualberta.net
メールアドレス：andrew@ualberta.net
Satoshi Futemma 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/
電話：+81 3 6748-2111 Eメール：URI satosi-f@sm.sony.co.jp：http://www.sony.net/
Eisaburo Itakura Sony Corporation 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/
電話：+81 3 6748-2111 Eメール：URI itakura@sm.sony.co.jp：http://www.sony.net/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。