RFC2190 日本語訳
2190 RTP Payload Format for H.263 Video Streams. C. Zhu. September 1997. (Format: TXT=26409 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Zhu Request for Comments: 2190 Intel Corp. Category: Standards Track September 1997
コメントを求めるワーキンググループC.朱の要求をネットワークでつないでください: 2190年のインテル社カテゴリ: 標準化過程1997年9月
RTP Payload Format for H.263 Video Streams
H.263ビデオストリームのための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 document specifies the payload format for encapsulating an H.263 bitstream in the Real-Time Transport Protocol (RTP). Three modes are defined for the H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired network packet size and H.263 encoding options employed. The shortest H.263 payload header (mode A) supports fragmentation at Group of Block (GOB) boundaries. The long H.263 payload headers (mode B and C) support fragmentation at Macroblock (MB) boundaries.
このドキュメントはレアル-時間Transportプロトコル(RTP)でH.263 bitstreamを要約するのにペイロード形式を指定します。 3つのモードがH.263ペイロードヘッダーのために定義されます。 RTPパケットは必要なネットワークパケットサイズと使われたオプションをコード化するH.263に依存するH.263ビデオストリームに3つのモードの1つを使用できます。 最も脆いH.263ペイロードヘッダー(モードA)はBlock(GOB)境界のGroupで断片化を支持します。 長いH.263ペイロードヘッダー(モードBとC)はMacroblock(MB)境界で断片化を支持します。
1. Introduction
1. 序論
This document describes a scheme to packetize an H.263 video stream for transport using RTP [1]. H.263 video stream is defined by ITU-T Recommendation H.263 (referred to as H.263 in this document) [4] for video coding at very low data rates. RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services.
このドキュメントは、RTP[1]を使用することで輸送のためのH.263ビデオストリームをpacketizeするように計画について説明します。 H.263ビデオストリームはビデオ符号化のためにITU-T Recommendation H.263(本書ではH.263と呼ばれる)[4]によって非常に低いデータ信号速度で定義されます。 RTPは、終わりから終わりへのネットワーク輸送マルチキャストの上にリアルタイムデータを伝えるアプリケーションかユニキャストネットワーク・サービスに適した機能を提供するためにインターネット・エンジニアリング・タスク・フォース(IETF)によって定義されます。
2. Definitions
2. 定義
The following definitions apply in this document:
以下の定義は本書では適用されます:
CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x 288 pixels for luminance, and 176 x 144 pixels for chrominance.
CIF: 共通中間フォーマット。 H.263に関しては、CIFの絵には、輝度、および176x144画素352x288画素が色差のためにあります。
QCIF: Quarter CIF source format with 176 x 144 pixels for luminance and 88 x 72 pixels for chrominance.
QCIF: 色差のための輝度と88x72画素176x144画素がある4分の1CIFソース形式。
Sub-QCIF: picture source format with 128 x 96 pixels for luminance and 64 x 48 pixels for chrominance.
サブQCIF: 色差のために128x96画素でソース書式を輝度と64x48画素描写してください。
Zhu Standards Track [Page 1] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[1ページ]。
4CIF: Picture source format with 704 x 576 pixels for luminance and 352 x 288 pixels for chrominance.
4CIF: 色差のために704x576画素でソース書式を輝度と352x288画素描写してください。
16CIF: Picture source format with 1408 x 1152 pixels for luminance and 704 x 576 pixels for chrominance.
16CIF: 色差のために1408x1152画素でソース書式を輝度と704x576画素描写してください。
GOB: For H.263, a Group of Blocks (GOB) consists of k*16 lines, where k depends on the picture format (k=1 for QCIF, CIF and sub- QCIF; k=2 for 4CIF and k=4 for 16CIF).
かたまり: H.263に関しては、Blocks(GOB)のGroupはk*16の線から成ります。そこでは、kが絵の形式(QCIF、CIF、およびサブQCIFのためのk=1; 4CIFのためのk=2と16CIFのためのk=4)に依存します。
MB: A macroblock (MB) contains four blocks of luminance and the spatially corresponding two blocks of chrominance. Each block consists of 8x8 pixels. For example, there are eleven MBs in a GOB in QCIF format and twenty two MBs in a GOB in CIF format.
MB: macroblock(MB)は4ブロックの輝度と空間的に対応する2つのブロックの色差を含んでいます。 各ブロックは8×8画素から成ります。 例えば、GOBのQCIF形式と22MBには11MBがGOBにCIF形式にあります。
3. Design Issues for Packetizing H.263 Bitstreams
3. Packetizing H.263 Bitstreamsのためのデザイン問題
H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as H.261 in this document). Compared to H.261, H.263 employs similar techniques to reduce both temporal and spatial redundancy, but there are several major differences between the two algorithms that affect the design of packetization schemes significantly. This section summarizes those differences.
H.263はITU-T Recommendation H.261[2](本書ではH.261と呼ばれます)に基づいています。 H.261と比べて、H.263は時のものと同様に空間的な冗長を減らすのに同様のテクニックを使いますが、packetization計画のデザインにかなり影響する2つのアルゴリズムの間には、いくつかの主要な違いがあります。 このセクションはそれらの違いをまとめます。
3.1 Optional Features of H.263
3.1 H.263の任意の特徴
In addition to the basic source coding algorithms, H.263 supports four negotiable coding options to improve performance: Advanced Prediction, PB-frames, Syntax-based Arithmetic Coding, and Unrestricted Motion Vectors. They can be used in any combination.
基本的なソースコーディングアルゴリズムに加えて、H.263は性能を向上させるために4つの交渉可能なコード化オプションをサポートします: 高度な予測、Pbフレーム、構文ベースの算数のコード化、および無制限な運動ベクトル。 どんな組み合わせにもそれらを使用できます。
Advanced Prediction(AP): One or four motion vectors can be used for some macroblocks in a frame. This feature makes recovery from packet loss difficult, because more redundant information has to be preserved at the beginning of a packet when fragmenting at a macroblock boundary.
高度な予測(AP): フレームのいくらかのmacroblocksに1か4つの運動ベクトルを使用できます。 この特徴でパケット損失からの回復は難しくなります、パケットの始めにmacroblock境界で断片化するとき、より余分な情報が保存されなければならないので。
PB-frames: Two frames (a P frame and a B frame) are coded into one bitstream with macroblocks from the two frames interleaved. From a packetization point of view, a MB from the P frame and a MB from the B frame must be treated together because each MB for the B frame is coded based on the corresponding MB for the P frame. A means must be provided to ensure proper rendering of two frames in the right order. Also, if part of this combined bitstream is lost, it will affect both frames, and possibly more.
Pbフレーム: macroblocksが2個のフレームからはさみ込まれている状態で、2個のフレーム(PフレームとBフレーム)が1bitstreamにコード化されます。 packetization観点から、Bフレームへの各MBがPフレームへの対応するMBに基づいてコード化されるので、Pフレームから1MBとBフレームから1MBを一緒に扱わなければなりません。 正しい注文における、2個のフレームの適切な表現を確実にするために手段を提供しなければなりません。 また、この結合したbitstreamの部分が無くなると、それは両方のフレームにことによるとさらに影響するでしょう。
Zhu Standards Track [Page 2] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[2ページ]。
Syntax-based Arithmetic Coding (SAC): When the SAC option is used, the resultant run-value pair after quantization of Discrete Cosine Transform (DCT) coefficients will be coded differently from Huffman codes, but the macroblock hierarchy will be preserved. Since context variables are only synchronized after fixed length codes in the bitstream, any fragmentation starting at variable length codes will result in difficulty in decoding in the presence of packet loss without carrying the values of all the context variables in each H.263 payload header.
(嚢)をコード化する構文ベースの演算: SACオプションが使用されているとき、Discrete Cosine Transform(DCT)係数の量子化の後の結果の走行価値の組はハフマン符号と異なってコード化されるでしょうが、macroblock階層構造は保存されるでしょう。 bitstreamの長さのコードが修理された後に文脈変数が同期するだけであるので、可変長コードで始まるどんな断片化もそれぞれのH.263ペイロードヘッダーのすべての文脈変数の値を運ぶことのないパケット損失の面前で解読することにおける苦労をもたらすでしょう。
The Unrestricted motion vectors feature allows large range of motion vectors to improve performance of motion compensation for inter-coded pictures. This option also affects packetization because it uses larger range of motion vectors than normal.
Unrestricted運動ベクトル機能で、広い範囲の運動ベクトルは相互コード化された絵のための動き補償の性能を向上させることができます。 また、標準より大きい動作範囲ベクトルを使用するので、このオプションはpacketizationに影響します。
To enable proper decoding of packets received, without dependency on previous packets, the use of these optional features is signaled in the H.263 payload header, as described in Section 5.
前のパケットにおける依存なしで受け取られたパケットの適切な解読を可能にするために、これらのオプション機能の使用はH.263ペイロードヘッダーで合図されます、セクション5で説明されるように。
3.2 GOB Numbering
3.2 かたまりの付番
In H.263, each picture is divided into groups of blocks (GOB). GOBs are numbered according to a vertical scan of a picture, starting with the top GOB and ending with the bottom GOB. In contrast, a GOB in H.261 is composed of three rows of 16x16 MB for QCIF, and three half-rows of MBs for CIF. A GOB is divided into macroblocks in H.263 and the definition of the macroblocks are the same as in H.261.
H.263では、各絵はブロック(GOB)のグループに分割されます。 絵の垂直なスキャンに従って、GOBsは付番されます、下部GOBと共に最高GOBと結末から始まって。 対照的に、H.261のGOBはCIFのために3つの列のQCIFのための16×16MB、および3つの半分列のMBで構成されます。 GOBはH.263でmacroblocksに分割されます、そして、macroblocksの定義はH.261と同じです。
Each GOB in H.263 can have a fixed GOB header, but the use of the header is optional. If the GOB header is present, it may or may not start on a byte boundary. Byte alignment can be achieved by proper bit stuffing by the encoder, but it is not required by the H.263 bitstream specification [4].
H.263の各GOBは固定GOBヘッダーを持つことができますが、ヘッダーの使用は任意です。 GOBヘッダーが出席しているなら、それはバイト境界を始めるかもしれません。 エンコーダによる適切なビット・スタッフィングでバイト整列を達成できますが、それはH.263 bitstream仕様[4]によって必要とされません。
In summary, a GOB in H.263 is defined and coded with finer granularity but with the same source format, resulting in more flexibility for packetization than with H.261.
概要では、H.263のGOBは、よりすばらしい粒状にもかかわらず、同じソース形式で定義されて、コード化されます、H.261よりpacketizationにおける多くの柔軟性をもたらして。
3.3 Motion Vector Encoding
3.3 動きベクトル符号化
Differential coding is used to code motion vectors as variable length codes. Unlike in H.261, where each motion vector is predicted from the previous MB in the GOB, H.263 employs a more flexible prediction scheme, where one or three candidate predictors could be used depending on the presence of GOB headers.
差分符号化は、可変長コードとして運動ベクトルをコード化するのに使用されます。 H.261などと異なって、H.263は、よりフレキシブルな予測計画を使います、GOBヘッダーの存在によって、1か3人の候補予言者を使用できたところで。そこでは、各運動ベクトルがGOBで前のMBから予測されます。
Zhu Standards Track [Page 3] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[3ページ]。
If the GOB header is present in a GOB, motion vectors are coded with reference to MBs in the current GOB only. If a GOB header is not present in the current GOB, three motion vectors must be available to decode one macroblock, where two of them might come from the previous GOB. To correctly decode a whole inter-coded GOB, all the motion vectors for MBs in the previous GOB must be available to compute the predictors or the predictors themselves must be present. The optional use of three motion vector predictors can be a major problem for a packetization scheme like the one defined for H.261 when packetizing at MB boundaries [5].
GOBヘッダーがGOBに出席しているなら、運動ベクトルは現在のGOBだけのMBに関してコード化されます。 GOBヘッダーが現在のGOBに出席していないなら、3つの運動ベクトルが、1macroblockを解読するために有効でなければなりません。(そこでは、それら2人が前のGOBから来るかもしれません)。 正しく全体を解読するのが相互GOBをコード化したか、前のGOBのMBすべての運動ベクトルが予言者を計算するために有効でなければなりませんか、または予言者自身は出席しているに違いありません。 3人の運動ベクトル予言者の任意の使用はMB境界[5]でpacketizingするときH.261のために定義されたもののようなpacketization計画のための大した問題であるかもしれません。
Consider the case that a packet starts with a MB but the GOB header is not present. If the previous packet is lost, then all the motion vectors needed to predict the motion vectors for the MBs in the current GOB are not available. In order to decode the received MBs correctly, all the motion vectors for the previous GOB or the motion vector predictors would have to be duplicated at the beginning of the packet. This kind of duplication would be very expensive and unacceptable in terms of bandwidth overhead.
パケットが1MB始まるケースにもかかわらず、GOBヘッダーが出席していないと考えてください。 前のパケットが無くなるなら、すべての運動ベクトルが、現在のGOBのMB単位で運動ベクトルが有効でないと予測する必要がありました。 正しく容認されたMBを解読するために、前のGOBのためのすべての運動ベクトルか運動ベクトル予言者がパケットの始めにコピーされなければならないでしょう。 この種類の複製は、帯域幅オーバーヘッドにおいて非常に高価であって、容認できないでしょう。
The encoding strategy of each H.263 CODEC (CODer and DECoder) implementation is beyond the scope of this document, even though it has significant effect on visual quality in the presence of packet loss. However, we strongly recommend use of the GOB header for every GOB at the beginning of a packet to address this problem.
それぞれのH.263 CODEC(CODerとDECoder)実現のコード化戦略はこのドキュメントの範囲を超えています、パケット損失の面前で視覚品質に重要な影響を与えますが。 しかしながら、私たちは、GOBヘッダーのパケットの始めのあらゆるGOBの使用がこのその問題を訴えることを強く勧めます。
Similar problems exist because of cross-GOB data dependency related to motion vectors, but they can not be addressed by using the GOB header. For 16CIF and 4CIF pictures, a GOB contains more than one row of MBs. If a GOB can not fit in one RTP packet, and the first packet containing the GOB header is lost, then MBs in the second packet can not compute motion vectors correctly, because they are coded relative to data in the lost packet. Similarly, when OBMC (Overlapped Block Motion Compensation) [4] in Advanced Prediction mode is used, motion compensation for some MBs in one GOB could use motion vectors of MBs in previous GOB regardless of the presence of GOB header. When MBs that are used to decode received MBs are lost, those received MBs can not be decoded correctly. Each implementation of the method described in this document should take these limitations into account.
同様の問題は運動ベクトルに関連する十字-GOBデータ依存のために存在していますが、GOBヘッダーを使用することによって、それらを記述できません。 16CIFと4CIFの絵のために、GOBは1つ以上の列のMBを含んでいます。 GOBが1つのRTPパケットをうまくはめ込むことができないで、GOBヘッダーを含む最初のパケットが無くなるなら、2番目のパケットのMBは正しく運動ベクトルを計算できません、それらが無くなっているパケットのデータに比例してコード化されるので。 Advanced PredictionモードによるOBMC(Block Motion Compensationを重ね合わせる)[4]が使用されているとき、同様に、1GOBの何らかのMBのための動き補償はGOBヘッダーの存在にかかわらず前のGOBのMBの運動ベクトルを使用するかもしれません。 使用されたMBであるときに、失われた、容認されたMB、受け取られたものを解読するために、正しくMBを解読できません。 本書では説明された方法の各実現はこれらの制限を考慮に入れるべきです。
Zhu Standards Track [Page 4] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[4ページ]。
3.4 Macroblock Address
3.4 Macroblockアドレス
As specified by H.261, a macroblock address (MBA) is encoded with a variable length code to indicate the position of a macroblock within a group of MBs in H.261 bitstreams. H.263 does not code the MBA explicitly, but the macroblock address within a GOB is necessary to recover from packet loss when fragmenting at MB boundaries. Therefore, this information must be included in the H.263 payload header for modes (mode B and mode C as described in Section 5) that allow packetization at MB boundaries.
H.261によって指定されるように、macroblockアドレス(MBA)は可変長コードでコード化されます。H.261 bitstreamsでMBのグループの中にmacroblockの位置を示す、H.263は明らかにMBAをコード化しませんが、GOBの中のmacroblockアドレスが、MB境界で断片化するとき、パケット損失から回復するのに必要です。 したがって、MB境界にpacketizationを許容するモード(セクション5で説明されるモードBとモードC)のためのH.263ペイロードヘッダーにこの情報を含まなければなりません。
4. Usage of RTP
4. RTPの使用法
When transmitting H.263 video streams over the Internet, the output of the encoder can be packetized directly. For every video frame, the H.263 bitstream itself is carried in the RTP payload without alteration, including the picture start code, the entire picture header, in addition to any fixed length codes and variable length codes. In addition, the output of the encoder is packetized without adding the framing information specified by H.223 [6]. Therefore multiplexing audio and video signals in the same packet is not accommodated, as UDP and RTP provide a much more efficient way to achieve multiplexing.
H.263ビデオストリームをインターネットの上に伝えるとき、直接エンコーダの出力をpacketizedされることができます。 あらゆるビデオフレームに関しては、H.263 bitstream自身はRTPペイロードで変更なしで運ばれます、絵のスタートコードを含んでいて、全体像ヘッダー、どんな固定長コードと可変長コードに加えて。 さらに、縁どり情報がH.223[6]で指定したと言い足さない、エンコーダの出力はpacketizedされます。 したがって、同じパケットでオーディオとビデオ信号を多重送信するのは設備されません、UDPとRTPがマルチプレクシングを達成するはるかに効率的な方法を提供するとき。
RTP does not guarantee a reliable and orderly data delivery service, so a packet might get lost in the network. To achieve a best-effort recovery from packet loss, the decoder needs assistance to proceed with decoding of other packets that are received. Thus it is desirable to be able to process each packet independent of other packets. Some frame level information is included in each packet, such as source format and flags for optional features to assist the decoder in operating correctly and efficiently in presence of packet loss. The flags for H.263 optional features also provide information about coding options used in H.263 video bitstreams that can be used by session management tools.
RTPが信頼できて規則的なデータデリバリ・サービスを保証しないので、パケットはネットワークで失せるかもしれません。 パケット損失からのベストエフォート型回復を達成するなら、デコーダは、他の受け取られていているパケットの解読を続けるために支援を必要とします。 したがって、他のパケットの如何にかかわらず各パケットを処理できるのは望ましいです。 何らかのフレーム・レベル情報が各パケットに含まれています、パケット損失の存在で正しく効率的に作動にデコーダを助けるオプション機能のためのソース形式や旗のように。 また、H.263オプション機能のための旗はセッション管理ツールで使用できるH.263ビデオbitstreamsで使用されるコード化オプションの情報を提供します。
H.263 video bitstreams will be carried as payload data within RTP packets. A new H.263 payload header is defined in section 5 on the H.263 payload header. This section defines the usage of RTP fixed header and H.263 video packet structure.
H.263ビデオbitstreamsはペイロードデータとしてRTPパケットの中で運ばれるでしょう。 新しいH.263ペイロードヘッダーはH.263ペイロードヘッダーの上のセクション5で定義されます。 このセクションはヘッダーに固定されたRTPとH.263ビデオパケット構造の使用法を定義します。
4.1 RTP Header Usage
4.1 RTPヘッダー用法
Each RTP packet starts with a fixed RTP header [1]. The following fields of the RTP fixed header are used for H.263 video streams:
それぞれのRTPパケットは固定RTPヘッダー[1]から始めます。 ヘッダーに固定されたRTPの以下の分野はH.263ビデオストリームに使用されます:
Zhu Standards Track [Page 5] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[5ページ]。
Marker bit (M bit): The Marker bit of the RTP fixed header is set to 1 when the current packet carries the end of current frame; set to 0 otherwise.
マーカーは噛み付きました(Mは噛み付きました): 現在のパケットが現在のフレームの端を運ぶとき、ヘッダーに固定されたRTPのMarkerビットは1に設定されます。 そうでなければ、0にセットしてください。
Payload Type (PT): The Payload Type shall specify H.263 video payload format using the value specified by the RTP profile in use, for example RFC 1890 [3].
有効搭載量タイプ(太平洋標準時の): 有効搭載量Typeは、RTPプロフィールによって指定された値を使用することで使用(例えば、RFC1890[3])でH.263ビデオペイロード形式を指定するものとします。
Timestamp: The RTP timestamp encodes the sampling instant of the video frame contained in the RTP data packet. The RTP timestamp may be the same on successive packets if a video frame occupies more than one packet. For H.263 video streams, the RTP timestamp is based on a 90 kHz clock, the same as the RTP timestamp for H.261 video streams [5].
タイムスタンプ: RTPタイムスタンプはRTPデータ・パケットに含まれたビデオフレームの標本抽出の瞬間をコード化します。 ビデオフレームが1つ以上のパケットを占領するなら、RTPタイムスタンプは連続したパケットで同じであるかもしれません。 H.263ビデオストリームにおいて、RTPタイムスタンプは90kHzの時計に基づいています、H.261ビデオストリーム[5]のためのRTPタイムスタンプと同じです。
4.2 Video Packet Structure
4.2 ビデオパケット構造
For each RTP packet, the RTP fixed header is followed by the H.263 payload header, which is followed by the standard H.263 compressed bitstream [4].
それぞれのRTPパケットに関しては、ヘッダーに固定されたRTPはH.263ペイロードヘッダーによって後をつけられていて、どれが標準のH.263によって続かれているかがbitstream[4]を圧縮しました。
The size of the H.263 payload header is variable depending on modes used as detailed in the next section. The layout of an RTP H.263 video packet is shown as:
次のセクションで詳しく述べられるように使用されるモードによって、H.263ペイロードヘッダーのサイズは可変です。 RTP H.263ビデオパケットのレイアウトは以下として示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263 payload header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.263 bitstream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263ペイロードヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 bitstream| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. H.263 Payload Header
5. H.263有効搭載量ヘッダー
For H.263 video streams, each RTP packet carries only one H.263 video packet. The H.263 payload header is always present for each H.263 video packet.
H.263ビデオストリームのために、それぞれのRTPパケットは1つのH.263ビデオパケットだけを運びます。 H.263ペイロードヘッダーはそれぞれのH.263ビデオパケットのためにいつも出席しています。
Three formats (mode A, mode B and mode C) are defined for H.263 payload header. In mode A, an H.263 payload header of four bytes is present before actual compressed H.263 video bitstream in a packet. It allows fragmentation at GOB boundaries. In mode B, an eight byte H.263 payload header is used and each packet starts at MB boundaries without the PB-frames option. Finally, a twelve byte H.263 payload
3つの書式(モードA、モードB、およびモードC)がH.263ペイロードヘッダーのために定義されます。 流行しているA、4バイトのH.263ペイロードヘッダーはパケットの実際の圧縮されたH.263ビデオbitstreamの前に出席しています。 それはGOB境界で断片化を許します。 流行しているB、8バイトのH.263ペイロードヘッダーは使用されています、そして、各パケットはMB境界でPB-フレームオプションなしで始まります。 最終的に12バイトのH.263ペイロード
Zhu Standards Track [Page 6] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[6ページ]。
header is defined in mode C to support fragmentation at MB boundaries for frames that are coded with the PB-frames option.
ヘッダーは、MB境界でPB-フレームオプションでコード化されるフレームに断片化を支持するためにモードCで定義されます。
The mode of each H.263 payload header is indicated by the F and P fields in the header. Packets of different modes can be intermixed. All client application are required to be able to receive packets in any mode, but decoding of mode C packets is optional because the PB- frames feature is optional.
それぞれのH.263ペイロードヘッダーのモードはヘッダーのFとP分野によって示されます。 異なったモードのパケットを混ぜることができます。 すべてのクライアントアプリケーションがどんなモードでもパケットを受けることができるように必要ですが、PBフレームの特徴が任意であるので、モードCパケットの解読は任意です。
In this section, the H.263 payload format is shown as rows of 32-bit words. Each word is transmitted in network byte order. Whenever a field represents a numeric value, the most significant bit is at the left of the field.
このセクションで、H.263ペイロード書式は32ビットの単語の列として示されます。 各言葉はネットワークバイトオーダーで伝えられます。 分野が数値を表すときはいつも、最も重要なビットが分野左側にあります。
5.1 Mode A
5.1 モードA
In this mode, an H.263 bitstream will be packetized on a GOB boundary or a picture boundary. Mode A packets always start with the H.263 picture start code [4] or a GOB, but do not necessarily contain complete GOBs. Four bytes are used for the mode A H.263 payload header. The H.263 payload header definition for mode A is shown as follows with F=0. Mode A packets are allowed to start at a GOB boundary even if no GOB header is present in the bitstream for the GOB. However, such use is discouraged due to the dependencies it creates across GOB boundaries, as described in Section 3.3.
このモードで、H.263 bitstreamはGOB境界か絵の限界でpacketizedされるでしょう。 モードAパケットは、いつもH.263絵のスタートコード[4]かGOBから始まりますが、必ず完全なGOBsを含むというわけではありません。 4バイトはモードA H.263ペイロードヘッダーに使用されます。 モードAのためのH.263ペイロードヘッダー定義は以下の通りF=0で示されます。 どんなGOBヘッダーもGOBのためにbitstreamに出席していなくても、モードAパケットはGOB境界で始まることができます。 しかしながら、そのような使用はそれがGOB境界の向こう側に引き起こす依存のためにセクション3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|P|SBIT |EBIT | SRC |I|U|S|A|R |DBQ| TRB | TR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT|EBIT| SRC|I|U|S|A|R|DBQ| TRB| TR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
F: 1 bit The flag bit indicates the mode of the payload header. F=0, mode A; F=1, mode B or mode C depending on P bit defined below.
F: 1ビット、フラグビットはペイロードヘッダーのモードを示します。 Fは0、モードAと等しいです。 以下で定義されたPビットによって、Fは1、モードBまたはモードCと等しいです。
P: 1 bit Optional PB-frames mode as defined by the H.263 [4]. "0" implies normal I or P frame, "1" PB-frames. When F=1, P also indicates modes: mode B if P=0, mode C if P=1.
P: H.263[4]によって定義される1ビットのOptional PB-フレームモード。 「「1インチのPbフレーム。」と、何0インチも、普通の私かPフレームが暗示します。 また、F=1であるときに、Pはモードを示します: モードB、P=0、モードCである、P=1であるなら。
SBIT: 3 bits Start bit position specifies number of most significant bits that shall be ignored in the first data byte.
SBIT: 3ビットのStartビット位置は最初のデータ・バイトで無視されるものとする最上位ビットの数を指定します。
EBIT: 3 bits End bit position specifies number of least significant bits that shall be ignored in the last data byte.
EBIT: 3ビットのEndビット位置は最後のデータ・バイトで無視されるものとする最下位ビットの数を指定します。
Zhu Standards Track [Page 7] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[7ページ]。
SRC : 3 bits Source format, bit 6,7 and 8 in PTYPE defined by H.263 [4], specifies the resolution of the current picture.
SRC: 3ビットのSource形式(H.263[4]によって定義されたPTYPEのビット6、7、および8)は現在の画像の解像度を指定します。
I: 1 bit. Picture coding type, bit 9 in PTYPE defined by H.263[4], "0" is intra-coded, "1" is inter-coded.
私: 1ビット。 H.263[4]によって定義されたPTYPEにビット9のコード化タイプについて描写してください、「0インチによるイントラによってコード化されていて、「1インチは相互コード化される」ということです。
U: 1 bit Set to 1 if the Unrestricted Motion Vector option, bit 10 in PTYPE defined by H.263 [4] was set to 1 in the current picture header, otherwise 0.
U: 1はUnrestricted Motion VectorオプションであるならSetに1まで噛み付いて、H.263[4]によって定義されたPTYPEのビット10はそうでなければ、0歳の現在の絵のヘッダーで1に設定されました。
S: 1 bit Set to 1 if the Syntax-based Arithmetic Coding option, bit 11 in PTYPE defined by the H.263 [4] was set to 1 for current picture header, otherwise 0.
S: 1はSyntaxベースのArithmetic CodingオプションであるならSetに1まで噛み付いて、H.263[4]によって定義されたPTYPEのビット11はそうでなければ、0歳の現在の絵のヘッダーのために1に設定されました。
A: 1 bit Set to 1 if the Advanced Prediction option, bit 12 in PTYPE defined by H.263 [4] was set to 1 for current picutre header, otherwise 0.
A: 1はAdvanced PredictionオプションであるならSetに1まで噛み付いて、H.263[4]によって定義されたPTYPEのビット12はそうでなければ、0歳の現在のpicutreヘッダーのために1に設定されました。
R: 4 bits Reserved, must be set to zero.
R: 4ビットのReservedはゼロへのセットであるに違いありません。
DBQ: 2 bits Differential quantization parameter used to calculate quantizer for the B frame based on quantizer for the P frame, when PB-frames option is used. The value should be the same as DBQUANT defined by H.263 [4]. Set to zero if PB-frames option is not used.
DBQ: 2ビットのDifferential量子化パラメタはPフレームのために以前はよく量子化器に基づくBフレームに量子化器について計算していました、PB-フレームオプションが使用されているとき。 値はH.263[4]によって定義されたDBQUANTと同じであるべきです。 PB-フレームオプションが使用されていないなら、ゼロにセットしてください。
TRB: 3 bits Temporal Reference for the B frame as defined by H.263 [4]. Set to zero if PB-frames option is not used.
TRB: H.263[4]によって定義されるBフレームへの3ビットのTemporal Reference。 PB-フレームオプションが使用されていないなら、ゼロにセットしてください。
TR: 8 bits Temporal Reference for the P frame as defined by H.263 [4]. Set to zero if the PB-frames option is not used.
TR: H.263[4]によって定義されるPフレームへの8ビットのTemporal Reference。 PB-フレームオプションが使用されていないなら、ゼロにセットしてください。
5.2 Mode B
5.2 モードB
In this mode, an H.263 bitstream can be fragmented at MB boundaries. Whenever a packet starts at a MB boundary, this mode shall be used without PB-frames option. Mode B packets are intended for a GOB whose size is larger than the maximum packet size allowed in the underlying protocol, thus making it impossible to fit one or more complete GOBs in a packet. This mode can only be used without the PB-frames option. Mode C as defined in the next section can be used to fragment H.263
このモードで、MB境界でH.263 bitstreamを断片化できます。 パケットがMB境界で始まるときはいつも、このモードはPB-フレームオプションなしで使用されるものとします。 モードBパケットはサイズが基本的なプロトコルで許容されていて、その結果1つに合うのを不可能にする最大のパケットサイズか以上がパケットでGOBsを完成するより大きいGOBのために意図します。 PB-フレームオプションなしでこのモードを使用できるだけです。 H.263を断片化するのに次のセクションで定義されるモードCは使用できます。
Zhu Standards Track [Page 8] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[8ページ]。
bitstreams at MB boundaries with the PB-frames option. The H.263 payload header definition for mode B is shown as follows with F=1 and P=0:
PB-フレームオプションがあるMB境界のbitstreams。 モードBのためのH.263ペイロードヘッダー定義は以下の通り1とF=P=0と共に示されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT|EBIT| SRC| 舟棹| GOBN| MBA|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|U|S|A| HMV1| VMV1| HMV2| VMV2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined the same as in mode A: F, P, SBIT, EBIT, SRC, I, U, S and A. Other fields are defined as follows:
以下の野原はモードA:で同じように定義づけられます。 F、P、SBIT、EBIT、SRC、私、U、S、およびA.Other分野は以下の通り定義されます:
QUANT: 5 bits Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header. This is the equivalent of GQUANT defined by the H.263 [4].
舟棹: パケットの始めのときにコード化された最初のMB単位で5ビットのQuantization値。 パケットがGOBヘッダーと共に始まるなら、0にセットしてください。 これはH.263[4]によって定義されたGQUANTの同等物です。
GOBN: 5 bits GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions. See H.263 [4] for details.
GOBN: 事実上、GOBがパケットの始めで付番する5ビット。 GOB番号は異なった解決に異なって指定されます。 詳細に関してH.263[4]を見てください。
MBA: 9 bits The address within the GOB of the first MB in the packet, counting from zero in scan order. For example, the third MB in any GOB is given MBA = 2.
MBA: 9ビット、パケットの最初のMBのGOBの中のアドレス、勘定はスキャンにおけるゼロに注文します。 例えば、どんなGOBでも第3MBにMBA=2を与えます。
HMV1, VMV1: 7 bits each. Horizontal and vertical motion vector predictors for the first MB in this packet [4]. When four motion vectors are used for current MB with advanced prediction option, these would be the motion vector predictors for block number 1 in the MB. Each 7 bits field encodes a motion vector predictor in half pixel resolution as a 2's complement number.
HMV1、VMV1: それぞれ7ビット。 このパケット[4]における最初のMB単位で水平面と上下動ベクトル予言者。 4つの運動ベクトルが現在のMBに高度な予測オプションで使用されるとき、これらはMBにおける街区番号1のための運動ベクトル予言者でしょう。 各7ビットの分野は2番号の補数ものとして運動ベクトルの予言者の半分の画素解像度をコード化します。
HMV2, VMV2: 7 bits each. Horizontal and vertical motion vector predictors for block number 3 in the first MB in this packet when four motion vectors are used with the advanced prediction option. This is needed because block number 3 in the MB needs different motion vector predictors from other blocks in the MB. These two fields are not used when the MB only has one motion vector. See the H.263 [4] for block organization in a macroblock. Each 7 bits field encodes a motion vector predictor in half pixel resolution as a 2's complement number.
HMV2、VMV2: それぞれ7ビット。 4がベクトルを身ぶりで合図するとき、このパケットにおける最初のMBにおける街区番号3のための水平面と上下動ベクトル予言者は高度な予測オプションと共に使用されます。 MBにおける街区番号3がMBで他のブロックと異なった運動ベクトル予言者を必要とするので、これが必要です。 MBに1つの運動ベクトルしかないとき、これらの2つの分野は使用されていません。 macroblockでのブロック組織に関してH.263[4]を見てください。 各7ビットの分野は2番号の補数ものとして運動ベクトルの予言者の半分の画素解像度をコード化します。
Zhu Standards Track [Page 9] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[9ページ]。
R : 2 bits Reserved, must be set to zero.
R: 2ビットのReservedはゼロへのセットであるに違いありません。
5.3 Mode C
5.3 モードC
In this mode, an H.263 bitstream is fragmented at MB boundaries of P frames with the PB-frames option. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlying protocol when PB-frames option is used. The H.263 payload header definition for mode C is shown as follows with F=1 and P=1:
このモードで、H.263 bitstreamはPフレームのMB境界でPB-フレームオプションで断片化されます。 それはサイズがPB-フレームオプションが使用されているとき基本的なプロトコルで許容された最大のパケットサイズより大きいそれらのGOBsのために意図します。 モードCのためのH.263ペイロードヘッダー定義は以下の通り1とF=P=1と共に示されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |DBQ| TRB | TR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT|EBIT| SRC| 舟棹| GOBN| MBA|R| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|U|S|A| HMV1| VMV1| HMV2| VMV2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR|DBQ| TRB| TR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following fields are defined the same as in mode B: F, P, SBIT, EBIT, SRC, QUANT, GOBN, MBA, R, I, U, S, A, HMV1, VMV1, HMV2, VMV2. The rest of the fields (TR, DBQ, TRB) are defined the same as in mode A, except field RR. The RR field takes 19 bits, and is currently reserved. It must be set to zero.
以下の野原はモードBで同じように定義づけられます: F、P、SBIT、EBIT、SRC、舟棹、GOBN、MBA、R、I、U、S、A、HMV1、VMV1、HMV2、VMV2。 分野RRを除いて、分野(TR、DBQ、TRB)の残りはモードAで同じように定義づけられます。 RR分野は、19ビット取って、現在、予約されます。 ゼロにそれを設定しなければなりません。
5.4 Selection of Modes for the H.263 Payload Header
5.4 H.263有効搭載量ヘッダーのためのモードの品揃え
Packets carrying H.263 video streams with different modes can be intermixed. The modes shall be selected carefully based on network packet size, H.263 coding options and underlying network protocols. More specifically, mode A shall be used for packets starting with a GOB or the H.263 picture start code [4], and mode B or C shall be used whenever a packet has to start at a MB boundary. Mode B or C are necessary for those GOBs with sizes larger than network packet size.
異なったモードでH.263ビデオストリームを運ぶパケットは混ぜることができます。 モードはネットワークパケットサイズ、オプションをコード化するH.263、および基本的なネットワーク・プロトコルに基づいて慎重に選択されるものとします。 より明確に、モードAはGOBから始まるパケットかH.263絵のスタートコード[4]に使用されるものとします、そして、パケットがMB境界で始まらなければならないときはいつも、モードBかCは使用されるものとします。 サイズがネットワークパケットサイズより大きい状態でモードBかCがそれらのGOBsに必要です。
We strongly recommend use of mode A whenever possible. The major advantage of mode A over mode B and C is its simplicity. The H.263 payload header is smaller than mode B and C. Transmission overhead is reduced and the savings may be very significant when working with very low data rates or relatively small packet sizes.
可能であるときはいつも、私たちは強くモードAの使用を推薦します。 モードBとCの上のモードAの主要な利点はその簡単さです。 H.263ペイロードヘッダーはモードBとC.Transmissionオーバーヘッドが下げられるより小さいです、そして、非常に低いデータ信号速度か比較的小さいパケットサイズで働いているとき、貯蓄は非常に重要であるかもしれません。
Another advantage of mode A is that it simplifies error recovery in the presence of packet loss. The internal state of a decoder can be recovered at GOB boundaries instead of having to synchronize with MBs as in mode B and C. The GOB headers and the picture start code are easy to identify, and their presence will normally cause a H.263
モードAの別の利点はパケット損失の面前でエラー回復を簡素化するということです。 流行しているBとGOBヘッダーと絵の始めがコード化するC.は特定しやすくて、彼らの存在が通常H.263を引き起こすときMBに連動しなければならないことの代わりにGOB境界でデコーダの内部の状態を回復できます。
Zhu Standards Track [Page 10] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[10ページ]。
decoder to re-synchronize its internal states.
内部の州を再連動させるデコーダ。
Finally, we would like to stress that recovery from packet loss depends on a decoder's ability to use the information provided in the H.263 payload header within RTP packets.
最終的に、パケット損失からの回復をRTPパケットの中でH.263ペイロードヘッダーに提供された情報を使用するデコーダの性能に依存すると強調したいと思います。
6. Limitations
6. 制限
The packetization method described in this document applies to the 1996 version of H.263. It may not be applicable to bitstreams with features added after that.
本書では説明されたpacketization方法は1996年のH.263のバージョンに適用されます。 特徴がその後に加えられている状態で、それはbitstreamsに適切でないかもしれません。
Security Considerations
セキュリティ問題
Security issues are addressed by RTP [1]. This memo does not bring up any additional security issues.
安全保障問題はRTP[1]によって記述されます。 このメモはどんな追加担保問題も持って来ません。
7. Acknowledgments
7. 承認
The author would like to thank the following people for their valuable comments: Linda S. Cline, Christian Maciocco, Mojy Mirashrafi, Phillip Lantz, Steve Casner, Gary Sullivan, and Sassan Pejhan.
作者は彼らの貴重なコメントについて以下の人々に感謝したがっています: リンダS.クライン、クリスチャンのMaciocco、Mojy Mirashrafi、フィリップ・ランツ、スティーブCasner、ゲーリー・サリバン、およびSassan Pejhan。
8. References
8. 参照
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[2] International Telecommunication Union.
Video Codec for Audiovisual Services at p x 64 kbits/s,
ITU-T Recommendation H.261, 1993.
[2] 国際電気通信連合。 p x64kbits/sのAudiovisual ServicesのためのビデオCodec、ITU-T Recommendation H.261、1993。
[3] Schulzrinne, H.,
"RTP Profile for Audio and Video Conference with Minimal
Control", RFC 1890,
January 1996.
[3]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
[4] International Telecommunication Union.
Video Coding for Low Bitrate Communication, ITU-T Recommendation
H.263, 1996
[4] 国際電気通信連合。 少ないBitrateコミュニケーションのためのビデオ符号化、ITU-T推薦H.263、1996
[5] Turletti, T., and C. Huitema,
"RTP Payload Format for H.261 Video Streams", RFC 2032,
October 1996.
[5]Turletti、T.、およびC.Huitema、「H.261ビデオストリームのためのRTP有効搭載量形式」、RFC2032、1996年10月。
Zhu Standards Track [Page 11] RFC 2190 RTP Payload Format for H.263 Video Streams September 1997
朱Standardsは1997年9月にH.263ビデオストリームのためにRFC2190RTP有効搭載量形式を追跡します[11ページ]。
[6] International Telecommunication Union.
Multiplexing Protocol for Low Bitrate Multimedia Communication,
ITU-T Recommendation H.223, 1995.
[6] 国際電気通信連合。 低いBitrateマルチメディア通信のためのプロトコル、ITU-T推薦H.223、1995を多重送信します。
7. Author's Address
7. 作者のアドレス
C. "Chad" Zhu Mail Stop: JF3-202 Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA
C.「チャド」朱のメール停止: JF3-202インテル社2111Avenueヒースボロー、または25番目の97124の東北米国
EMail: czhu@ibeam.intel.com Phone: (503) 264-6008 Fax: (503) 264-1805
メール: czhu@ibeam.intel.com 電話: (503) 264-6008 Fax: (503) 264-1805
Zhu Standards Track [Page 12]
朱標準化過程[12ページ]
一覧
スポンサーリンク
