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
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国際規格15444-1のためのRTPペイロード形式について説明しますITU-T勧告。より良いJPEG 2000 JPEG 2000の機能として知られているT.800は、このペイロード形式の設計において考慮されています。 JPEG 2000は、アプリケーションが一度エンコードし、さまざまな方法をデコードすることができ、真にスケーラブルな圧縮技術です。 JPEG2000のビデオストリームは、JPEG2000画像の系列に単一の画像から延在して形成されます。
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国際標準とITU-T勧告である（ISO / IEC国際規格15444-1 |。ITU-T勧告T.800）次世代、静止画圧縮のために開発されました。 JPEGは共同カメラマン専門家グループ、画像圧縮規格を開発するために産学で作られた国際的なグループを表します。モーションJPEG 2000 [JPEG2000Pt_3]：CoreはISO JPEG 2000パート3で定義された運動で、[JPEG2000Pt_1]システムコーディング：JPEG 2000の基本的な圧縮技術は、ISO JPEG 2000パート1に詳細に定義されています。
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.
JPEG2000規格のパート3は、モーションJPEG 2000 [JPEG2000Pt_3]を定義します。しかし、モーション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.
特に極端な圧縮率ではあまり視覚的な歪みのJPEGよりもO高い圧縮効率。
o A single codestream that offers both lossy and lossless compression.
非可逆と可逆圧縮の両方を提供しています、単一のコードストリームO。
o Better error resiliency than JPEG.
JPEGよりもO優れたエラー復元力。
o Progressive transmission by pixel accuracy (Signal-to-Noise Ratio (SNR) scalability) and resolution (resolution scalability).
ピクセル精度（信号対雑音比（SNR）スケーラビリティ）と分解能（解像度スケーラビリティ）によってOプログレッシブ伝送。
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は、JPEG2000符号化方式のブロック図を示します。
+-----+
| 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のJPEG2000エンコーダのブロック図
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.
結果として、所与のタイルに対して、JPEG2000のパケットと呼ばれるデータユニットは、データの順序に応じて特定の層、特定のコンポーネント、特定の分解能、または特定のプレシンクトからデータを含有する、生成されます。
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.
レイヤ、解像度、コンポーネント、プレシンクト：最後に、JPEG2000のパケットは、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.
JPEG2000コードストリームを解凍するためには、レート制御せずに、符号化順序と逆の順序に従います。
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は、詳細にJPEG2000コードストリームを示しています。 JPEG2000コードストリームは、コードストリームの終わりを示すために、SOC（コードストリームの開始）マーカー、一枚の以上のタイル、およびEOC（コードストリームの終わり）マーカで始まる、メインヘッダから構成されています。各タイルは、SOT（タイルのスタート）マーカーで始まり、SOD（データの開始）マーカー、及びビットストリーム（JPEG2000のパケットのシリーズ）で終了するタイルパートヘッダから成ります。
+-- +------------+
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：JPEG2000コードストリームの基本構成
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とMotion JPEGで劇的に改善されています。
o This is a full intra-frame format -- each frame is independently compressed -- and therefore has a low encoding and decoding delay.
各フレームは独立して圧縮されている - - ○これは、完全なイントラフレームのフォーマットであるため、低符号化および復号化遅延を有します。
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％以上まで異なる場合があります。 RTPパケットにJPEG 2000ビデオストリームを分割するには、コードストリームの効率的なパケットが欠落により、パケットのデコードで問題を最小限に抑えるために必要とされます。メインヘッダが失われた場合、画像が復号できません。
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固定ヘッダは、ペイロードが続くJPEG2000のRTPペイロードヘッダ、続いて、通常のJPEG2000パケットであるJPEG2000コードストリームの部分。
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パケットに現れなければなりません。 JPEG2000の画像がインターレース形式である場合、奇数フィールドと対応する偶数フィールドは、同じタイムスタンプ値を持たなければなりません。 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タイムスタンプに基づいて、RTP制御プロトコル（RTCP）測定のために不十分な解像度をもたらすため1000Hzの下のRTPタイムスタンプレートを使用しないでください。クロック・レートは、セッションの開始時に交渉しなければなりません。セッション記述プロトコル（SDP）を使用する場合、それは「rtpmap」属性を使用して表現されなければなりません。非た90KHzクロックレートが使用される場合、好ましいクロックレートも、異なるRTPペイロードタイプた90KHzクロック速度だけでなく提示することが推奨されます。
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 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：ペイロードは、インターレース・ビデオ・フレームの奇数フィールドの一部です。 JPEG2000のメインヘッダで指定された高さが全体表示される画像の高さの半分です。受信機において、奇数フィールドは、各画像から線が交互に表示されるように、それに続く偶数フィールドでデインタレースされるべきです。
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ビットは、タイル番号フィールドが有効か無効かを示します。送信者は1時に無効と0有効にTビットを設定しなければなりません。
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パケットの重要性を示しています。典型的には、より高い優先度の値が低いサブバンドを含むJPEG2000のパケットを含むパケットに設定されています。
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).
この値は、各JPEG2000コードストリームの冒頭に関連して、現在のペイロードのバイトオフセット（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.
バイト・オフセットは、現在のペイロードが完全なJPEG2000コードストリームの中に収まるように現在の位置に各JPEG2000コードストリームアップの開始から計算されます。
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セッションを使用して層状のビデオを配信することが可能です。フラグメントオフセットは、パケットが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.
「パケット化部」とは、JPEG2000のメインヘッダ、タイルパートヘッダ、またはJPEG2000のパケットのいずれかとして定義されます。
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:
まず、送信者は、コードストリームを解析することにより、またはエンコーダからの情報を取得することにより、パケット単位にJPEG2000コードストリームを分割し、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 = 1）または（TP = 2）：TP値が正しく画像が表すフィールドを指定しなければなりません。このオプションが存在しない場合、ペイロードがプログレッシブ形式でなければなりませんし、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.
幅：ビデオストリームの最大幅を記述するパラメータ。高さが存在する場合、このパラメータは表示されなければなりません。許容可能な値： - 4,294,967,295 - 0の整数値。
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.
高さ：ビデオストリームの最大高さを記述するパラメータ。幅が存在する場合、このパラメータは表示されなければなりません。許容可能な値： - 4,294,967,295 - 0の整数値。
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勧告。 T.800
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
video streaming and communication
ビデオストリーミングと通信
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Eisaburo Itakura, Satoshi Futemma, Andrew Leung Email: itakura@sm.sony.co.jp, satosi-f@sm.sony.co.jp, andrew@ualberta.net
えいさぶろ いたくら、 さとし ふてっま、 あんｄれｗ ぇうんｇ えまいｌ： いたくら＠ｓｍ。そｎｙ。こ。ｊｐ、 さとしーｆ＠ｓｍ。そｎｙ。こ。ｊｐ、 あんｄれｗ＠うあｌべｒた。ねｔ
Intended usage: COMMON
意図している用法：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
えいさぶろ いたくら、 さとし ふてっま、 あんｄれｗ ぇうんｇ えまいｌ： いたくら＠ｓｍ。そｎｙ。こ。ｊｐ、 さとしーｆ＠ｓｍ。そｎｙ。こ。ｊｐ、 あんｄれｗ＠うあｌべｒた。ねｔ
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「M =」SDPのラインがビデオでなければなりません。
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のレートを使用する送信者はまた、互換性のためにた90KHzに優雅なフォールバックを可能にする、異なるRTPペイロードタイプた90KHzタイムスタンプレートを使用して同じストリームを提供するべきです。
o The REQUIRED parameter, "sampling", MUST be included in the "a=fmtp" line of SDP.
O REQUIREDパラメータ、「サンプリング」は、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
M =ビデオ2分の49170 RTP / AVP 98 = rtpmap：98 JPEG2000 / 90000 =のfmtp：98サンプリング=たYCbCr-4：2：0;幅= 128;高さ= 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
M =ビデオ2分の49170 RTP / AVP 98 99 = rtpmap：98 JPEG2000 /2700万A = rtpmap：99 JPEG2000 / 90000 =のfmtp：98サンプリング=たYCbCr-4：2：0;幅= 128;高さ= 128 =のfmtp：99サンプリング=たYCbCr-4：2：0;幅= 128;高さ= 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:
2：以下のように2色空間、720ピクセル幅480ピクセル高さインターレース画像アリスはYCbCr表4を提供します。
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
/ 90000 98 JPEG2000 =のfmtp：98サンプリング= YCbCrのIP4 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49170は、RTP / AVP 98 = rtpmap IN V = 0 0 =アリス2890844526 2890844526 -4：2：2。インターレース= 1。幅= 720;高さ= 480
Bob accepts YCbCr-4:2:2 color space, interlace image 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 sampling=YCbCr-4:2:2; interlace=1; width=720;height=480
/ 90000 98 JPEG2000 =のfmtp：98サンプリング= YCbCrのIP4 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49920は、RTP / AVP 98 = rtpmap IN V = 0 0 =ボブ2890844730 2890844731 -4：2：2。インターレース= 1。幅= 720;高さ= 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.
彼女は27 MHzのではなくた90KHzを使用したいので、27MHzのクロック・レートがた90KHzの前に属性を置きます。
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
V = 0 0 =アリス2890844526 2890844526 IN IP4 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49170 RTP / AVP 98 99 = rtpmap：98 JPEG2000 /2700万A = rtpmap：99 JPEG2000 / 90000 =のfmtp：98サンプリング=たYCbCr-4：2：2。インターレース= 1。幅= 720;高さ= 480 =のfmtp：99サンプリング=たYCbCr-4：2：2。インターレース= 1。幅= 720;高さ= 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
V = 0 0 =ボブ2890844730 2890844731 IN IP4 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49920 RTP / AVP 98 = rtpmap：98 JPEG2000 /2700万A =のfmtp：98サンプリング= YCbCr表-4：2：2。インターレース= 1。幅= 720;高さ= 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
/ 90000 99 JPEG2000 =のfmtp：99サンプリング= YCbCrのIP4 host.example S = C = IN IP4 host.example T = 0、M =ビデオ49920は、RTP / AVP 99 = rtpmap IN V = 0 0 =ボブ2890844730 2890844731 -4：2：2。インターレース= 1。幅= 720;高さ= 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.
ベストエフォート型のサービスが使用されている場合は、このペイロード形式のユーザーは、パケット損失率が許容パラメータの範囲内であることを保証するために、パケット損失を監視する必要があります。パケット損失は、同じネットワーク・パスを横切るTCPフローあれば許容されると考えられる、同一のネットワーク条件を経験し、RTPの流れ以上である合理的なタイムスケールで測定した平均スループットが、達成され得るであろう。この条件は、伝送速度（又は層状マルチキャストセッションのために加入層数）を適合させるために、輻輳制御メカニズムを実装することで、または損失率が許容できないほど高い場合にセッションを終了するための受信機のために配置することによって満たすことができます。
[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月。
[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月。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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.、マグリュー、D.、Naslund、M.、カララ、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]解放され、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.、RFC 4855、2007年2月 "RTPペイロード形式のメディアタイプ登録"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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勧告。 T.800、 "情報技術 - システムをコーディングJPEG 2000イメージ - 第3部：モーション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]レオン、A.、普天間、S.、およびE.板倉、 "JPEG 2000ビデオのためのペイロードフォーマット：拡張性とメインヘッダ回復のための拡張機能"、RFC 5372、2008年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン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.パーキンス、 "非圧縮ビデオのためのRTPペイロードフォーマット"、RFC 4175、2005年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
Appendix A. Informative Appendix
付録A.有益な付録
A.1. Recommended Practices
A.1。推奨プラクティス
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.
JPEG2000の符号化規格は非常に柔軟であるように、多くの異なるが準拠データストリームが生成され、依然として準拠JPEG2000のコードストリームであってもよいです。
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データ・ストリームにおけるエラー耐性マーカーの使用は非常にすべての状況で推奨されます。これらのマーカーとエラー回復は、デコーダに有用であり、外部リソースを節約する（例えば、RESET、RESTART、および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パケットサイズも低減されています。タイリングを使用する場合、ほぼすべてのJPEG2000パケットサイズは、送信のために許容されるサイズである（すなわち、ほとんどのネットワークの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.
送信者処理：制限は、送信者がペイロードを詰めるべきかに関して、ありません。一般的には、送信者は、ヘッダ回復を簡単にするために、コードストリームの残りの部分とは別にヘッダを詰める必要があります。ペイロードは、一般に容易に復号処理のためのパケットヘッダ（EPH）マーカーの端部とパケットの開始（SOP）マーカーおよび端で始まるべきです。
A.2. Sample Headers in Detail
A.2。詳細のサンプルヘッダ
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ペイロードヘッダー
A.2.1. Sample 1: Progressive Image with Single Tile, 3500 Bytes (i.e., thumbnail)
A.2.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 | 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パケット）
A.2.2. Sample 2: Image with 4 Tiles
A.2.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 | 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のパケットは、このパケットは、第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 | 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のパケット：このパケットは二タイルパート（タイル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番目のパケット：このパケットは、第三タイルパート（タイル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
第五パケット：このパケットは第四タイルパート（タイル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パケット）
A.2.3. Sample 3: Packing Multiple Tiles in Single Payload, Fragmented Header
A.2.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| 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バイトの第二の部分を有しています
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のパケット：このパケットは、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| 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パケット）
A.2.4. Sample 4: Interlace Image, Single Tile
A.2.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バイトの第二の部分を持っています
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
第五パケット：このパケットは偶数フィールドのために全体のメインヘッダ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
第六パケット：このパケットは偶数フィールドのタイル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
第七パケット：このパケットは偶数フィールドのタイル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 | 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
第八パケット：このパケットは偶数フィールドのタイル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
さとし ふてっま そｎｙ こｒぽらちおん １ー７ー１ こなん みなとーく ときょ １０８ー００７５ じゃぱん
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/
Andrew Leung Sony Corporation
アンドリュー・レオンソニー株式会社
EMail: andrew@ualberta.net
メールアドレス：andrew@ualberta.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に情報を記述してください。