[要約] RFC 5371は、JPEG 2000ビデオストリームのRTPペイロード形式に関する仕様です。このRFCの目的は、JPEG 2000ビデオストリームの効率的な転送と処理を可能にするための標準化を提供することです。
Network Working Group S. Futemma
Request for Comments: 5371 E. Itakura
Category: Standards Track A. Leung
Sony
October 2008
RTP Payload Format for JPEG 2000 Video Streams
JPEG 2000ビデオストリームのRTPペイロード形式
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 an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as JPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways. The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images.
このメモは、ISO/IEC International Standard 15444-1のRTPペイロード形式について説明しています。itu-t rec。JPEG 2000としてよく知られているT.800。JPEG2000の機能は、このペイロード形式の設計で考慮されています。JPEG 2000は、アプリケーションが1回エンコードし、さまざまな方法をデコードできるようにする真にスケーラブルな圧縮テクノロジーです。JPEG 2000ビデオストリームは、単一の画像から一連のJPEG 2000画像に拡張することにより形成されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 6
2. JPEG 2000 Video Features . . . . . . . . . . . . . . . . . . . 6
3. Payload Design . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. RTP Fixed Header Usage . . . . . . . . . . . . . . . . . . 7
4.2. RTP Payload Header Format . . . . . . . . . . . . . . . . 8
5. RTP Packetization . . . . . . . . . . . . . . . . . . . . . . 10
6. Media Type Registration . . . . . . . . . . . . . . . . . . . 11
7. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. SDP Mapping . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Usage with the SDP Offer/Answer Model . . . . . . . . . . 15
7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 16
7.2.2. Examples: Non-90kHz Timestamp . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Informative Appendix . . . . . . . . . . . . . . . . 21
A.1. Recommended Practices . . . . . . . . . . . . . . . . . . 21
A.2. Sample Headers in Detail . . . . . . . . . . . . . . . . . 22
A.2.1. Sample 1: Progressive Image with Single Tile, 3500
Bytes (i.e., thumbnail) . . . . . . . . . . . . . . . 22
A.2.2. Sample 2: Image with 4 Tiles . . . . . . . . . . . . . 24
A.2.3. Sample 3: Packing Multiple Tiles in Single
Payload, Fragmented Header . . . . . . . . . . . . . . 25
A.2.4. Sample 4: Interlace Image, Single Tile . . . . . . . . 27
This document specifies a payload format for JPEG 2000 video streams over the Real-time Transport Protocol (RTP). JPEG 2000 is an ISO/IEC International Standard and ITU-T Recommendation (ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800) developed for next-generation, still-image compression. JPEG stands for the Joint Photographers Experts Group, an international group made of academia and industry to develop image compression standards. JPEG 2000 basic compression technology is defined in detail in ISO JPEG 2000 Part 1: Core Coding System [JPEG2000Pt_1], with motion defined in ISO JPEG 2000 Part 3: Motion JPEG 2000 [JPEG2000Pt_3].
このドキュメントは、リアルタイムトランスポートプロトコル（RTP）を介したJPEG 2000ビデオストリームのペイロード形式を指定しています。JPEG 2000は、ISO/IEC International Standard and ITU-Tの推奨（ISO/IEC International Standard 15444-1 | ITU-TRec。T.800）であり、次世代のまだイメージ圧縮のために開発されました。JPEGは、画像圧縮標準を開発するために学界と産業で作られた国際グループである共同写真家の専門家グループを略しています。JPEG 2000基本圧縮技術は、ISO JPEG 2000パート1：コアコーディングシステム[JPEG2000PT_1]で詳細に定義されており、ISO JPEG 2000でモーションが定義されています。
Part 3 of the JPEG 2000 standard defines Motion JPEG 2000 [JPEG2000Pt_3]. However, Motion JPEG 2000 defines a file format, not a transmission format for the network. This document specifies a transmission format for the network for a series of JPEG 2000 images.
JPEG 2000標準のパート3は、モーションJPEG 2000 [JPEG2000PT_3]を定義しています。ただし、Motion JPEG 2000は、ネットワークの送信形式ではなく、ファイル形式を定義します。このドキュメントは、一連のJPEG 2000画像のネットワークの送信形式を指定します。
JPEG 2000 supports many powerful features [JPEG2000Pt_1] [JPEG2000Pt_3] that are not supported in the current JPEG standard, such as:
JPEG 2000は、現在のJPEG標準ではサポートされていない多くの強力な機能[JPEG2000PT_1] [JPEG2000PT_3]をサポートしています。
o Higher compression efficiency than JPEG with less visual distortion especially at extreme compression ratios.
o 特に極端な圧縮比では、視覚的な歪みが少ないJPEGよりも高い圧縮効率。
o A single codestream that offers both lossy and lossless compression.
o 損失と損失のない圧縮の両方を提供する単一のコードストリーム。
o Better error resiliency than JPEG.
o jpegよりも優れたエラー回復力。
o Progressive transmission by pixel accuracy (Signal-to-Noise Ratio (SNR) scalability) and resolution (resolution scalability).
o ピクセル精度（信号対雑音比（SNR）スケーラビリティ）および解像度（解像度のスケーラビリティ）によるプログレッシブ伝送。
o Random codestream access and processing.
o ランダムコードストリームアクセスと処理。
The JPEG 2000 algorithm is briefly explained. Figure 1 shows a block diagram of the JPEG 2000 encoding method.
JPEG 2000アルゴリズムについて簡単に説明します。図1は、JPEG 2000エンコーディング方法のブロック図を示しています。
+-----+
| ROI |
+-----+
|
V
+----------+ +----------+ +------------+
|DC, comp. | | Wavelet | | |
Raw Image ==> |transform-|==>|transform-|==>|Quantization|==+
| ation | | ation | | | |
+----------+ +----------+ +------------+ |
|
+-----------+ +----------+ +------------+ |
| | | | | | |
JPEG 2000 <==| Data |<==| Rate |<==| EBCOT |<=+
codestream | Ordering | | Control | | |
+-----------+ +----------+ +------------+
Figure 1: Block diagram of the JPEG 2000 encoder
図1：JPEG 2000エンコーダーのブロック図
The image is first transformed into wavelet coefficients. The image is sampled into various levels, vertically and horizontally, from high frequencies (which contain sharp details) to low frequencies (which contain smooth areas). Quantization is performed on the coefficients within each sub-band.
画像は最初にウェーブレット係数に変換されます。画像は、垂直および水平方向のさまざまなレベルにサンプリングされ、高周波数（鋭い詳細を含む）から低周波数（滑らかな領域を含む）までサンプリングされます。量子化は、各サブバンド内の係数で実行されます。
After quantization, code blocks are formed from within the precincts within the tiles. (Precincts are a finer separation than tiles, and code blocks are the smallest separation of the image data.) EBCOT coding (Embedded Block Coding Optimized for Truncation) is performed within each code block and arithmetically encoded by bit plane. Rate control is performed to achieve the highest quality image for a specified rate.
量子化後、タイル内の境内からコードブロックが形成されます。（境内はタイルよりも細かい分離であり、コードブロックは画像データの最小の分離です。）EBCOTコーディング（切り捨てのために最適化された組み込みブロックコーディング）は、各コードブロック内で実行され、ビットプレーンによって算術的にエンコードされます。レート制御は、指定されたレートに対して最高品質の画像を実現するために実行されます。
As a result, for a given tile, data units called JPEG 2000 packets are generated, which contain data from a specific layer, specific component, specific resolution, or specific precinct, depending on the data ordering.
その結果、特定のタイルについて、データの順序に応じて、特定のレイヤー、特定のコンポーネント、特定の解像度、または特定の境内からのデータを含むJPEG 2000パケットと呼ばれるデータユニットが生成されます。
Finally, the JPEG 2000 packets are interleaved according to the progression along four axes: layer, resolution, component, and precinct. A JPEG 2000 header is added to become a fully compliant JPEG 2000 codestream.
最後に、JPEG 2000パケットは、レイヤー、解像度、コンポーネント、および境内の4つの軸に沿った進行に応じてインターリーブされます。JPEG 2000ヘッダーが追加され、完全に準拠したJPEG 2000コードストリームになります。
To decompress a JPEG 2000 codestream, one would follow the reverse order of the encoding order, without the rate control.
JPEG 2000 Codestreamを減圧するために、レート制御なしで、エンコード順序の逆順序に従います。
It is outside the scope of this document to further describe in detail this procedure. Please refer to various JPEG 2000 related texts for further details [JPEG2000Pt_1].
このドキュメントの範囲外で、この手順を詳細に説明します。詳細[JPEG2000PT_1]については、さまざまなJPEG 2000関連テキストを参照してください。
Figure 2 shows a JPEG 2000 codestream in detail. A JPEG 2000 codestream is structured from the main header, beginning with the SOC (Start Of Codestream) marker, one or more tiles, and the EOC (End Of Codestream) marker to indicate the end of the codestream. Each tile consists of a tile-part header that starts with the SOT (Start of Tile) marker and ends with a SOD (Start of Data) marker, and bitstream (a series of JPEG 2000 packets).
図2は、JPEG 2000コードストリームを詳細に示しています。JPEG 2000 Codestreamは、Codestreamの終わりを示すために、SOC（Codestreamの開始）マーカー、1つ以上のタイル、およびEOC（Codestreamの終了）マーカーから始まるメインヘッダーから構成されています。各タイルは、SOT（タイルの開始）マーカーで始まり、SOD（データの開始）マーカーで終了するタイルパートヘッダーとビットストリーム（一連のJPEG 2000パケット）で構成されています。
+-- +------------+
Main | | SOC | Required as the first marker
header| +------------+
| | main | Main header marker segments
+-- +------------+
| | SOT | Required at the beginning of each
Tile- | +------------+ tile-part header
part | | T0,TP0 | Tile 0, tile-part 0 header marker
header| +------------+ segments
| | SOD | Required at the end of each tile-part
+-- +------------+ header
| bitstream | Tile-part bitstream
+-- +------------+
| | SOT |
Tile- | +------------+
part | | T1,TP0 |
header| +------------+
| | SOD |
+-- +------------+
| bit stream |
+------------+
.
.
.
+------------+
| EOC | Required as the last marker in the
+------------+ codestream
Figure 2: Basic construction of the JPEG 2000 codestream
図2：JPEG 2000 Codestreamの基本構造
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", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
JPEG 2000 video streams are formed as a continuous series of JPEG 2000 still images. Previously described features of JPEG 2000 may be used effectively in streaming applications for a JPEG 2000 video. A JPEG 2000 video stream has the following qualities:
JPEG 2000ビデオストリームは、JPEG 2000静止画像の連続シリーズとして形成されます。JPEG 2000の以前に説明された機能は、JPEG 2000ビデオのストリーミングアプリケーションで効果的に使用できます。JPEG 2000ビデオストリームには次の品質があります。
o At low bit rates, the SNR is improved dramatically over JPEG and Motion JPEG.
o 低いレートでは、SNRはJPEGおよびモーションJPEGで劇的に改善されます。
o This is a full intra-frame format -- each frame is independently compressed -- and therefore has a low encoding and decoding delay.
o これは完全なフレーム内形式であり、各フレームは独立して圧縮されているため、エンコードとデコードの遅延が低くなります。
o JPEG 2000 has flexible and accurate rate control.
o JPEG 2000には、柔軟で正確なレート制御があります。
o This is suitable for traffic control and congestion control during network transmission.
o これは、ネットワーク伝送中の交通制御と混雑制御に適しています。
o JPEG 2000 can provide its own codestream error resilience markers to aid in codestream recovery outside of this specification.
o JPEG 2000は、この仕様以外のコードストリーム回復を支援する独自のコードストリームエラーレジリエンスマーカーを提供できます。
To design a payload format that maximizes JPEG 2000 features, the following are taken into consideration:
JPEG 2000の機能を最大化するペイロード形式を設計するために、以下を考慮します。
o Provisions for packet loss:
o パケット損失の規定：
On the Internet, 5% packet loss is common and this percentage may vary up to 20% or more. To split JPEG 2000 video streams into RTP packets, efficient packetization of the codestream is required to minimize problems in decoding due to missing packets. If the main header is lost, the image cannot be decoded.
インターネットでは、5％のパケット損失が一般的であり、この割合は最大20％以上になる場合があります。JPEG 2000のビデオストリームをRTPパケットに分割するには、パケットの欠落によるデコードの問題を最小限に抑えるために、コードストリームの効率的なパケット化が必要です。メインヘッダーが失われた場合、画像をデコードできません。
o JPEG 2000 Scalability
o JPEG 2000スケーラビリティ
JPEG 2000 has powerful scalability features and markers in the payload header to indicate the specific meaning of the payload, such as:
JPEG 2000には、ペイロードヘッダーに強力なスケーラビリティ機能とマーカーがあり、次のようなペイロードの特定の意味を示します。
* Special markers for the headers, fragments of headers, etc.
* ヘッダー、ヘッダーの断片などの特別なマーカー。
* Tile numbering for association of packets.
* パケットの関連付けのタイル番号。
* Since this is primarily for video applications, special markers are used to indicate format (i.e., interlace odd/even fields).
* これは主にビデオアプリケーション向けであるため、特別なマーカーは形式（つまり、インターレース奇数/偶数フィールド）を示すために使用されます。
* Priority importance of the packet using methods described in RFC 5372 [RFC5372].
* RFC 5372 [RFC5372]で説明されている方法を使用したパケットの優先度の重要性。
* Main header recovery using methods described in RFC 5372 [RFC5372].
* RFC 5372 [RFC5372]に記載されている方法を使用したメインヘッダーの回復。
Additional usage of the payload header is described in RFC 5372 [RFC5372].
ペイロードヘッダーの追加の使用法は、RFC 5372 [RFC5372]で説明されています。
For each RTP packet, the RTP fixed header is followed by the JPEG 2000 RTP payload header, which is followed by the payload, a piece of a JPEG 2000 codestream, which is usually a JPEG 2000 packet.
各RTPパケットについて、RTP固定ヘッダーの後にJPEG 2000 RTPペイロードヘッダーが続き、その後、通常はJPEG 2000パケットであるJPEG 2000コードストリームの一部です。
The RTP header fields that have a meaning specific to a JPEG 2000 video stream are described as follows:
JPEG 2000ビデオストリームに固有の意味を持つRTPヘッダーフィールドは、次のように説明されています。
Marker bit (M): The marker bit of the RTP fixed header MUST be set to 1 for the last RTP packet of a video frame; otherwise, it MUST be 0. When transmission is performed by multiple RTP sessions, this bit is 1 in the last packet of the frame in each session.
マーカービット（M）：RTP固定ヘッダーのマーカービットは、ビデオフレームの最後のRTPパケットで1に設定する必要があります。それ以外の場合は、0でなければなりません。複数のRTPセッションによって送信が実行される場合、このビットは各セッションのフレームの最後のパケットの1です。
Payload type (PT): The payload type is dynamically assigned by means outside the scope of this document. A payload type in the dynamic range shall be chosen by means of an out-of-band signaling protocol (i.e., Real Time Streaming Protocol (RTSP), SIP, etc.).
ペイロードタイプ（PT）：ペイロードタイプは、このドキュメントの範囲外の手段によって動的に割り当てられます。ダイナミックレンジのペイロードタイプは、バンド外シグナリングプロトコル（つまり、リアルタイムストリーミングプロトコル（RTSP）、SIPなど）によって選択されます。
Timestamp: Timestamp indicates the presentation time of the frame contained in the RTP packet. The same timestamp value MUST appear in each RTP packet carrying a fragment of a given frame. When a JPEG 2000 image is in interlace format, the odd field and the corresponding even field MUST have the same timestamp value. Following the RTP specification [RFC3550], the initial value of the timestamp should be randomly chosen.
タイムスタンプ：タイムスタンプは、RTPパケットに含まれるフレームのプレゼンテーション時間を示します。特定のフレームのフラグメントを運ぶ各RTPパケットに同じタイムスタンプ値が表示される必要があります。JPEG 2000の画像がインターレース形式である場合、奇数フィールドと対応する均等なフィールドは同じタイムスタンプ値を持たなければなりません。RTP仕様[RFC3550]に続いて、タイムスタンプの初期値をランダムに選択する必要があります。
As for the clock rate, senders and receivers MUST support the 90kHz RTP timestamp rate, and MAY support other rates. RTP timestamp rates below 1000 Hz SHOULD NOT be used because they will result in insufficient resolution for RTP Control Protocol (RTCP) measurements based on the RTP timestamp, such as the interarrival jitter. The clock rate MUST be negotiated at the start of the session. When using the Session Description Protocol (SDP), it MUST be expressed using the "rtpmap" attributes. If a non-90kHz clock rate is to be used, it is RECOMMENDED to present not only a preferable clock rate but also 90kHz clock rate with a different RTP payload type.
クロックレートに関しては、送信者と受信者は90kHzのRTPタイムスタンプレートをサポートし、他のレートをサポートする必要があります。RTPタイムスタンプレートは、1000 Hz未満のレートを使用しては、RTPコントロールプロトコル（RTCP）測定値が不十分なRTPタイムスタンプに基づいて、RTP Control Protocol（RTCP）測定値（RTP）測定値が不十分であるため、使用しないでください。クロックレートは、セッションの開始時に交渉する必要があります。セッション説明プロトコル（SDP）を使用する場合、「rtpmap」属性を使用して表現する必要があります。90kHz以外のクロックレートを使用する場合、好ましいクロックレートだけでなく、異なるRTPペイロードタイプの90kHzクロックレートを提示することをお勧めします。
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 3: RTP payload header format for JPEG 2000
図3：JPEG 2000のRTPペイロードヘッダー形式
tp (type): 2 bits
TP（タイプ）：2ビット
This field indicates how a JPEG 2000 image is scanned (progressive or interlace).
このフィールドは、JPEG 2000の画像がどのようにスキャンされるかを示しています（プログレッシブまたはインターレース）。
0: The payload is progressively scanned.
0：ペイロードは徐々にスキャンされます。
1: The payload is part of an odd field of an interlaced video frame. The height specified in the JPEG 2000 main header is half of the height of the entire displayed image. In a receiver, an odd field should be de-interlaced with the even field following it so that lines from each image are displayed alternately.
1：ペイロードは、インターレースビデオフレームの奇妙なフィールドの一部です。JPEG 2000メインヘッダーで指定されている高さは、表示された画像全体の高さの半分です。レシーバーでは、各画像の線が交互に表示されるように、奇妙なフィールドを均一なフィールドと再インタレースする必要があります。
2: The payload is part of an even field of an interlaced video signal.
2：ペイロードは、インターレースビデオ信号の均一なフィールドの一部です。
MHF (Main Header Flag): 2 bits
MHF（メインヘッダーフラグ）：2ビット
MHF indicates whether a main header or packet of a main header is in the RTP packet.
MHFは、メインヘッダーのメインヘッダーまたはパケットがRTPパケットにあるかどうかを示します。
If there is no header, MHF has a value of 0. If there is just a part of a fragmented header, MHF has a value of 1. If there is the last part of a fragmented header, MHF has value of 2. If the whole header is in the packet, MHF has a value of 3.
ヘッダーがない場合、MHFの値は0です。断片化されたヘッダーの一部しかない場合、MHFの値は1の値です。断片化ヘッダーの最後の部分がある場合、MHFの値は2です。ヘッダー全体がパケットにあり、MHFの値は3です。
+-----------+----------------------------------+
| MHF Value | Description |
+-----------+----------------------------------+
| 0 | no main header in the payload |
| 1 | piece of fragmented header |
| 2 | last part of a fragmented header |
| 3 | a whole main header |
+-----------+----------------------------------+
Table 1: MHF Usage Values
表1：MHFの使用値
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メインヘッダーリカバリに使用されます。
For implementations following only this specification, the sender SHOULD set this value to 0 and the receiver SHOULD ignore this field on processing.
この仕様のみに従う実装の場合、送信者はこの値を0に設定する必要があり、受信機は処理時にこのフィールドを無視する必要があります。
T (Tile field invalidation flag): 1 bit
T（タイルフィールドの無効なフラグ）：1ビット
The T bit indicates whether the tile number field is valid or invalid. A sender MUST set the T bit to 1 when invalid and 0 when valid.
Tビットは、タイル番号フィールドが有効か無効かを示します。送信者は、無効な場合はtビットを1に、有効な場合は0に設定する必要があります。
There are two cases where the tile number field is invalid:
タイル番号フィールドが無効な2つのケースがあります。
* When an RTP packet holds only the main header. A sender cannot set any number in the tile number field, as no JPEG 2000 tile-part bitstream is included in the RTP packet.
* RTPパケットがメインヘッダーのみを保持する場合。JPEG 2000タイルパートビットストリームがRTPパケットに含まれていないため、送信者はタイル番号フィールドに任意の数字を設定できません。
* Multiple tile-parts are packed together in a single payload. If there are multiple tiles packed into a single payload, there is no meaning to assign a number to the tile number field.
* 複数のタイルパートが単一のペイロードで一緒に詰め込まれています。複数のタイルが単一のペイロードに詰め込まれている場合、タイル番号フィールドに番号を割り当てるという意味はありません。
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 that contain the lower sub-bands.
優先フィールドは、ペイロードに含まれるJPEG 2000パケットの重要性を示しています。通常、下部サブバンドを含むJPEG 2000パケットを含むパケットには、より高い優先度値が設定されています。
For implementations following only this specification, the sender SHOULD set this value to 255 and the receiver SHOULD ignore this field on processing.
この仕様のみに従う実装の場合、送信者はこの値を255に設定し、受信者は処理時にこのフィールドを無視する必要があります。
tile number: 16 bits
タイル番号：16ビット
This field shows the tile number of the payload. This field is only valid when the T bit is 0. If the T bit is set to 1, the receiver MUST ignore this field.
このフィールドは、ペイロードのタイル番号を示しています。このフィールドは、tビットが0の場合にのみ有効です。tビットが1に設定されている場合、受信機はこのフィールドを無視する必要があります。
R (Reserved): 8 bits
R（予約済み）：8ビット
This bit is reserved for future use. Senders MUST set this to 0. Receivers MUST ignore this field.
このビットは、将来の使用のために予約されています。送信者はこれを0に設定する必要があります。受信機はこのフィールドを無視する必要があります。
fragment offset: 24 bits
フラグメントオフセット：24ビット
This value MUST be set to the byte offset of the current payload in relation to the very beginning of each JPEG 2000 codestream (JPEG 2000 frame).
この値は、各JPEG 2000 Codestream（JPEG 2000フレーム）のまさに始まりに関連して、現在のペイロードのバイトオフセットに設定する必要があります。
Byte offsets are calculated from the start of each JPEG 2000 codestream up to the current position where the current payload would fit into the complete JPEG 2000 codestream.
バイトオフセットは、各JPEG 2000コードストリームの開始から現在の位置まで計算され、現在のペイロードが完全なJPEG 2000コードストリームに収まります。
To perform scalable video delivery by using multiple RTP sessions, the offset value from the first byte of the same frame is set for fragment offset. It is then possible to deliver layered video using multiple RTP sessions; the fragment offset might not start from 0 in some RTP sessions even if the packet is the first one received in the RTP session.
複数のRTPセッションを使用してスケーラブルなビデオ配信を実行するには、同じフレームの最初のバイトからのオフセット値がフラグメントオフセットに設定されています。その後、複数のRTPセッションを使用してレイヤードビデオを配信することができます。Fragmentオフセットは、RTPセッションで最初に受け取ったセッションであっても、一部のRTPセッションで0から開始されない場合があります。
The sender must packetize the JPEG 2000 appropriately according to initial media type parameters and/or details from SDP offer/answer parameters.
送信者は、SDPオファー/回答パラメーターの初期メディアタイプパラメーターおよび/または詳細に従って、JPEG 2000を適切にパケット化する必要があります。
A "packetization unit" is defined as either a JPEG 2000 main header, a tile-part header, or a JPEG 2000 packet.
「パケット化ユニット」は、JPEG 2000メインヘッダー、タイルパートヘッダー、またはJPEG 2000パケットのいずれかとして定義されます。
First, a sender divides the JPEG 2000 codestream into packetization units by parsing the codestream or by getting information from the encoder, and packs the packetization units into RTP packets. A sender can put an arbitrary number of packetization units into an RTP packet, but it MUST preserve the codestream order. An example of this kind of RTP packet format is shown in Figure 4:
まず、送信者は、JPEG 2000 Codestreamをコードストリームを解析するか、エンコーダーから情報を取得してパケット化ユニットに分割し、パケット化ユニットをRTPパケットに詰めます。送信者は、任意の数のパケット化ユニットをRTPパケットに入れることができますが、コードストリームの順序を保持する必要があります。この種のRTPパケット形式の例を図4に示します。
+------+-------+---------------+---------------+
|RTP |payload| packetization | packetization |
|header|header | unit | unit |
+------+-------+---------------+---------------+
Figure 4: An example with multiple packetization units
図4：複数のパケット化ユニットを含む例
If a packetization unit with headers (IP header, RTP header, and payload header) is larger than the MTU size, it MAY be fragmented. To pack a fragmented packetization unit, the fragmented unit MUST NOT be packed with the succeeding packetization unit within the same RTP packet. An example of this kind of RTP packet format is shown in Figure 5:
ヘッダーを備えたパケット化ユニット（IPヘッダー、RTPヘッダー、ペイロードヘッダー）がMTUサイズよりも大きい場合、断片化される可能性があります。断片化されたパケット化ユニットを梱包するには、断片化されたユニットに、同じRTPパケット内の後続のパケット化ユニットを梱包してはなりません。この種のRTPパケット形式の例を図5に示します。
+------+-------+-------------------------------------------------+
|RTP |payload| packetization unit fragment |
|header|header | |
+------+-------+-------------------------------------------------+
+------+-------+-------------------------------------------------+
|RTP |payload| packetization unit fragment |
|header|header | |
+------+-------+-------------------------------------------------+
.
.
.
+------+-------+------------------------------------+
|RTP |payload| end of packetization unit fragment |
|header|header | |
+------+-------+------------------------------------+
Figure 5: An example with a fragmented packetization unit
図5：断片化されたパケット化ユニットの例
This registration uses the template defined in [RFC4288] and follows [RFC4855].
この登録は、[RFC4288]で定義されたテンプレートを使用し、[RFC4855]に続きます。
Type name: video Subtype name: jpeg2000
タイプ名：ビデオサブタイプ名：JPEG2000
Required parameters:
必要なパラメーター：
rate: The RTP timestamp clock rate. The default rate is 90000, but other rates MAY be specified. Rates below 1000 Hz SHOULD NOT be used.
レート：RTPタイムスタンプ時計レート。デフォルトレートは90000ですが、その他のレートが指定される場合があります。1000 Hz未満の料金は使用しないでください。
sampling: A list of values specifying the color space of the payload data.
サンプリング：ペイロードデータの色空間を指定する値のリスト。
Acceptable values:
許容可能な値：
RGB: standard Red, Green, Blue color space.
RGB：標準の赤、緑、青色の空間。
BGR: standard Blue, Green, Red color space.
BGR：標準の青、緑、赤い色のスペース。
RGBA: standard Red, Green, Blue, Alpha color space.
RGBA：標準の赤、緑、青、アルファカラースペース。
BGRA: standard Blue, Green, Red, Alpha color space.
Bgra：標準の青、緑、赤、アルファカラースペース。
YCbCr-4:4:4: standard YCbCr color space; no subsampling.
YCBCR-4：4：4：標準YCBCRカラースペース。サブサンプリングはありません。
YCbCr-4:2:2: standard YCbCr color space; Cb and Cr are subsampled horizontally by 1/2.
YCBCR-4：2：2：標準YCBCRカラースペース。CBとCRは、水平に1/2でサブサンプリングされます。
YCbCr-4:2:0: standard YCbCr color space; Cb and Cr are subsampled horizontally and vertically by 1/2.
YCBCR-4：2：0：標準YCBCRカラースペース。CBとCRは、1/2で水平および垂直にサブサンプリングされます。
YCbCr-4:1:1: standard YCbCr color space; Cb and Cr are subsampled vertically by 1/4.
YCBCR-4：1：1：標準YCBCRカラースペース。CBとCRは、1/4で垂直にサブサンプリングされます。
GRAYSCALE: basically, a single component image of just multilevels of grey.
Grayscale：基本的に、グレーのマルチレベルだけの単一のコンポーネント画像。
EXTENSION VALUE: Additional color samplings can be registered with the current listing of registered color samplings at: Color Sampling Registration Authority. Please refer to RTP Format for Uncompressed Video [RFC4175].
拡張値：追加の色のサンプリングは、登録された色サンプリングの現在のリストに登録できます。色サンプリング登録局。非圧縮ビデオ[RFC4175]については、RTP形式を参照してください。
Optional parameters:
オプションのパラメーター：
interlace: Interlace scanning. If the payload is in interlace format, the acceptable value is "1"; otherwise, the value should be "0". Each complete image forms, vertically, half the display. The tp value MUST properly specify the field the image represents: odd(tp=1) or even(tp=2). If this option is not present, the payload MUST be in progressive format and the tp MUST be set to 0.
インターレース：インターレーススキャン。ペイロードがインターレース形式の場合、許容値は「1」です。それ以外の場合、値は「0」でなければなりません。各完全な画像は、垂直に、ディスプレイの半分を形成します。TP値は、画像が表すフィールドを適切に指定する必要があります：ODD（TP = 1）または（TP = 2）。このオプションが存在しない場合、ペイロードはプログレッシブ形式で、TPを0に設定する必要があります。
width: A parameter describing the maximum width of the video stream. This parameter MUST appear when height is present. Acceptable values: -- an integer value between 0 -- 4,294,967,295.
幅：ビデオストリームの最大幅を記述するパラメーター。このパラメーターは、高さが存在するときに表示する必要があります。許容値：-0-4,294,967,295の間の整数値。
height: A parameter describing the maximum height of the video stream. This parameter MUST appear when width is present. Acceptable values: -- an integer value between 0 -- 4,294,967,295.
高さ：ビデオストリームの最大高さを表すパラメーター。このパラメーターは、幅が存在するときに表示する必要があります。許容値：-0-4,294,967,295の間の整数値。
The receiver MUST ignore any unspecified parameters.
受信者は、不特定のパラメーターを無視する必要があります。
Encoding considerations:
考慮事項のエンコード：
This media type is framed and binary, see Section 4.8 of [RFC4288].
このメディアタイプは、[RFC4288]のセクション4.8を参照してください。
Security considerations: See Section 9 of this document.
セキュリティ上の考慮事項：このドキュメントのセクション9を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
The JPEG 2000 video stream is a sequence of JPEG 2000 still images. An implementation compliant with [JPEG2000Pt_1] can decode and attempt to display the encoded JPEG 2000 video stream.
JPEG 2000ビデオストリームは、JPEG 2000静止画像のシーケンスです。[JPEG2000PT_1]に準拠した実装は、エンコードされたJPEG 2000ビデオストリームをデコードして表示しようとします。
Published specification: ISO/IEC 15444-1 | ITU-T Rec. T.800
公開された仕様：ISO/IEC 15444-1 |itu-t rec。T.800
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
video streaming and communication
ビデオストリーミングとコミュニケーション
Person and email address to contact for further information:
詳細については、人とメールアドレスをお問い合わせください。
Eisaburo Itakura, Satoshi Futemma, Andrew Leung Email: itakura@sm.sony.co.jp, satosi-f@sm.sony.co.jp, andrew@ualberta.net
eisaburo itakura、atshi fifemma、andrew leungメール：itakura@sm.sony.co.jp、atosi-f@sm.sony.co.jp、andrew@ualberta.net
Intended usage: COMMON
意図された使用法：共通
Restrictions on Usage:
使用に関する制限：
This media type depends on RTP framing, and hence is only defined for the transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at the time.
このメディアタイプはRTPフレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。他のフレーミングプロトコル内の輸送は、当時定義されていません。
Author/Change Controller:
著者/変更コントローラー：
Author:
著者：
Eisaburo Itakura, Satoshi Futemma, Andrew Leung Email: itakura@sm.sony.co.jp, satosi-f@sm.sony.co.jp, andrew@ualberta.net
eisaburo itakura、atshi fifemma、andrew leungメール：itakura@sm.sony.co.jp、atosi-f@sm.sony.co.jp、andrew@ualberta.net
Change controller:
Change Controller：
IETF Audio/Video Transport Working Group delegated from the IESG.
IETFオーディオ/ビデオトランスポートワーキンググループは、IESGから委任されました。
The media type video/jpeg2000 string is mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:
メディアタイプのビデオ/JPEG2000文字列は、次のようにセッション説明プロトコル（SDP）[RFC4566]のフィールドにマッピングされます。
o The media name in the "m=" line of SDP MUST be video.
o SDPの「m =」行のメディア名はビデオでなければなりません。
o The encoding name in the "a=rtpmap" line of SDP MUST be jpeg2000 (the subtype).
o SDPの「a = rtpmap」行のエンコード名は、jpeg2000（サブタイプ）でなければなりません。
o The clock rate in the "a=rtpmap" line is set according to the "rate" parameter. Senders that wish to use a non-90kHz rate SHOULD also offer the same stream using a 90kHz timestamp rate with a different RTP payload type, allowing graceful fallback to 90kHz for compatibility.
o 「a = rtpmap」行のクロックレートは、「レート」パラメーターに従って設定されます。90kHz以外のレートを使用したい送信者は、異なるRTPペイロードタイプの90kHzタイムスタンプレートを使用して同じストリームを提供する必要があります。
o The REQUIRED parameter, "sampling", MUST be included in the "a=fmtp" line of SDP.
o 必要なパラメーター「サンプリング」は、SDPの「a = fmtp」行に含める必要があります。
o The OPTIONAL parameters, if presented, MUST be included in the "a=fmtp" line of SDP.
o オプションのパラメーターは、提示された場合、SDPの「a = fmtp」行に含める必要があります。
These parameters are expressed as a media type string, in the form of a semicolon separated list of parameter=value pairs.
これらのパラメーターは、パラメーター=値ペアのセミコロン分離リストの形で、メディアタイプの文字列として表されます。
Therefore, an example of media representation in SDP using typical parameters is as follows:
したがって、典型的なパラメーターを使用したSDPのメディア表現の例は次のとおりです。
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128
An example for using non-90kHz timestamp is as follows:
90kHz以外のタイムスタンプを使用する例は次のとおりです。
m=video 49170/2 RTP/AVP 98 99
a=rtpmap:98 jpeg2000/27000000
a=rtpmap:99 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128
a=fmtp:99 sampling=YCbCr-4:2:0;width=128;height=128
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 the parameter.
o すべてのパラメーターには、パラメーターに対して許容値が必要です。
o All parameters MUST correspond to the parameters of the payload.
o すべてのパラメーターは、ペイロードのパラメーターに対応する必要があります。
o The parameter "sampling" with an acceptable answer MUST appear in the offer and in the answer if accepted by the receiver. The receiver SHOULD do its best to handle the received codestream in the color space offered. If the receiver cannot handle the offered color space for whatever reason, it should reply with its preferred color space in the answer and gracefully end the session. Senders do not need to conform to the color space in the answer, but they should take note that the session ended due to color sampling issues.
o 許容可能な回答を使用したパラメーター「サンプリング」は、受信者が受け入れた場合は、オファーと回答に表示する必要があります。レシーバーは、提供されているカラースペースの受信したコードストリームを処理するために最善を尽くす必要があります。レシーバーが何らかの理由で提供されたカラースペースを処理できない場合、回答の好ましい色のスペースで返信し、セッションを優雅に終了する必要があります。送信者は、答えのカラー空間に準拠する必要はありませんが、色のサンプリングの問題によりセッションが終了したことに注意する必要があります。
o For optional parameter "interlace", if this option is used, it MUST appear in the offer and, if accepted, it SHOULD appear in the answer. Receivers should do their best to handle interlace or progressive codestreams but, if for some reason, receivers cannot accommodate, receivers should reply with preferred settings in the answer, then gracefully end the session. Senders do not need to adjust settings upon this answer, but they should take note that the session ended due to interlace or progressive issues.
o オプションのパラメーター「インターレース」の場合、このオプションを使用する場合、オファーに表示され、受け入れられた場合は回答に表示される必要があります。受信者は、インターレースまたはプログレッシブコードストリームを処理するために最善を尽くす必要がありますが、何らかの理由で受信者が収容できない場合は、受信者が回答の優先設定で返信し、セッションを優雅に終了する必要があります。送信者は、この回答に合わせて設定を調整する必要はありませんが、セッションがインターレースまたは進歩的な問題のために終了したことに注意する必要があります。
o For optional parameters "width" and "height", the following applies:
o オプションのパラメーター「幅」と「高さ」の場合、次のものが適用されます。
* if "width" appears in the offer or answer, "height" MUST be present.
* オファーまたは回答に「幅」が表示される場合、「高さ」が存在する必要があります。
* if "height" appears in the offer or answer, "width" MUST be present.
* 「高さ」がオファーまたは回答に表示される場合、「幅」が存在する必要があります。
o Width and height should appear in the offer as the maximum dimensions the sender can offer. In the answer, it SHOULD represent the maximum the receiver can accommodate. If there is a difference between the offer and answer, the sender should re-offer a new width and height and appropriately scale down the codestream for the receiver.
o 送信者が提供できる最大寸法として、オファーに幅と高さが表示される必要があります。答えでは、受信者が収容できる最大値を表す必要があります。オファーと回答の間に違いがある場合、送信者は新しい幅と高さを再採用し、レシーバーのコードストリームを適切に縮小する必要があります。
o In a multicast environment, [RFC1112] receivers should do their best to conform to parameters in the offer from the sender. Senders should use recommended settings in multicast environments and take note of answers. For width and height, the sender should accommodate to the lowest values it receives from all answers.
o マルチキャスト環境では、[RFC1112]レシーバーは、送信者からのオファーのパラメーターに適合するために最善を尽くす必要があります。送信者は、マルチキャスト環境で推奨される設定を使用し、回答に注意する必要があります。幅と高さの場合、送信者は、すべての回答から受信する最低値に対応する必要があります。
o Any unknown options in the offer should be ignored and deleted from the answer.
o オファーの未知のオプションは無視し、回答から削除する必要があります。
Example offer/answer exchanges are provided.
オファー/回答の例が提供されます。
Alice offers YCbCr 4:2:2 color space, interlace image with 720-pixel width and 480-pixel height as below:
アリスはYCBCR 4：2：2の色空間、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 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480
Bob accepts YCbCr-4:2:2 color space, interlace image 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 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480
Example offer/answer exchanges, where an offerer wishes to use non-90kHz timestamp, are provided.
オファー/アンサーの例は、90kHz以外のタイムスタンプを使用したい場合に提供されます。
Alice offers an RTP payload type with 27MHz clock rate as well as with 90kHz clock rate, and each payload type includes: YCbCr 4:2:2 color space, interlace image, 720-pixel width and 480-pixel height.
アリスは、27MHzのクロックレートと90kHzクロックレートのRTPペイロードタイプを提供し、各ペイロードタイプにはYCBCR 4：2：2カラースペース、インターレース画像、720ピクセル幅、480ピクセルの高さが含まれます。
She puts 27MHz clock rate attributes prior to 90kHz because she wants to use 27 MHz rather than 90kHz.
彼女は、90kHzではなく27 MHzを使用したいため、90kHzの前に27MHzのクロックレート属性を配置します。
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 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480
a=fmtp:99 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480
If Bob can accept 27MHz clock rate, he replies as below:
ボブが27MHzの時計レートを受け入れることができる場合、彼は以下のように答えます。
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 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480
If Bob doesn't accept 27MHz clock rate, he replies as below:
ボブが27MHzの時計レートを受け入れない場合、彼は以下のように答えます。
v=0
o=bob 2890844730 2890844731 IN IP4 host.example
s=
c=IN IP4 host.example
t=0 0
m=video 49920 RTP/AVP 99
a=rtpmap:99 jpeg2000/90000
a=fmtp:99 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480
A new media subtype (video/jpeg2000) has been registered by IANA. For details, see Section 6 of this document.
新しいメディアサブタイプ（ビデオ/JPEG2000）がIANAによって登録されています。詳細については、このドキュメントのセクション6を参照してください。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550], and in any applicable RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets is through the use of suitable cryptographic integrity protection mechanism. A cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least a source authentication method capable of determining whether or not an RTP packet is from a member of the RTP session.
この仕様で定義されたペイロード形式を使用したRTPパケットは、RTP仕様[RFC3550]および該当するRTPプロファイルで説明されているセキュリティ上の考慮事項の対象となります。このメモ内で定義されているRTPペイロード形式を運ぶRTPパケットの主なセキュリティ上の考慮事項は、機密性、整合性、およびソースの信頼性です。機密性は、RTPペイロードの暗号化によって達成されます。RTPパケットの整合性は、適切な暗号整合性保護メカニズムを使用することです。暗号化システムは、ペイロードのソースの認証を可能にする場合があります。このRTPペイロード形式の適切なセキュリティメカニズムは、機密性、整合性保護、および少なくともRTPパケットがRTPセッションのメンバーからのものであるかどうかを判断できるソース認証方法を提供する必要があります。
Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, the usage of SRTP [RFC3711] is recommended. Other mechanism that may be used are IPsec [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over TCP), but other alternatives may also exist.
このメモに従ってRTPとペイロードにセキュリティを提供する適切なメカニズムは異なる場合があることに注意してください。アプリケーション、輸送、および採用されたシグナルプロトコルに依存します。したがって、単一のメカニズムは十分ではありませんが、適切な場合はSRTP [RFC3711]の使用が推奨されます。使用できる他のメカニズムは、IPSEC [RFC4301]と輸送層セキュリティ（TLS）[RFC5246]（TCPを介したRTP）ですが、他の代替品も存在する可能性があります。
If Quality of Service (QoS) enhanced service is used, RTP receivers SHOULD monitor packet loss to ensure that the service that was requested is actually being delivered. If it is not, then they SHOULD assume that they are receiving best-effort service and behave accordingly.
サービス品質（QOS）強化サービスが使用される場合、RTPレシーバーはパケットの損失を監視して、要求されたサービスが実際に配信されていることを確認する必要があります。そうでない場合、彼らは彼らが最高のエフォルトサービスを受けており、それに応じて振る舞っていると仮定する必要があります。
If best-effort service is being used, users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path, experiencing the same network conditions, would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high.
Best-Effortサービスが使用されている場合、このペイロード形式のユーザーは、パケットの損失を監視して、パケットの損失率が許容可能なパラメーター内にあることを確認する必要があります。同じネットワークパスを越えたTCPフローが同じネットワーク条件を経験し、合理的なタイムスケールで測定された平均スループットを達成する場合、パケットの損失は許容できると見なされます。この条件は、透過速度（または層状マルチキャストセッションにサブスクライブされるレイヤー数）を適応させるための輻輳制御メカニズムを実装すること、または損失率が容認できないほど高い場合にセッションを去るように配置することにより、満たすことができます。
[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月。
[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月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「安全なリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロードフォーマットのメディアタイプ登録」、RFC 4855、2007年2月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[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月。
[JPEG2000Pt_3] ISO/IEC JTC1/SC29, ISO/IEC 15444-1 | ITU-T Rec. T.800, "Information Technology - JPEG 2000 Image Coding System - Part 3: Motion JPEG 2000", July 2002.
[JPEG2000PT_3] ISO/IEC JTC1/SC29、ISO/IEC 15444-1 |itu-t rec。T.800、「情報技術-JPEG 2000画像コーディングシステム-PART 3：MOTION JPEG 2000」、2002年7月。
[RFC5372] Leung, A., Futemma, S., and E. Itakura, "Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery", RFC 5372, October 2008.
[RFC5372] Leung、A.、Fipemma、S。、およびE. Itakura、「JPEG 2000ビデオのペイロード形式：スケーラビリティおよびメインヘッダーリカバリのための拡張」、RFC 5372、2008年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for Uncompressed Video", RFC 4175, September 2005.
[RFC4175] Gharai、L。およびC. Perkins、「非圧縮ビデオのRTPペイロード形式」、RFC 4175、2005年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
As the JPEG 2000 coding standard is highly flexible, many different but compliant data streams may be produced and still be compliant JPEG 2000 codestreams.
JPEG 2000コーディング標準は非常に柔軟であるため、多くの異なるが準拠したデータストリームが生成される可能性があり、依然としてJPEG 2000コードストリームに準拠しています。
The following is a set of recommendations set forth from our experience in developing JPEG 2000 and this payload specification. Implementations of this standard must handle all possibilities mentioned in this specification. The following is a listing of items an implementation may optimize.
以下は、JPEG 2000とこのペイロード仕様の開発経験から記載されている一連の推奨事項です。この標準の実装は、この仕様に記載されているすべての可能性を処理する必要があります。以下は、実装が最適化できるアイテムのリストです。
Error Resilience Markers: The use of error resilience markers in the JPEG 2000 data stream is highly recommended in all situations. Error recovery with these markers is helpful to the decoder and saves external resources (e.g., markers such as RESET, RESTART, and ERTERM).
エラーレジリエンスマーカー：JPEG 2000データストリームでのエラーレジリエンスマーカーの使用は、すべての状況で強く推奨されます。これらのマーカーを使用したエラー回復は、デコーダーに役立ち、外部リソース（リセット、再起動、ERTermなどのマーカーなど）を保存します。
YCbCr Color Space: The YCbCr color space provides the greatest amount of compression in color with respect to the human visual system. When used with JPEG 2000, this color space can provide excellent visual results at low bit rates.
YCBCRカラースペース：YCBCRカラースペースは、人間の視覚システムに関して、色が最大の圧縮を提供します。JPEG 2000で使用すると、この色空間は低ビットレートで優れた視覚結果を提供できます。
Progression Ordering: JPEG 2000 offers many different ways to order the final code stream to optimize the transfer with the presentation. We have found that the most useful codestream ordering is layer progression and resolution progression ordering.
進行順序：JPEG 2000は、プレゼンテーションで転送を最適化するために最終コードストリームを注文するさまざまな方法を提供します。最も有用なコードストリームの順序は、層の進行と解像度の進行順序であることがわかりました。
Tiling and Packets: JPEG 2000 packets are formed regardless of the encoding method. The encoder has little control over the size of these JPEG 2000 packets as they may be large or small. Tiling splits the image into smaller areas and each is encoded separately. With tiles, the JPEG 2000 packet sizes are also reduced. When using tiling, almost all JPEG 2000 packet sizes are an acceptable size for transmission (i.e., smaller than the MTU size of most networks).
タイルとパケット：JPEG 2000パケットは、エンコーディング方法に関係なく形成されます。エンコーダーは、これらのJPEG 2000パケットのサイズを大きくても小さい場合があるため、ほとんど制御できません。タイルは画像をより小さな領域に分割し、それぞれが個別にエンコードされます。タイルを使用すると、JPEG 2000パケットサイズも削減されます。タイルを使用する場合、ほとんどすべてのJPEG 2000パケットサイズは、送信に許容可能なサイズです（つまり、ほとんどのネットワークのMTUサイズよりも小さくなります）。
Sender Processing: There are no limitations as to how the sender should pack the payload. In general, the sender should pack headers separately from the rest of the codestream to make header recovery simple. Payloads should generally begin with a Start of Packet (SOP) marker and end with an End of Packet Header (EPH) marker for easier decoder processing.
送信者処理：送信者がペイロードをどのように梱包するかについての制限はありません。一般に、送信者は、ヘッダーの回復をシンプルにするために、コードストリームの残りの部分とは別にヘッダーを梱包する必要があります。ペイロードは通常、パケット（SOP）マーカーの開始から始まり、デコーダー処理を容易にするためのパケットヘッダー（EPH）マーカーの端で終了する必要があります。
This section has various sample headers in various configurations for reference.
このセクションには、参照用のさまざまな構成にさまざまなサンプルヘッダーがあります。
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 6: JPEG 2000 Payload Header
図6：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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 000 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Header Sample 1-1 (First Packet)
図7：ヘッダーサンプル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 | 3 | 0 |0| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 2DB3 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Header Sample 1-2 (Second Packet)
図8：ヘッダーサンプル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 | 0 |0| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1710 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E841 4526 4556 9850 C2EA ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Header Sample 1-3 (Third Packet)
図9：ヘッダーサンプル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 | 0 |0| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A55D 8B73 3B25 25C7 B9EB ... 2FBE B153|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Header Sample 1-4 (4th Packet)
図10：ヘッダーサンプル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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 000 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Header Sample 2-1 (First Packet)
図11：ヘッダーサンプル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 | 0 |0| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Header Sample 2-2 (Second Packet)
図12：ヘッダーサンプル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 | 0 |0| 255 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0001 0000 058F 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Sample 2-3 (Third Packet)
図13：ヘッダーサンプル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 | 0 |0| 255 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3033 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 054B 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Header Sample 2-4 (4th Packet)
図14：ヘッダーサンプル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 | 0 |0| 255 | 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 4388 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0003 0000 050A 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Header Sample 2-5 (5th Packet)
図15：ヘッダーサンプル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| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 000 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Header Sample 3-1 (First Packet)
図16：ヘッダーサンプル3-1（最初のパケット）
Second Packet: This packet has the second part of the header 1400 bytes
2番目のパケット：このパケットには、ヘッダー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 | 2 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 110 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF64 00FF ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Header Sample 3-2 (Second Packet)
図17：ヘッダーサンプル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| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1510 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 02BC 0001 FF93 ... |
// //
|FF90 000A 0001 0000 02BC 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Header Sample 3-3 (Third Packet)
図18：ヘッダーサンプル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| 255 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 2910 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0002 0000 0573 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Header Sample 3-4 (4th Packet)
図19：ヘッダーサンプル3-4（4番目のパケット）
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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 000 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Header Sample 4-1 (First Packet)
図20：ヘッダーサンプル4-1（最初のパケット）
Second packet: This packet will have the first part of the odd field's tile 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Header Sample 4-2 (Second Packet)
図21：ヘッダーサンプル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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|7F04 E708 27D9 D11D 22CB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Header Sample 4-3 (Third Packet)
図22：ヘッダーサンプル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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|98BD EC9B 2826 DC62 D4AB ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Header Sample 4-4 (4th Packet)
図23：ヘッダーサンプル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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF4F FF51 002F 000 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Header Sample 4-5 (5th Packet)
図24：ヘッダーサンプル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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 210 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF90 000A 0000 0000 0578 0001 FF93 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Header Sample 4-6 (6th Packet)
図25：ヘッダーサンプル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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 1610 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|626C 42F0 166B 6BD0 F8E1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: Header Sample 4-7 (7th Packet)
図26：ヘッダーサンプル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 | 0 |1| 255 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 3010 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|8114 41D5 18AB 4A1B ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: Header Sample 4-8 (8th Packet)
図27：ヘッダーサンプル4-8（8番目のパケット）
Authors' Addresses
著者のアドレス
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/
Andrew Leung Sony Corporation
アンドリュー・レオン・ソニー・コーポレーション
EMail: andrew@ualberta.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への情報をお問い合わせください。