RFC5371 日本語訳
5371 RTP Payload Format for JPEG 2000 Video Streams. S. Futemma, E.Itakura, A. Leung. October 2008. (Format: TXT=62655 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Futemma
Request for Comments: 5371 E. Itakura
Category: Standards Track A. Leung
Sony
October 2008
Futemmaがコメントのために要求するワーキンググループS.をネットワークでつないでください: 5371年のE.板倉カテゴリ: 標準化過程A.レオンソニー2008年10月
RTP Payload Format for JPEG 2000 Video Streams
JPEG2000ビデオストリームのための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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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 Rec。 JPEG2000として、よりよく知られているT.800。 JPEG2000の特徴はこのペイロード形式のデザインで考えられます。 JPEG2000はアプリケーションが多くの異なった道を一度コード化して、解読する本当にスケーラブルな圧縮技術です。 2000年のJPEGビデオストリームは、ただ一つのイメージからJPEGのシリーズまで2000のイメージについて敷衍することによって、形成されます。
Futemma, et al. Standards Track [Page 1] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 コンベンションは本書では.6 2を使用しました。 JPEG2000ビデオは.6 3を特徴とします。 有効搭載量デザイン. . . . . . . . . . . . . . . . . . . . . . . . 6 4。 有効搭載量形式. . . . . . . . . . . . . . . . . . . . . . . . 7 4.1。 RTPは用法. . . . . . . . . . . . . . . . . . 7 4.2をヘッダーに固定しました。 RTP有効搭載量ヘッダー形式. . . . . . . . . . . . . . . . 8 5。 RTP Packetization. . . . . . . . . . . . . . . . . . . . . . 10 6。 メディアは登録. . . . . . . . . . . . . . . . . . . 11 7をタイプします。 SDPパラメタ. . . . . . . . . . . . . . . . . . . . . . . . 14 7.1。 SDPマッピング. . . . . . . . . . . . . . . . . . . . . . . 14 7.2。 SDP申し出/答えモデル. . . . . . . . . . 15 7.2.1がある用法。 例. . . . . . . . . . . . . . . . . . . . . . . 16 7.2の.2。 例: 90非kHzタイムスタンプ. . . . . . . . . . . . 16 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 17 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 10。 輻輳制御. . . . . . . . . . . . . . . . . . . . . . 18 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1。 引用規格. . . . . . . . . . . . . . . . . . . 19 11.2。 有益な参照. . . . . . . . . . . . . . . . . . 19の付録のA.の有益な付録. . . . . . . . . . . . . . . . 21A.1。 推奨案. . . . . . . . . . . . . . . . . . 21A.2。 詳細に.22にヘッダーを抽出してください。A.2.1。 サンプル1: Single Tile(3500Bytes(すなわち、小さい)の.22A.2.2)と進歩的なImage。 サンプル2: 4があるイメージは.24A.2.3にタイルを張ります。 サンプル3: 集合タイルを詰めて、有効搭載量を選抜してください、断片化しているヘッダー.25A.2.4。 サンプル4: インターレースイメージ、単一のタイル. . . . . . . . 27
Futemma, et al. Standards Track [Page 2] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[2ページ]。
1. Introduction
1. 序論
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].
このドキュメントはレアル-時間Transportプロトコル(RTP)の上のJPEG2000ビデオストリームにペイロード形式を指定します。 JPEG2000はISO/IEC国際規格とITU-T Recommendationです。(ISO/IEC国際規格15444-1| ITU-T Rec。 T.800) それでも、次世代、イメージ圧縮のために、開発されています。 JPEGはJoint Photographers Experts Group(画像圧縮規格を開発するためにアカデミーと産業で作られた国際的なグループ)を表します。 JPEG2000の基本的な圧縮技術はISO JPEG2000Part1で詳細に定義されます: 動きがISO JPEG2000Part3で定義されているコアCoding System[JPEG2000Pt_1]: MotionJPEG2000[JPEG2000Pt_3]。
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がMotionJPEG2000[JPEG2000Pt_3]を定義します。 しかしながら、MotionJPEG2000はネットワークのためにトランスミッション形式ではなく、ファイル形式を定義します。 このドキュメントは一連のJPEG2000イメージとしてトランスミッション形式をネットワークに指定します。
JPEG 2000 supports many powerful features [JPEG2000Pt_1] [JPEG2000Pt_3] that are not supported in the current JPEG standard, such as:
JPEG2000は現在の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 損失性と可逆圧縮の両方を提供する単一のcodestream。
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 画素精度による進歩的なトランスミッション(信号から雑音へのRatio(SNR)スケーラビリティ)と解決(解決スケーラビリティ)。
o Random codestream access and processing.
o 無作為のcodestreamアクセスと処理。
Futemma, et al. Standards Track [Page 3] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[3ページ]。
The JPEG 2000 algorithm is briefly explained. Figure 1 shows a block diagram of the JPEG 2000 encoding method.
JPEG2000アルゴリズムは簡潔に説明されます。 図1は、JPEG2000のブロック図が方法をコード化するのを示します。
+-----+
| ROI |
+-----+
|
V
+----------+ +----------+ +------------+
|DC, comp. | | Wavelet | | |
Raw Image ==> |transform-|==>|transform-|==>|Quantization|==+
| ation | | ation | | | |
+----------+ +----------+ +------------+ |
|
+-----------+ +----------+ +------------+ |
| | | | | | |
JPEG 2000 <==| Data |<==| Rate |<==| EBCOT |<=+
codestream | Ordering | | Control | | |
+-----------+ +----------+ +------------+
+-----+ | ROI| +-----+ | +に対して----------+ +----------+ +------------+ |DC、コンピュータ。 | | さざ波| | | 生のイメージ=>。|変形してください。|==>|変形してください。|==>|量子化|==+ | ation| | ation| | | | +----------+ +----------+ +------------+ | | +-----------+ +----------+ +------------+ | | | | | | | | JPEG2000<=| データ|<=| レート|<=| EBCOT|<=+ codestream| 注文します。| | コントロール| | | +-----------+ +----------+ +------------+
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コード化(TruncationのためにBlock Coding Optimizedを埋め込む)は、それぞれのコードブロックの中で実行されて、噛み付いている飛行機によって算術でコード化されます。 速度制御は、指定されたレートのための最も高い品質イメージを達成するために実行されます。
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.
最終的に、4本の軸に沿った進行に従って、JPEG2000パケットははさみ込まれます: 層、解決、コンポーネント、および管区。 JPEG2000ヘッダーは、完全に言いなりになっているJPEG2000codestreamになるように加えられます。
Futemma, et al. Standards Track [Page 4] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[4ページ]。
To decompress a JPEG 2000 codestream, one would follow the reverse order of the encoding order, without the rate control.
JPEG2000codestreamを減圧するために、1つは速度制御なしでコード化オーダーの逆順に続くでしょう。
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]について様々なJPEG2000関連するテキストを参照してください。
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は詳細にJPEG2000codestreamを示しています。 JPEG2000codestreamは主なヘッダーから構造化されます、SOC(Of Codestreamを始動する)マーカー、1個以上のタイル、およびEOC(終わりのOf Codestream)マーカーでcodestreamの端を示し始めて。 各タイルは、SOT(Tileの始まり)マーカーから始めるタイル部分ヘッダーから成って、SOD(Dataの始まり)マーカー、およびbitstream(一連の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
+-- +------------+ メイン| | SOC| 最初のマーカーヘッダーとして、必要です。| +------------+ | | メイン| 主なヘッダーマーカーセグメント+--+------------+ | | 飲んだくれ| それぞれのTileの始めに必要です。| +------------+ タイル部分のヘッダー一部| | T0、TP0| タイル0、タイル部分0ヘッダーマーカーヘッダー| +------------+ セグメント| | 芝生| 必要であることで、それぞれの終わりで+--+をタイルで分けてください。------------+ ヘッダー| bitstream| タイルパートbitstream+--+------------+ | | 飲んだくれ| タイル| +------------+ 部分| | T1、TP0| ヘッダー| +------------+ | | 芝生| +-- +------------+ | ビットストリーム| +------------+ . . . +------------+ | EOC| +における最後のマーカーとして、必要です。------------+ codestream
Figure 2: Basic construction of the JPEG 2000 codestream
図2: JPEG2000codestreamの基本的な構造
Futemma, et al. Standards Track [Page 5] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[5ページ]。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. JPEG 2000 Video Features
2. JPEG2000ビデオの特徴
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:
JPEG2000ビデオストリームは連続したシリーズに関するJPEG2000静止画像として形成されます。 JPEG2000の以前説明された特徴はJPEG2000ビデオにストリーミング・アプリケーションで有効に使用されるかもしれません。 JPEG2000ビデオストリームには、以下の品質があります:
o At low bit rates, the SNR is improved dramatically over JPEG and
Motion JPEG.
o 低ビット伝送速度では、SNRはJPEGとMotionJPEGの上で劇的に改良されます。
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 JPEG2000には、フレキシブルで正確な速度制御があります。
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 JPEG2000はこの仕様の外でcodestream回復でそれ自身のcodestream誤り弾力マーカーを援助に提供できます。
3. Payload Design
3. 有効搭載量デザイン
To design a payload format that maximizes JPEG 2000 features, the following are taken into consideration:
JPEG2000の特徴を最大にするペイロード形式を設計するために、以下は考慮に入れられます:
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%以上まで異なるかもしれません。 JPEG2000ビデオストリームをRTPパケットに分けるために、codestreamの効率的なpacketizationはなくなったパケットのため解読する際に問題を最小にしなければなりません。 主なヘッダーが迷子になるなら、イメージを解読できません。
o JPEG 2000 Scalability
o JPEG2000スケーラビリティ
JPEG 2000 has powerful scalability features and markers in the
payload header to indicate the specific meaning of the payload,
such as:
JPEG2000には、以下などのペイロードの特定の意味を示すために、強力なスケーラビリティ機能とマーカーがペイロードヘッダーにあります。
* Special markers for the headers, fragments of headers, etc.
* ヘッダーのための特別なマーカー、ヘッダーの断片など
Futemma, et al. Standards Track [Page 6] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[6ページ]。
* 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].
* パケットが方法を使用する優先権の重要性はRFC5372で[RFC5372]について説明しました。
* Main header recovery using methods described in RFC 5372
[RFC5372].
* 方法を使用する主なヘッダー回復がRFC5372で[RFC5372]について説明しました。
Additional usage of the payload header is described in RFC 5372
[RFC5372].
ペイロードヘッダーの追加使用法はRFC5372[RFC5372]で説明されます。
4. Payload Format
4. 有効搭載量形式
4.1. RTP Fixed Header Usage
4.1. ヘッダー用法が修理されたRTP
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はJPEG2000RTPペイロードヘッダーによって後をつけられています。(ペイロード(JPEG2000codestreamの1つの断片)はヘッダーを支えます)。通常、codestreamは2000年のJPEGパケットです。
The RTP header fields that have a meaning specific to a JPEG 2000 video stream are described as follows:
意味をJPEG2000ビデオストリームに特定にする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.).
有効搭載量タイプ(太平洋標準時の): ペイロードタイプはこのドキュメントの範囲の外の手段でダイナミックに選任されます。 ダイナミックレンジにおけるペイロードタイプはバンドで出ているシグナリングプロトコル(すなわち、レアルTime Streamingプロトコル(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パケットに現れなければなりません。 インターレース形式に2000年のJPEGイメージがあるとき、変な分野と対応する同等の分野には、同じタイムスタンプ値がなければなりません。 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
クロックレートに関して、送付者と受信機は、90kHzのRTPタイムスタンプレートを支持しなければならなくて、他のレートを支持するかもしれません。 RTPタイムスタンプレート、1000HzのSHOULD NOTの下では、RTPタイムスタンプに基づくRTP Controlプロトコル(RTCP)測定値のための不十分な解決をもたらすので、使用されてください、interarrivalなどのように
Futemma, et al. Standards Track [Page 7] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[7ページ]。
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.
ジター。 セッションの始めでクロックレートを交渉しなければなりません。 Session記述プロトコル(SDP)を使用するとき、"rtpmap"属性を使用して、それを言い表さなければなりません。 非90のkHzクロックレートが使用されていることであるなら、それは望ましいクロックレートだけではなく、異なったRTPペイロードタイプに従った90kHzのクロックレートも提示するRECOMMENDEDです。
4.2. RTP Payload Header Format
4.2. RTP有効搭載量ヘッダー形式
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_イド|T| 優先権| タイル番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |予約されます。| 断片オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: RTP payload header format for JPEG 2000
図3: JPEG2000のためのRTPペイロードヘッダー形式
tp (type): 2 bits
tp(タイプします): 2ビット
This field indicates how a JPEG 2000 image is scanned (progressive
or interlace).
この分野はJPEG2000イメージがどうスキャンされるかを(進歩的な人かインターレース)示します。
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パケットにあるかを示します。
Futemma, et al. Standards Track [Page 8] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[8ページ]。
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 |
+-----------+----------------------------------+
+-----------+----------------------------------+ | MHF値| 記述| +-----------+----------------------------------+ | 0 | ペイロードで主なヘッダーがありません。| | 1 | 断片化しているヘッダーの断片| | 2 | 断片化しているヘッダーの最後の一部| | 3 | 全体の主なヘッダー| +-----------+----------------------------------+
Table 1: MHF Usage Values
テーブル1: MHF用法値
mh_id (Main Header Identification): 3 bits
mh_イド(主なHeader Identification): 3ビット
Main header identification value. This is used for JPEG 2000 main
header recovery.
主なヘッダー識別価値。 これはJPEG2000の主なヘッダー回復に使用されます。
For implementations following only this specification, the sender
SHOULD set this value to 0 and the receiver SHOULD ignore this
field on processing.
この仕様だけに従う実現のために、送付者SHOULDはこの値を0に設定します、そして、受信機SHOULDは処理のこの分野を無視します。
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まで噛み付かれたTと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パケットが主なヘッダーだけを持っているとき。 送付者はタイルナンバーフィールドに少しの数もはめ込むことができません、JPEG2000タイルがないパートbitstreamが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.
ペイロードに2000年のパケットを含んでいて、優先権分野はJPEGの重要性を示します。 通常、より高い優先順位の値は下側のサブバンドを含むJPEG2000パケットを含むパケットに設定されます。
Futemma, et al. Standards Track [Page 9] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[9ページ]。
For implementations following only this specification, the sender
SHOULD set this value to 255 and the receiver SHOULD ignore this
field on processing.
この仕様だけに従う実現のために、送付者SHOULDはこの値を255に設定します、そして、受信機SHOULDは処理のこの分野を無視します。
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.
このビットは今後の使用のために予約されます。 Sendersは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).
この値は非常にそれぞれのJPEG2000codestream(JPEG2000フレーム)について始まりと関連した現在のペイロードのバイトオフセットへのセットでなければなりません。
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.
バイトオフセットはそれぞれのJPEG2000codestreamの始まりから現在のペイロードが完全なJPEG2000codestreamに収まる現在の位置まで計算されます。
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つのコネから始めないかもしれません。
5. RTP Packetization
5. RTP Packetization
The sender must packetize the JPEG 2000 appropriately according to initial media type parameters and/or details from SDP offer/answer parameters.
SDP申し出/答えパラメタから初期のメディア型引数、そして/または、詳細に従って、送付者は適切にJPEG2000をpacketizeしなければなりません。
A "packetization unit" is defined as either a JPEG 2000 main header, a tile-part header, or a JPEG 2000 packet.
「packetizationユニット」は2000年のJPEGの主なヘッダー、タイル部分ヘッダーか2000年のJPEGパケットのどちらかと定義されます。
Futemma, et al. Standards Track [Page 10] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[10ページ]。
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:
まず最初に、送付者は、codestreamを分析するか、またはエンコーダから情報を得ることによってJPEG2000codestreamをpacketizationユニットに分割して、RTPパケットにpacketizationユニットを埋めつくします。 送付者はpacketizationユニットの特殊活字の数字をRTPパケットに入れることができますが、それはcodestreamオーダーを保存しなければなりません。 この種類のRTPパケット・フォーマットに関する例は図4に示されます:
+------+-------+---------------+---------------+ |RTP |payload| packetization | packetization | |header|header | unit | unit | +------+-------+---------------+---------------+
+------+-------+---------------+---------------+ |RTP|ペイロード| packetization| packetization| |ヘッダー|ヘッダー| ユニット| ユニット| +------+-------+---------------+---------------+
Figure 4: An example with multiple packetization units
図4: 複数のpacketizationユニットがある例
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ヘッダー、およびペイロードヘッダー)があるpacketization単位がMTUサイズより大きいなら、それは断片化されるかもしれません。 断片化しているpacketizationユニットを梱包するために、同じRTPパケットの中で続くpacketizationユニットで断片化しているユニットを梱包してはいけません。 この種類の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 | |
+------+-------+------------------------------------+
+------+-------+-------------------------------------------------+ |RTP|ペイロード| packetizationユニットは断片化します。| |ヘッダー|ヘッダー| | +------+-------+-------------------------------------------------+ +------+-------+-------------------------------------------------+ |RTP|ペイロード| packetizationユニットは断片化します。| |ヘッダー|ヘッダー| | +------+-------+-------------------------------------------------+ . . . +------+-------+------------------------------------+ |RTP|ペイロード| packetizationユニット断片の端| |ヘッダー|ヘッダー| | +------+-------+------------------------------------+
Figure 5: An example with a fragmented packetization unit
図5: 断片化しているpacketizationユニットがある例
6. Media Type Registration
6. メディアは登録をタイプします。
This registration uses the template defined in [RFC4288] and follows [RFC4855].
この登録は、[RFC4288]で定義されたテンプレートを使用して、[RFC4855]に続きます。
Type name: video
型名: ビデオ
Futemma, et al. Standards Track [Page 11] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[11ページ]。
Subtype name: jpeg2000
Subtypeは以下を命名します。 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ですが、他のレートは指定されるかもしれません。 レート、1000HzのSHOULD NOTの下では、使用されてください。
sampling: A list of values specifying the color space of the
payload data.
抽出します: ペイロードデータの色のスペースを指定する値のリスト。
Acceptable values:
許容値:
RGB: standard Red, Green, Blue color space.
RGB: 標準のRed、グリーン、Blueはスペースを着色します。
BGR: standard Blue, Green, Red color space.
BGR: 標準のBlue、グリーン、Redはスペースを着色します。
RGBA: standard Red, Green, Blue, Alpha color space.
RGBA: 標準のRed、グリーン、Blue、アルファー色のスペース。
BGRA: standard Blue, Green, Red, Alpha color space.
BGRA: 標準のBlue、グリーン、Red、アルファー色のスペース。
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.
グレースケール: 基本的にまさしく灰色の「マルチ-レベル」のただ一つのコンポーネントイメージ。
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].
拡大値: 以下に登録されたカラーsamplingsの現在のリストに追加カラーsamplingsを登録できます。 標本抽出登録局を着色してください。 Uncompressed Video[RFC4175]についてRTP Formatを参照してください。
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
インターレース: スキャンを交錯させてください。 インターレース形式にペイロードがあるなら、許容値は「1インチ」です。 さもなければ、値は「0インチ」であるべきです。 それぞれの完全なイメージは垂直に表示の半分を形成します。 tp値は適切にイメージが表す分野を指定しなければなりません: 変な(tp=1)か(tp=2。)さえ このオプションがそうなら
Futemma, et al. Standards Track [Page 12] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[12ページ]。
not present, the payload MUST be in progressive format and the
tp MUST be set to 0.
進歩的な形式にはプレゼントでない、ペイロードがあるに違いありません、そして、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は、このメディアタイプが縁どられて2進であることを見ます。
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.
JPEG2000ビデオストリームはJPEG2000静止画像の系列です。 [JPEG2000Pt_1]による対応することの実現は、解読して、2000年のコード化されたJPEGビデオストリームを表示するのを試みることができます。
Published specification: ISO/IEC 15444-1 | ITU-T Rec. T.800
広められた仕様: ISO/IEC15444-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:
詳細のために連絡する人とEメールアドレス:
Eisaburo Itakura, Satoshi Futemma, Andrew Leung
Email: itakura@sm.sony.co.jp, satosi-f@sm.sony.co.jp,
andrew@ualberta.net
Eisaburo板倉、Satoshi Futemma、アンドリューレオンEmail: itakura@sm.sony.co.jp 、satosi-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]を通して定義されるだけです。 他の縁どりプロトコルの中の輸送は当時、定義されません。
Futemma, et al. Standards Track [Page 13] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[13ページ]。
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板倉、Satoshi Futemma、アンドリューレオン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.
IESGから代表として派遣されたIETF Audio/ビデオTransport作業部会。
7. SDP Parameters
7. SDPパラメタ
7.1. SDP Mapping
7.1. SDPマッピング
The media type video/jpeg2000 string is mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:
メディアタイプビデオ/jpeg2000ストリングは以下のSession記述プロトコル(SDP)[RFC4566]の分野に写像されます:
o The media name in the "m=" line of SDP MUST be video.
o メディアは「m=」で台詞を命名します。SDP MUSTでは、ビデオになってください。
o The encoding name in the "a=rtpmap" line of SDP MUST be jpeg2000
(the subtype).
o コード化はjpeg2000が(「副-タイプ」)であったなら"a=rtpmap"でSDP MUSTの台詞を命名します。
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"線におけるクロックレートは設定されます。 また、非90のkHzレートSHOULDを使用したがっている送付者が異なったRTPペイロードタイプに従った90kHzのタイムスタンプレートを使用することで同じ流れを提供します、優雅な後退を互換性のための90kHzまで許容して。
o The REQUIRED parameter, "sampling", MUST be included in the
"a=fmtp" line of SDP.
o SDPの"a=fmtp"線に「標本抽出である」REQUIREDパラメタを含まなければなりません。
o The OPTIONAL parameters, if presented, MUST be included in the
"a=fmtp" line of SDP.
o 提示されるなら、SDPの"a=fmtp"線にOPTIONALパラメタを含まなければなりません。
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
ビデオ49170/2RTP/AVP98m=a=rtpmap: 98jpeg2000/90000 a=fmtp: 98標本抽出=YCbCr-4: 2:0; 幅=128; 高さ=128
Futemma, et al. Standards Track [Page 14] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[14ページ]。
An example for using non-90kHz timestamp is as follows:
非90のkHzタイムスタンプを使用するための例は以下の通りです:
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
128ビデオ49170/2RTP/AVP98 99m=a=rtpmap: 98jpeg2000/27000000 a=rtpmap: 99jpeg2000/90000 a=fmtp: 98標本抽出=YCbCr-4: 2:0; 幅=128; 高さ=a=fmtp: 99標本抽出=YCbCr-4: 2:0; 幅=128; 高さ=128
7.2. Usage with the SDP Offer/Answer Model
7.2. SDP申し出/答えモデルがある用法
When offering JPEG 2000 over RTP using SDP in an Offer/Answer model [RFC3264], the following rules and limitations apply:
Offer/答えモデル[RFC3264]でSDPを使用することでJPEG2000をRTPの上に提供するとき、以下の規則と制限は適用されます:
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 受信機で受け入れるなら、「標本抽出」という歓迎すべき返答があるパラメタは申し出と答えに現れなければなりません。受信機SHOULDは、スペースが提供した色で容認されたcodestreamを扱うために最善をつくします。 受信機がいかなる理由でも提供された色のスペースを扱うことができないなら、それは、答えにおける都合のよい色のスペースで返答して、セッションを優雅に終わらせるべきです。 送付者は答えにおける色のスペースに従う必要はありませんが、彼らはセッションが色の標本抽出問題のため終わったというノートを取るべきです。
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 「インターレース」という任意のパラメタに関しては、このオプションが使用されているなら、申し出と受け入れるときのそれでSHOULDが答えに現れるように見えなければなりません。 受信機がインターレースか進歩的なcodestreamsを扱うために最善をつくすはずですが、受信機がある理由で収容できないなら、受信機は、都合のよい設定で答えで返答して、次に、セッションを優雅に終わらせるはずです。 送付者はこの答えでの設定を調整する必要はありませんが、それらはセッションがインターレースか進歩的な問題のため終わったというノートを取るべきです。
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
o 幅と高さは送付者が提供できる最大の寸法として申し出に現れるべきです。 答えでそれ、SHOULDは受信機が収容できる最大を表します。 aがあれば
Futemma, et al. Standards Track [Page 15] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[15ページ]。
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.
申し出と答え、送付者の違いは、新しい幅と高さを再提供して、受信機のためにcodestreamを適切に縮小させるべきです。
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]受信機は、送付者から申し出におけるパラメタに従うために最善をつくすはずです。 Sendersは、マルチキャスト環境でお勧めの設定を使用して、答えに注目するべきです。 幅と高さのために、送付者はそれがすべての答えから受ける値を最も低く収容するべきです。
o Any unknown options in the offer should be ignored and deleted
from the answer.
o 申し出におけるどんな未知のオプションも、答えから無視されて、削除されるべきです。
7.2.1. Examples
7.2.1. 例
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:
アリスは以下で720画素の幅と480画素の高さYCbCr4:2:2色のスペース、インターレースイメージを提供します:
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
ビデオ49170RTP/AVP98 0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.example s=c=IP4 host.example t=m=a=rtpmap: 98 jpeg2000/90000 a=fmtp: 98 標本抽出はYCbCr-4と等しいです: 2:2 =1を交錯させてください。 幅=720; 高さ=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
ビデオ49920RTP/AVP98 0 0INボブの2890844730 2890844731IN v=0o=IP4 host.example s=c=IP4 host.example t=m=a=rtpmap: 98 jpeg2000/90000 a=fmtp: 98 標本抽出はYCbCr-4と等しいです: 2:2 =1を交錯させてください。 幅=720; 高さ=480
7.2.2. Examples: Non-90kHz Timestamp
7.2.2. 例: 90非kHzタイムスタンプ
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ペイロードタイプを提供します、そして、それぞれのペイロードタイプ提供します。 YCbCr4:2:2はスペース、インターレースイメージ、720画素の幅、および480画素の高さを着色します。
Futemma, et al. Standards Track [Page 16] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[16ページ]。
She puts 27MHz clock rate attributes prior to 90kHz because she wants to use 27 MHz rather than 90kHz.
彼女は、90kHzよりむしろ27MHzを使用したがっているので、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
ビデオ49170RTP/AVP98 99 0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.example s=c=IP4 host.example t=m=a=rtpmap: 98 jpeg2000/27000000 a=rtpmap: 99 jpeg2000/90000 a=fmtp: 98 標本抽出はYCbCr-4と等しいです: 2:2 =1を交錯させてください。 幅=720; 480高さ=a=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
ビデオ49920RTP/AVP98 0 0INボブの2890844730 2890844731IN v=0o=IP4 host.example s=c=IP4 host.example t=m=a=rtpmap: 98 jpeg2000/27000000 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
ビデオ49920RTP/AVP99 0 0INボブの2890844730 2890844731IN v=0o=IP4 host.example s=c=IP4 host.example t=m=a=rtpmap: 99 jpeg2000/90000 a=fmtp: 99 標本抽出はYCbCr-4と等しいです: 2:2 =1を交錯させてください。 幅=720; 高さ=480
8. IANA Considerations
8. IANA問題
A new media subtype (video/jpeg2000) has been registered by IANA. For details, see Section 6 of this document.
ニューメディア「副-タイプ」(ビデオ/jpeg2000)はIANAによって登録されました。 詳細に関しては、このドキュメントのセクション6を見てください。
9. Security Considerations
9. セキュリティ問題
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
この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP仕様[RFC3550]、およびどんな適切なRTPプロフィールでも議論したセキュリティ問題を受けることがあります。 そしてRTPペイロード形式がこのメモの中で定義したRTPパケット携帯のための主なセキュリティ問題は秘密性です、保全。
Futemma, et al. Standards Track [Page 17] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[17ページ]。
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パケットの保全が適当な暗号の保全保護メカニズムの使用であります。 また、暗号のシステムはペイロードの源の認証を許すかもしれません。 この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]とTransport Layer Security(TLS)[RFC5246](TCPの上のRTP)であることにもかかわらずの、また、他の代替手段が存在するかもしれないということであるかもしれない他のメカニズム。
10. Congestion Control
10. 輻輳制御
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.
Service(QoS)高度サービスのQualityが使用されているなら、RTP受信機SHOULDは、要求されたサービスが実際に提供されているのを保証するためにパケット損失をモニターします。 それはそうでなく、次に、それらはSHOULDです。彼らが受信のベストエフォート型サービスであり、それに従って、振る舞うと仮定してください。
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である平均したスループットを実現するなら、パケット損失は許容できると考えられます。 通信速度(層の数は層にされたマルチキャストセッションのために申し込まれた)を適合させるために混雑制御機構を実行するか、または損失率が容認できないほど高いなら受信機がセッションを出発するように手配することによって、この状態を満たすことができます。
Futemma, et al. Standards Track [Page 18] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[18ページ]。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[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/IEC15444-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] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、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] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
and Registration Procedures", BCP 13, RFC 4288,
December 2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC4855] Casner、S.、「メディアはRTP有効搭載量形式の登録をタイプする」RFC4855、2007年2月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
11.2. Informative References
11.2. 有益な参照
[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/IEC15444-1| ITU-T Rec。 T.800、「情報技術(JPEG2000イメージ記号化体系)は3を分けます」。 2002年7月の「MotionJPEG2000。」
[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.、Futemma、S.、およびE.板倉、「有効搭載量はJPEGのために2000年のビデオをフォーマットします」。 「スケーラビリティと主なヘッダー回復のための拡大」、RFC5372、2008年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
Futemma, et al. Standards Track [Page 19] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[19ページ]。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5246] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2008年8月にバージョン1.2インチ、RFC5246について議定書の中で述べます」。
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, September 2005.
[RFC4175] GharaiとL.とC.パーキンス、「解凍されたビデオのためのRTP有効搭載量形式」、RFC4175、2005年9月。
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
Futemma, et al. Standards Track [Page 20] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[20ページ]。
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コーディング標準が非常にフレキシブルであるときに、多くの異なりましたが、対応することのデータ・ストリームが、生産されて、まだ言いなりになっているJPEG2000codestreamsであるかもしれません。
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.
↓これは展開しているJPEG2000の私たちの経験とこのペイロード仕様から詳しく説明された1セットの推薦です。 この規格の実現はこの仕様で言及されたすべての可能性を扱わなければなりません。 ↓これは実現が最適化するかもしれない項目のリストです。
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).
誤り弾力マーカー: JPEG2000データ・ストリームにおける誤り弾力マーカーの使用はすべての状況で非常にお勧めです。 これらのマーカーがあるエラー回復は、デコーダに役立って、外部のリソース(例えば、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色のスペースは人間の視覚体系に関して色における最大級の圧縮量を提供します。 JPEG2000と共に使用されると、この色のスペースは低ビット伝送速度で素晴らしい視覚結果を提供できます。
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.
進行注文: JPEG2000はプレゼンテーションによる転送を最適化するよう最終的なコードの流れに命令する多くの異なった方法を提供します。 私たちは、最も役に立つcodestream注文が層の進行と解決進行注文であることがわかりました。
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).
ティリンクとパケット: JPEG2000パケットはコード化方法にかかわらず形成されます。 それらが大きいか、または小さいかもしれないので、エンコーダには、これらのJPEG2000パケットのサイズのコントロールがほとんどありません。 ティリンクは、イメージをより小さい領域に分けて、別々にそれぞれコード化されます。 また、タイルで、JPEG2000パケットサイズは減少します。 葺くことを使用するとき、ほとんどすべての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.
送付者処理: 送付者がどうペイロードを梱包するべきであるかに関して制限が全くありません。 一般に、送付者は、ヘッダー回復を簡単にするように別々にcodestreamの残りからヘッダーを梱包するべきです。 有効搭載量は、一般に、Packet(SOP)マーカーのStartと共に始まって、より簡単なデコーダ処理のためのPacket Header(EPH)マーカーのEndと共に終わるべきです。
Futemma, et al. Standards Track [Page 21] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[21ページ]。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_イド|T| 優先権| タイル番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |予約されます。| 断片オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: JPEG 2000 Payload Header
図6: JPEG2000有効搭載量ヘッダー
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 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 002F000… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Header Sample 1-1 (First Packet)
図7: ヘッダーのサンプル1-1(最初のパケット)
Futemma, et al. Standards Track [Page 22] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[22ページ]。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0000 0000 2DB3 0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Header Sample 1-2 (Second Packet)
エイト環: ヘッダーのサンプル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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |841Eの4526 4556 9850C2EA… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パケット)
Futemma, et al. Standards Track [Page 23] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[23ページ]。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 002F000… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0000 0000 0578 0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0001 0000 058Fの0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header Sample 2-3 (Third Packet)
図13: ヘッダーのサンプル2-3(第3パケット)
Futemma, et al. Standards Track [Page 24] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[24ページ]。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0002 0000 054B0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0003 0000 050A0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 002F000… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Futemma, et al. Standards Track [Page 25] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[25ページ]。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 02BC0001FF93… | // // |FF90 000A 0001 0000 02BC0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Header Sample 3-3 (Third Packet)
図18: ヘッダーのサンプル3-3(第3パケット)
Futemma, et al. Standards Track [Page 26] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[26ページ]。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0002 0000 0573 0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 002F000… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0000 0000 0578 0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Header Sample 4-2 (Second Packet)
図21: ヘッダーのサンプル4-2(第2パケット)
Futemma, et al. Standards Track [Page 27] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[27ページ]。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |7F04E708 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番目のパケット: このパケットには、変なフィールドのタイルの3番目の一部が1300バイトあるでしょう。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 EC9B2826DC62 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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 002F000… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Header Sample 4-5 (5th Packet)
図24: ヘッダーのサンプル4-5(第5パケット)
Futemma, et al. Standards Track [Page 28] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[28ページ]。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 000A0000 0000 0578 0001FF93… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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バイトあるでしょう。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |626 C42F0 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番目のパケット: このパケットには、同等のフィールドのタイルの3番目の一部が1300バイトあるでしょう。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パケット)
Futemma, et al. Standards Track [Page 29] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[29ページ]。
Authors' Addresses
作者のアドレス
Satoshi Futemma Sony Corporation 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
Satoshi Futemmaソニー1-7-1Konan港区日本東京108-0075
Phone: +81 3 6748-2111 EMail: satosi-f@sm.sony.co.jp URI: http://www.sony.net/
以下に電話をしてください。 +81 3 6748-2111 メールしてください: satosi-f@sm.sony.co.jp ユリ: http://www.sony.net/
Eisaburo Itakura Sony Corporation 1-7-1 Konan Minato-ku Tokyo 108-0075 Japan
Eisaburo板倉ソニー1-7-1Konan港区日本東京108-0075
Phone: +81 3 6748-2111 EMail: itakura@sm.sony.co.jp URI: http://www.sony.net/
以下に電話をしてください。 +81 3 6748-2111 メールしてください: itakura@sm.sony.co.jp ユリ: http://www.sony.net/
Andrew Leung Sony Corporation
アンドリューレオンソニー
EMail: andrew@ualberta.net
メール: andrew@ualberta.net
Futemma, et al. Standards Track [Page 30] RFC 5371 JPEG 2000 RTP Payload Format October 2008
Futemma、他 規格はRTP有効搭載量形式2008年10月にRFC5371JPEG2000を追跡します[30ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Futemma, et al. Standards Track [Page 31]
Futemma、他 標準化過程[31ページ]
一覧
スポンサーリンク
