RFC2032 日本語訳
2032 RTP Payload Format for H.261 Video Streams. T. Turletti, C.Huitema. October 1996. (Format: TXT=27488 bytes) (Obsoleted by RFC4587) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Turletti
Request for Comments: 2032 MIT
Category: Standards Track C. Huitema
Bellcore
October 1996
Turlettiがコメントのために要求するワーキンググループT.をネットワークでつないでください: 2032年のMITカテゴリ: 標準化過程C.Huitema Bellcore1996年10月
RTP Payload Format for H.261 Video Streams
H.261ビデオストリームのためのRTP有効搭載量形式
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Abstract ............................................. 1
2. Purpose of this document ............................. 2
3. Structure of the packet stream ....................... 2
3.1 Overview of the ITU-T recommendation H.261 .......... 2
3.2 Considerations for packetization .................... 3
4. Specification of the packetization scheme ............ 4
4.1 Usage of RTP ........................................ 4
4.2 Recommendations for operation with hardware codecs .. 6
5. Packet loss issues ................................... 7
5.1 Use of optional H.261-specific control packets ...... 8
5.2 H.261 control packets definition .................... 9
5.2.1 Full INTRA-frame Request (FIR) packet ............. 9
5.2.2 Negative ACKnowledgements (NACK) packet ........... 9
6. Security Considerations .............................. 10
Authors' Addresses ..................................... 10
Acknowledgements ....................................... 10
References ............................................. 11
1. 要約… 1 2. このドキュメントの目的… 2 3. パケットの流れの構造… 2 ITU-T推薦H.261の3.1概観… 2 packetizationのための3.2の問題… 3 4. packetization計画の仕様… 4 4.1 RTPの使用法… 4 ハードウェアコーデックがある操作のための4.2の推薦。 6 5. パケット損失問題… 7 5.1 任意のH.261特有のコントロールパケットの使用… 8 5.2 H.261はパケット定義を制御します… 9 5.2 .1完全なINTRA-フレームRequest(FIR)パケット… 9 5.2 .2の否定的ACKnowledgements(ナック)パケット… 9 6. セキュリティ問題… 10人の作者のアドレス… 10の承認… 10の参照箇所… 11
1. Abstract
1. 要約
This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP.
このメモはレアル-時間Transportプロトコルを使用することで輸送のためのH.261ビデオストリームをpacketizeするように計画について説明します、RTP、RTPを運ぶ基本的なプロトコルのいずれでも。
This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors.
この仕様はインターネット・エンジニアリング・タスク・フォースの中のAudio/ビデオTransportワーキンググループの製品です。 コメントは、請求されて、 rem-conf@es.net 、そして/または、作者にワーキンググループのメーリングリストに記述されるべきです。
Turletti & Huitema Standards Track [Page 1] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[1ページ]。
2. Purpose of this document
2. このドキュメントの目的
The ITU-T recommendation H.261 [6] specifies the encodings used by ITU-T compliant video-conference codecs. Although these encodings were originally specified for fixed data rate ISDN circuits, experiments [3],[8] have shown that they can also be used over packet-switched networks such as the Internet.
ITU-T推薦H.261[6]はITU-T対応することのテレビ会議コーデックによって使用されるencodingsを指定します。 これらのencodingsは元々固定データ信号速度ISDNサーキットに指定されましたが、実験[3]、[8]は、また、インターネットなどのパケット交換網の上でそれらを使用できるのを示しました。
The purpose of this memo is to specify the RTP payload format for encapsulating H.261 video streams in RTP [1].
このメモの目的はRTP[1]でH.261ビデオストリームをカプセルに入れるのにRTPペイロード形式を指定することです。
3. Structure of the packet stream
3. パケットの流れの構造
3.1. Overview of the ITU-T recommendation H.261
3.1. ITU-T推薦H.261の概観
The H.261 coding is organized as a hierarchy of groupings. The video stream is composed of a sequence of images, or frames, which are themselves organized as a set of Groups of Blocks (GOB). Note that H.261 "pictures" are referred as "frames" in this document. Each GOB holds a set of 3 lines of 11 macro blocks (MB). Each MB carries information on a group of 16x16 pixels: luminance information is specified for 4 blocks of 8x8 pixels, while chrominance information is given by two "red" and "blue" color difference components at a resolution of only 8x8 pixels. These components and the codes representing their sampled values are as defined in the ITU-R Recommendation 601 [7].
H.261コード化は組分けの階層構造として組織化されます。 ビデオストリームはBlocks(GOB)のGroupsの1セットとして組織化されるイメージ、またはフレームの系列で構成されます。 これの「フレーム」が記録するようにH.261「絵」が参照されることに注意してください。 各GOBは11マクロブロック(MB)の3つの線のセットを持っています。 各MBは16×16画素のグループの情報を運びます: 輝度情報は4ブロックの8×8画素に指定されます、8×8画素だけの解像度のときに2つの「赤く」て「青い」色差成分で色差情報を与えますが。 それらの標本値を表すこれらのコンポーネントとコードがITU-R Recommendation601[7]で定義されるようにあります。
This grouping is used to specify information at each level of the hierarchy:
この組分けは階層構造の各レベルで情報を指定するのに使用されます:
- At the frame level, one specifies information such as the
delay from the previous frame, the image format, and
various indicators.
- フレーム・レベルでは、1つは前のフレーム(画像形式の、そして、様々なインディケータ)からの遅れなどの情報を指定します。
- At the GOB level, one specifies the GOB number and the
default quantifier that will be used for the MBs.
- GOBレベルでは、1つはMBに使用されるGOB番号とデフォルト数量詞を指定します。
- At the MB level, one specifies which blocks are present
and which did not change, and optionally a quantifier and
motion vectors.
- MBレベルでは、1つはどのブロックが存在しているか、そして、どれが任意に変化しなかったかを指定します。数量詞と運動ベクトル。
Blocks which have changed are encoded by computing the discrete cosine transform (DCT) of their coefficients, which are then quantized and Huffman encoded (Variable Length Codes).
変化したブロックはそれらの係数の離散コサイン変換(DCT)を計算することによって、コード化されました、そして、ハフマンは(可変Length Codes)をコード化しました。次に、係数は量子化されます。
The H.261 Huffman encoding includes a special "GOB start" pattern, composed of 15 zeroes followed by a single 1, that cannot be imitated by any other code words. This pattern is included at the beginning of
H.261ハフマン符号化はいかなる他の婉曲的表現でも模倣できないただ一つの1があとに続いていて、15のゼロで構成された特別な「GOB始め」パターンを含んでいます。 このパターンは始めに含まれています。
Turletti & Huitema Standards Track [Page 2] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[2ページ]。
each GOB header (and also at the beginning of each frame header) to mark the separation between two GOBs, and is in fact used as an indicator that the current GOB is terminated. The encoding also includes a stuffing pattern, composed of seven zeroes followed by four ones; that stuffing pattern can only be entered between the encoding of MBs, or just before the GOB separator.
2GOBsの間の分離をマークして、事実上、マークするそれぞれのGOBヘッダー(そしてそれぞれのフレームヘッダーの始めにも)、現在のGOBが終えられるというインディケータとして、使用されています。 また、コード化は4つのものがあとに続いていて、7つのゼロで構成された詰め物のパターンを含んでいます。 MBのコード化の間か、GOB分離符のすぐ前にその詰め物のパターンに入ることができるだけです。
3.2. Considerations for packetization
3.2. packetizationのための問題
H.261 codecs designed for operation over ISDN circuits produce a bit stream composed of several levels of encoding specified by H.261 and companion recommendations. The bits resulting from the Huffman encoding are arranged in 512-bit frames, containing 2 bits of synchronization, 492 bits of data and 18 bits of error correcting code. The 512-bit frames are then interlaced with an audio stream and transmitted over px64 kbps circuits according to specification H.221 [5].
ISDNサーキットの上の操作のために設計されたH.261コーデックはH.261と仲間推薦で指定されたいくつかのレベルのコード化で構成された流れを少し起こします。 ハフマン符号化から生じるビットは512ビットのフレームに配置されます、同期の2ビット、492ビットのデータ、および誤り検出方式の18ビットを含んでいて。 512ビットのフレームは、次に、オーディオストリームによって交錯されて、仕様H.221[5]に応じて、px64キロビット毎秒サーキットの上に送られます。
When transmitting over the Internet, we will directly consider the output of the Huffman encoding. All the bits produced by the Huffman encoding stage will be included in the packet. We will not carry the 512-bit frames, as protection against bit errors can be obtained by other means. Similarly, we will not attempt to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more efficient way to achieve multiplexing.
インターネットの上を伝わるとき、私たちは直接ハフマン符号化の出力を考えるつもりです。 ハフマン符号化段階によって作り出されたすべてのビットがパケットに含まれるでしょう。 他の手段で噛み付いている誤りに対する保護を得ることができるのに従って、私たちは512ビットのフレームを運ぶつもりではありません。 同様に、私たちは、同じパケットでオーディオとビデオ信号を多重送信するのを試みるつもりではありません、UDPとRTPがマルチプレクシングを達成するはるかに効率的な方法を提供するとき。
Directly transmitting the result of the Huffman encoding over an unreliable stream of UDP datagrams would, however, have poor error resistance characteristics. The result of the hierachical structure of H.261 bit stream is that one needs to receive the information present in the frame header to decode the GOBs, as well as the information present in the GOB header to decode the MBs. Without precautions, this would mean that one has to receive all the packets that carry an image in order to properly decode its components.
しかしながら、UDPデータグラムの頼り無いストリームで直接ハフマン符号化の結果を伝えるのにおいて、貧しい誤り抵抗の特性があるでしょう。 H.261ビットストリームのhierachical構造の結果は人が、GOBsを解読するためにフレームヘッダーの現在の情報を受け取る必要があるということです、MBを解読するGOBヘッダーの現在の情報と同様に。 注意がなければ、これは、人が適切にコンポーネントを解読するためにイメージを運ぶすべてのパケットを受けなければならないことを意味するでしょう。
If each image could be carried in a single packet, this requirement would not create a problem. However, a video image or even one GOB by itself can sometimes be too large to fit in a single packet. Therefore, the MB is taken as the unit of fragmentation. Packets must start and end on a MB boundary, i.e. a MB cannot be split across multiple packets. Multiple MBs may be carried in a single packet when they will fit within the maximal packet size allowed. This practice is recommended to reduce the packet send rate and packet overhead.
単一のパケットで各イメージを運ぶことができるなら、この要件は問題を生じさせないでしょうに。 しかしながら、それ自体でビデオ画像か1GOBさえ時々単一のパケットをうまくはめ込むことができないくらい大きい場合があります。 したがって、MBは断片化のユニットとしてみなされます。 パケットはMB境界で終始しなければなりません、すなわち、複数のパケットの向こう側に1MBを分けることができません。 彼らがサイズが許容した最大限度のパケットの中で合うと、複数のMBが単一のパケットで運ばれるかもしれません。 習慣がパケットを減少させることが勧められるこれはレートとパケットオーバーヘッドを送ります。
To allow each packet to be processed independently for efficient resynchronization in the presence of packet losses, some state information from the frame header and GOB header is carried with each
各パケットがパケット損失の面前で効率的な再同期のために独自に処理されるのを許容するために、フレームヘッダーとGOBヘッダーからの何らかの州の情報がそれぞれで運ばれます。
Turletti & Huitema Standards Track [Page 3] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[3ページ]。
packet to allow the MBs in that packet to be decoded. This state information includes the GOB number in effect at the start of the packet, the macroblock address predictor (i.e. the last MBA encoded in the previous packet), the quantizer value in effect prior to the start of this packet (GQUANT, MQUANT or zero in case of a beginning of GOB) and the reference motion vector data (MVD) for computing the true MVDs contained within this packet. The bit stream cannot be fragmented between a GOB header and MB 1 of that GOB.
そのパケットのMBが解読されるのを許容するパケット。 事実上、この州の情報はパケット(事実上、(すなわち、前のパケットでコード化された最後のMBA)、量子化器がこのパケット(GOBの始まりの場合のGQUANT、MQUANTまたはゼロ)の始まりの前に評価して、本当のMVDsを計算するための参照動きベクトルデータ(MVD)がこのパケットの中に含んだmacroblockアドレス予言者)の始めにGOB番号を含んでいます。 そのGOBのGOBヘッダーとMB1の間でビットストリームを断片化できません。
Moreover, since the compressed MB may not fill an integer number of octets, the data header contains two three-bit integers, SBIT and EBIT, to indicate the number of unused bits in the first and last octets of the H.261 data, respectively.
そのうえ、圧縮されたMBが八重奏の整数をいっぱいにしないかもしれないので、データヘッダーは1番目の未使用のビットの数を示して、H.261データの八重奏がそれぞれ続くように2つの3ビットの整数、SBIT、およびEBITを含んでいます。
4. Specification of the packetization scheme
4. packetization計画の仕様
4.1. Usage of RTP
4.1. RTPの使用法
The H.261 information is carried as payload data within the RTP protocol. The following fields of the RTP header are specified:
RTPの中のペイロードデータが議定書を作るのに従って、H.261情報は運ばれます。 RTPヘッダーの以下の分野は指定されます:
- The payload type should specify H.261 payload format (see
the companion RTP profile document RFC 1890).
- ペイロードタイプはH.261ペイロード形式を指定するべきです(仲間RTPがドキュメントRFC1890の輪郭を描くのを見てください)。
- The RTP timestamp encodes the sampling instant of the
first video image contained in the RTP data packet. If a
video image occupies more than one packet, the timestamp
will be the same on all of those packets. Packets from
different video images must have different timestamps so
that frames may be distinguished by the timestamp. For
H.261 video streams, the RTP timestamp is based on a
90kHz clock. This clock rate is a multiple of the natural
H.261 frame rate (i.e. 30000/1001 or approx. 29.97 Hz).
That way, for each frame time, the clock is just
incremented by the multiple and this removes inaccuracy
in calculating the timestamp. Furthermore, the initial
value of the timestamp is random (unpredictable) to make
known-plaintext attacks on encryption more difficult, see
RTP [1]. Note that if multiple frames are encoded in a
packet (e.g. when there are very little changes between
two images), it is necessary to calculate display times
for the frames after the first using the timing
information in the H.261 frame header. This is required
because the RTP timestamp only gives the display time of
the first frame in the packet.
- RTPタイムスタンプはRTPデータ・パケットに含まれた最初のビデオ画像の標本抽出の瞬間をコード化します。 ビデオ画像が1つ以上のパケットを占領すると、タイムスタンプはそれらのパケットのすべてで同じになるでしょう。 異なったビデオ画像からのパケットには、異なったタイムスタンプが、タイムスタンプがフレームを区別できるように、なければなりません。 H.261ビデオストリームにおいて、RTPタイムスタンプは90kHzの時計に基づいています。 このクロックレートは自然なH.261フレームレート(すなわち、30000/1001Hzかおよそ29.97Hz)の倍数です。 そのように、フレーム毎回の間、時計はただ倍数増加されます、そして、これはタイムスタンプについて計算する際に不正確を取り除きます。 その上、タイムスタンプの初期の値は暗号化に対する知られている平文攻撃をより難しくするように無作為です(予測できない)、とRTP[1]は見ます。 複数のフレームがパケットでコード化されるなら(例えば、いつ、2つのイメージの間には、非常に小さい変化がありますか)、1日以降表示時間についてフレームに計算するのがH.261フレームヘッダーでタイミング情報を使用することで必要であることに注意してください。 RTPタイムスタンプがパケットの最初のフレームの表示時間を与えるだけであるので、これが必要です。
- The marker bit of the RTP header is set to one in the
last packet of a video frame, and otherwise, must be
- RTPヘッダーのマーカービットはビデオフレーム、そうでないことの最後のパケットの1つへのセットがあるに違いないということです。
Turletti & Huitema Standards Track [Page 4] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[4ページ]。
zero. Thus, it is not necessary to wait for a following
packet (which contains the start code that terminates the
current frame) to detect that a new frame should be
displayed.
ゼロ。 したがって、検出する次のパケット(現在のフレームを終えるスタートコードを含む)を待つために、新しいフレームを表示するのは必要ではありません。
The H.261 data will follow the RTP header, as in:
H.261データは以下のように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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. RTP header .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H.261 stream ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.261ヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.261は流れます… . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The H.261 header is defined as following:
H.261ヘッダーは以下に続くと定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SBIT |EBIT |I|V| GOBN | MBAP | QUANT | HMVD | VMVD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |SBIT|EBIT|I|V| GOBN| MBAP| 舟棹| HMVD| VMVD| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the H.261 header have the following meanings:
H.261ヘッダーの分野には、以下の意味があります:
Start bit position (SBIT): 3 bits
Number of most significant bits that should be ignored
in the first data octet.
スタートビット位置の(SBIT): 最初のデータ八重奏で無視されるべきである最上位ビットの3ビットのNumber。
End bit position (EBIT): 3 bits
Number of least significant bits that should be ignored
in the last data octet.
ビット位置(EBIT)を終わらせてください: 最後のデータ八重奏で無視されるべきである最下位ビットの3ビットのNumber。
INTRA-frame encoded data (I): 1 bit
Set to 1 if this stream contains only INTRA-frame coded
blocks. Set to 0 if this stream may or may not contain
INTRA-frame coded blocks. The sense of this bit may not
change during the course of the RTP session.
INTRA-フレームはデータ(I)をコード化しました: この流れがINTRA-フレームだけを含んでいるなら、1への1ビットのSetはブロックをコード化しました。 この流れがINTRA-フレームコード化されたブロックを含むかもしれないなら、0にセットしてください。 このビットの感覚はRTPセッションのコースの間、変化しないかもしれません。
Motion Vector flag (V): 1 bit
Set to 0 if motion vectors are not used in this stream.
Set to 1 if motion vectors may or may not be used in
this stream. The sense of this bit may not change during
the course of the session.
動きVectorは(V)に旗を揚げさせます: 運動ベクトルがこれで使用されないなら、0への1ビットのSetは流れます。 運動ベクトルがこの流れに使用されるかもしれないなら、1にセットしてください。 このビットの感覚はセッションのコースの間、変化しないかもしれません。
Turletti & Huitema Standards Track [Page 5] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[5ページ]。
GOB number (GOBN): 4 bits
Encodes the GOB number in effect at the start of the
packet. Set to 0 if the packet begins with a GOB header.
GOB番号(GOBN): 事実上、GOBがパケットの始めで付番する4ビットのEncodes。 パケットがGOBヘッダーと共に始まるなら、0にセットしてください。
Macroblock address predictor (MBAP): 5 bits
Encodes the macroblock address predictor (i.e. the last
MBA encoded in the previous packet). This predictor ranges
from 0-32 (to predict the valid MBAs 1-33), but because
the bit stream cannot be fragmented between a GOB header
and MB 1, the predictor at the start of the packet can
never be 0. Therefore, the range is 1-32, which is biased
by -1 to fit in 5 bits. For example, if MBAP is 0, the
value of the MBA predictor is 1. Set to 0 if the packet
begins with a GOB header.
Macroblockは予言者(MBAP)を記述します: macroblockアドレス予言者(すなわち、前のパケットでコード化された最後のMBA)の5ビットのEncodes。 この予言者は0-32(有効なMBAs1-33を予測する)から変化しますが、GOBヘッダーとMB1の間でビットストリームを断片化できないので、パケットの始めの予言者は0歳であるはずがありません。 したがって、範囲は1-32です(5ビット適合するように-1偏られます)。 例えば、MBAPが0歳であるなら、MBA予言者の値は1です。 パケットがGOBヘッダーと共に始まるなら、0にセットしてください。
Quantizer (QUANT): 5 bits
Quantizer value (MQUANT or GQUANT) in effect prior to the
start of this packet. Set to 0 if the packet begins with
a GOB header.
量子化器(舟棹): 事実上、5ビットのQuantizerはこのパケットの始まりの前に(MQUANTかGQUANT)を評価します。 パケットがGOBヘッダーと共に始まるなら、0にセットしてください。
Horizontal motion vector data (HMVD): 5 bits
Reference horizontal motion vector data (MVD). Set to 0
if V flag is 0 or if the packet begins with a GOB header,
or when the MTYPE of the last MB encoded in the previous
packet was not MC. HMVD is encoded as a 2's complement
number, and `10000' corresponding to the value -16 is
forbidden (motion vector fields range from +/-15).
水平動ベクトルデータ(HMVD): 5ビットのReference水平動ベクトルデータ(MVD)。 V旗が0であるかパケットがGOBヘッダーと共に始まるか、または前のパケットでコード化された最後のMBのMTYPEがM.C.でなかったときに、0にセットしてください。 2番号の補数もの、および値-16に対応する'10000'が禁制であるときに(動きベクトル場は+/-15から変化します)、HMVDはコード化されます。
Vertical motion vector data (VMVD): 5 bits
Reference vertical motion vector data (MVD). Set to 0 if
V flag is 0 or if the packet begins with a GOB header, or
when the MTYPE of the last MB encoded in the previous
packet was not MC. VMVD is encoded as a 2's complement
number, and `10000' corresponding to the value -16 is
forbidden (motion vector fields range from +/-15).
上下動ベクトルデータ(VMVD): 5ビットのReference上下動ベクトルデータ(MVD)。 V旗が0であるかパケットがGOBヘッダーと共に始まるか、または前のパケットでコード化された最後のMBのMTYPEがM.C.でなかったときに、0にセットしてください。 2番号の補数もの、および値-16に対応する'10000'が禁制であるときに(動きベクトル場は+/-15から変化します)、VMVDはコード化されます。
Note that the I and V flags are hint flags, i.e. they can be inferred from the bit stream. They are included to allow decoders to make optimizations that would not be possible if these hints were not provided before bit stream was decoded. Therefore, these bits cannot change for the duration of the stream. A conformant implementation can always set V=1 and I=0.
IとV旗がヒント旗であることに注意してください、そして、すなわち、ビットストリームからそれらは推論できます。 それらは、デコーダがビットストリームが解読される前にこれらのヒントが提供されないなら可能でない最適化をするのを許容するために含まれています。 したがって、これらのビットは流れの持続時間のために変化できません。 conformant実現はいつもV=1とI=0を設定できます。
4.2. Recommendations for operation with hardware codecs
4.2. ハードウェアコーデックがある操作のための推薦
Packetizers for hardware codecs can trivially figure out GOB boundaries using the GOB-start pattern included in the H.261 data. (Note that software encoders already know the boundaries.) The
ハードウェアコーデックのためのPacketizersは、H.261データに含まれていたGOB-スタートパターンを使用することでGOB境界を些細なことに理解できます。 (ソフトウェアエンコーダが既に境界を知ることに注意してください。) The
Turletti & Huitema Standards Track [Page 6] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[6ページ]。
cheapest packetization implementation is to packetize at the GOB level all the GOBs that fit in a packet. But when a GOB is too large, the packetizer has to parse it to do MB fragmentation. (Note that only the Huffman encoding must be parsed and that it is not necessary to fully decompress the stream, so this requires relatively little processing; example implementations can be found in some public H.261 codecs such as IVS [4] and VIC [9].) It is recommended that MB level fragmentation be used when feasible in order to obtain more efficient packetization. Using this fragmentation scheme reduces the output packet rate and therefore reduces the overhead.
最も安いpacketization実現はGOBレベルでパケットをうまくはめ込むすべてのGOBsをpacketizeすることです。 しかし、GOBが大き過ぎるときに、packetizerは、MB断片化をするためにそれを分析しなければなりません。 (これが比較的小さい処理を必要とするように、ハフマン符号化だけを分析しなければならなくて、流れを完全に減圧するのは必要でないことに注意してください; IVS[4]やVIC[9]などのいくつかの公共のH.261コーデックで例の実現を見つけることができます。) 可能であるときに、MBの平らな断片化が、より効率的なpacketizationを入手するのに使用されるのは、お勧めです。 この断片化計画を使用すると、出力パケット率が低下して、したがって、オーバーヘッドは下げられます。
At the receiver, the data stream can be depacketized and directed to a hardware codec's input. If the hardware decoder operates at a fixed bit rate, synchronization may be maintained by inserting the stuffing pattern between MBs (i.e., between packets) when the packet arrival rate is slower than the bit rate.
受信機では、ハードウェアコーデックの入力にデータ・ストリームをdepacketizedして、向けることができます。 ハードウェアデコーダが固定ビット伝送速度で作動するなら、同期は、パケット到着率がビット伝送速度より遅いときに、MB(すなわち、パケットの間の)の間に詰め物のパターンを挿入することによって、維持されるかもしれません。
5. Packet loss issues
5. パケット損失問題
On the Internet, most packet losses are due to network congestion rather than transmission errors. Using UDP, no mechanism is available at the sender to know if a packet has been successfully received. It is up to the application, i.e. coder and decoder, to handle the packet loss. Each RTP packet includes a a sequence number field which can be used to detect packet loss.
インターネットに、ほとんどのパケット損失が伝送エラーよりむしろネットワークの混雑のためにあります。 UDPを使用して、首尾よくパケットを受け取ったなら、どんなメカニズムも知る送付者で利用可能ではありません。 それは、パケット損失を扱うためにはすなわち、アプリケーション、符号化器、およびデコーダ次第です。 それぞれのRTPパケットはパケット損失を検出するのに使用できるa一連番号分野を含んでいます。
H.261 uses the temporal redundancy of video to perform compression. This differential coding (or INTER-frame coding) is sensitive to packet loss. After a packet loss, parts of the image may remain corrupt until all corresponding MBs have been encoded in INTRA-frame mode (i.e. encoded independently of past frames). There are several ways to mitigate packet loss:
H.261は、圧縮を実行するのにビデオの時の冗長を使用します。 この差分符号化(または、INTER-フレームコード化)はパケット損失に敏感です。 パケット損失の後に、INTRA-フレーム方式(すなわち、過去のフレームの如何にかかわらず、コード化される)ですべての対応するMBがコード化されるまで、イメージの部分は不正なままで残るかもしれません。 パケット損失を緩和するいくつかの方法があります:
(1) One way is to use only INTRA-frame encoding and MB level
conditional replenishment. That is, only MBs that change
(beyond some threshold) are transmitted.
(1) 1つの方法はINTRA-フレームコード化とMBの平らな条件付きの補給だけを使用することです。 すなわち、変化する(何らかの敷居を超えて)MBだけが伝えられます。
(2) Another way is to adjust the INTRA-frame encoding
refreshment rate according to the packet loss observed by
the receivers. The H.261 recommendation specifies that a
MB is INTRA-frame encoded at least every 132 times it is
transmitted. However, the INTRA-frame refreshment rate
can be raised in order to speed the recovery when the
measured loss rate is significant.
(2) 別の方法は受信機によって観測されたパケット損失に従って軽い飲食物レートをコード化しながらINTRA-フレームを調整することです。 H.261推薦は、1MBがINTRA-フレームがそれが伝えられるという少なくともあらゆる132回をコード化したということであると指定します。 しかしながら、測定損失率が重要であるときに、回復を促進するためにINTRA-フレーム軽い飲食物レートを上げることができます。
(3) The fastest way to repair a corrupted image is to request
an INTRA-frame coded image refreshment after a packet
loss is detected. One means to accomplish this is for the
(3) 崩壊したイメージを修理する最も速い方法はパケット損失が検出された後にINTRA-フレーム符号化画像軽い飲食物を要求することです。 これを達成する1つの手段がそうです。
Turletti & Huitema Standards Track [Page 7] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[7ページ]。
decoder to send to the coder a list of packets lost. The
coder can decide to encode every MB of every GOB of the
following video frame in INTRA-frame mode (i.e. Full
INTRA-frame encoded), or if the coder can deduce from the
packet sequence numbers which MBs were affected by the
loss, it can save bandwidth by sending only those MBs in
INTRA-frame mode. This mode is particularly efficient in
point-to-point connection or when the number of decoders
is low. The next section specifies how the refresh
function may be implemented.
パケットのリストを符号化器に送るデコーダは損をしました。 符号化器が、INTRA-フレーム方式(すなわち、コード化されたFull INTRA-フレーム)で以下のビデオフレームのあらゆるGOBのあらゆるMBをコード化すると決めることができますか、または符号化器がパケットからそれのMBが損失で影響を受けた一連番号を推論できるなら、それは、INTRA-フレーム方式によるそれらのMBだけを送ることによって、帯域幅を救うことができます。 このモードは指すポイントでの特に有能な接続かデコーダの数がいつ下位であるかということです。 次のセクションはリフレッシュ機能がどう実行されるかもしれないかを指定します。
Note that the method (1) is currently implemented in the VIC videoconferencing software [9]. Methods (2) and (3) are currently implemented in the IVS videoconferencing software [4].
方法(1)が現在VICテレビ会議ソフトウェア[9]で実行されることに注意してください。 方法(2)と(3)は現在、IVSテレビ会議ソフトウェア[4]で実行されます。
5.1. Use of optional H.261-specific control packets
5.1. 任意のH.261特有のコントロールパケットの使用
This specification defines two H.261-specific RTCP control packets, "Full INTRA-frame Request" and "Negative Acknowledgement", described in the next section. Their purpose is to speed up refreshment of the video in those situations where their use is feasible. Support of these H.261-specific control packets by the H.261 sender is optional; in particular, early experiments have shown that the usage of this feature could have very negative effects when the number of sites is very large. Thus, these control packets should be used with caution.
この仕様は「完全なイントラフレーム要求」と「否定的承認」というパケットが次のセクションで説明した2のH.261特有のRTCPコントロールを定義します。 それらの目的は彼らの使用が可能であるそれらの状況でビデオの軽い飲食物を加速することです。 H.261送付者によるこれらのH.261特有のコントロールパケットのサポートは任意です。 特に、早めの実験は、サイトの数が非常に大きいときに、この特徴の用法が非常にマイナスしている効果を持つことができたのを示しました。 したがって、これらのコントロールパケットは慎重に使用されるべきです。
The H.261-specific control packets differ from normal RTCP packets in that they are not transmitted to the normal RTCP destination transport address for the RTP session (which is often a multicast address). Instead, these control packets are sent directly via unicast from the decoder to the coder. The destination port for these control packets is the same port that the coder uses as a source port for transmitting RTP (data) packets. Therefore, these packets may be considered "reverse" control packets.
H.261特有のコントロールパケットはそれらがRTPセッション(しばしばマルチキャストアドレスである)のための正常なRTCP送付先輸送アドレスに伝えられないという点において正常なRTCPパケットと異なっています。 代わりに、直接デコーダから符号化器までのユニキャストでこれらのコントロールパケットを送ります。 これらのコントロールパケットのための仕向港は符号化器がRTP(データ)パケットを伝えるのにソース港として使用する同じポートです。 したがって、これらのパケットは「逆」のコントロールパケットであると考えられるかもしれません。
As a consequence, these control packets may only be used when no RTP mixers or translators intervene in the path from the coder to the decoder. If such intermediate systems do intervene, the address of the coder would no longer be present as the network-level source address in packets received by the decoder, and in fact, it might not be possible for the decoder to send packets directly to the coder.
どんなRTPミキサーも翻訳者も符号化器からデコーダまで経路を干渉しないときだけ、結果として、これらのコントロールパケットは使用されるかもしれません。 そのような中間システムに介入するなら、パケットのネットワークレベルソースアドレスがデコーダのそばで受信されて、事実上、デコーダが直接符号化器にパケットを送るのが、可能でないかもしれないので、符号化器のアドレスはもう存在していないでしょう。
Some reliable multicast protocols use similar NACK control packets transmitted over the normal multicast distribution channel, but they typically use random delays to prevent a NACK implosion problem [2]. The goal of such protocols is to provide reliable multicast packet delivery at the expense of delay, which is appropriate for applications such as a shared whiteboard.
いくつかの信頼できるマルチキャストプロトコルが普通のマルチキャスト販売チャネルの上に伝えられた同様のナックコントロールパケットを使用しますが、それらは、ナック内部破裂問題[2]を防ぐのに無作為の遅れを通常使用します。 そのようなプロトコルの目標は遅れを犠牲にして信頼できるマルチキャストパケット配信を提供することです。共有されたホワイトボードなどのアプリケーションに、遅れは適切です。
Turletti & Huitema Standards Track [Page 8] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[8ページ]。
On the other hand, interactive video transmission is more sensitive to delay and does not require full reliability. For video applications it is more effective to send the NACK control packets as soon as possible, i.e. as soon as a loss is detected, without adding any random delays. In this case, multicasting the NACK control packets would generate useless traffic between receivers since only the coder will use them. But this method is only effective when the number of receivers is small. e.g. in IVS [4] the H.261 specific control packets are used only in point-to-point connections or in point-to-multipoint connections when there are less than 10 participants in the conference.
他方では、双方向テレビトランスミッションは、延着するように、より敏感であり、完全な信頼性を必要としません。 ビデオ・アプリケーションには、できるだけ早くナックコントロールパケットを送るのは、より効果的です、損失が検出されるとすぐにすなわち、、どんな無作為の遅れも加えないで。 この場合、マルチキャスティングナックはパケットを制御します。符号化器だけがそれらを使用するので、受信機の間の無駄な交通を発生させるでしょう。 しかし、受信機の数が少ないときにだけ、この方法は効果的です。会議の10人未満の関係者がいるとき、例えば、IVS[4]では、H.261の特定のコントロールパケットは、指すポイントだけでの中古の接続かマルチポイント接続にポイントです。
5.2. H.261 control packets definition
5.2. H.261コントロールパケット定義
5.2.1. Full INTRA-frame Request (FIR) packet
5.2.1. 完全なINTRA-フレームRequest(FIR)パケット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| MBZ | PT=RTCP_FIR | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| MBZ| PTはRTCP_モミと等しいです。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This packet indicates that a receiver requires a full encoded image in order to either start decoding with an entire image or to refresh its image and speed the recovery after a burst of lost packets. The receiver requests the source to force the next image in full "INTRA- frame" coding mode, i.e. without using differential coding. The various fields are defined in the RTP specification [1]. SSRC is the synchronization source identifier for the sender of this packet. The value of the packet type (PT) identifier is the constant RTCP_FIR (192).
このパケットは、受信機が無くなっているパケットの炸裂の後に全体のイメージで解読し始めるか、イメージをリフレッシュして、または回復を促進するためにいっぱいのコード化されたイメージを必要とするのを示します。 受信機は、完全な「INTRAフレーム」コード化モードによる次のイメージを強制するようソースに要求します、すなわち、差分符号化を使用しないで。 多岐はRTP仕様[1]に基づき定義されます。 SSRCはこのパケットの送付者への同期ソース識別子です。 パケットタイプ(太平洋標準時の)識別子の値は一定のRTCP_FIR(192)です。
5.2.2. Negative ACKnowledgements (NACK) packet
5.2.2. 否定的ACKnowledgements(ナック)パケット
The format of the NACK packet is as follow:
ナックパケットの形式が続くようにあります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| MBZ | PT=RTCP_NACK | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FSN | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| MBZ| PTはRTCP_ナックと等しいです。| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FSN| BLP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Turletti & Huitema Standards Track [Page 9] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[9ページ]。
The various fields T, P, PT, length and SSRC are defined in the RTP specification [1]. The value of the packet type (PT) identifier is the constant RTCP_NACK (193). SSRC is the synchronization source identifier for the sender of this packet.
太平洋標準時の多岐T、P、長さ、およびSSRCはRTP仕様[1]に基づき定義されます。 パケットタイプ(太平洋標準時の)識別子の値は一定のRTCP_ナック(193)です。 SSRCはこのパケットの送付者への同期ソース識別子です。
The two remaining fields have the following meanings:
2つの残っているフィールドには、以下の意味があります:
First Sequence Number (FSN): 16 bits
Identifies the first sequence number lost.
最初に、一連番号(FSN): 最初の一連番号がなくした16ビットのIdentifies。
Bitmask of following lost packets (BLP): 16 bits
A bit is set to 1 if the corresponding packet has been lost,
and set to 0 otherwise. BLP is set to 0 only if no packet
other than that being NACKed (using the FSN field) has been
lost. BLP is set to 0x00001 if the packet corresponding to
the FSN and the following packet have been lost, etc.
無くなっているパケット(BLP)に続くビットマスク: 対応するパケットが別の方法で0に失われていて、設定されたなら、16ビットのAビットは1に設定されます。 それを除いたNACKed(FSN分野を使用する)であるパケットが全く失われていない場合にだけ、BLPは0に用意ができています。 FSNに対応するパケットと以下のパケットが失われていたのなどなら、BLPは0×00001に用意ができています。
6. Security Considerations
6. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Thierry Turletti INRIA - RODEO Project 2004 route des Lucioles BP 93, 06902 Sophia Antipolis FRANCE
ティエリーTurletti INRIA--RODEO Project2004ルートdesルシオールBP93、06902ソフィア・Antipolisフランス
EMail: turletti@sophia.inria.fr
メール: turletti@sophia.inria.fr
Christian Huitema MCC 1J236B Bellcore 445 South Street Morristown, NJ 07960-6438
南通りモリスタウン、クリスチャンのHuitema MCC 1J236B Bellcore445ニュージャージー07960-6438
EMail: huitema@bellcore.com
メール: huitema@bellcore.com
Acknowledgements
承認
This memo is based on discussion within the AVT working group chaired by Stephen Casner. Steve McCanne, Stephen Casner, Ronan Flood, Mark Handley, Van Jacobson, Henning G. Schulzrinne and John Wroclawski provided valuable comments. Stephen Casner and Steve McCanne also helped greatly with getting this document into readable form.
このメモはスティーブンCasnerによってまとめられたAVTワーキンググループの中で議論に基づいています。 スティーブMcCanne、スティーブンCasner、ローナンFlood、マーク・ハンドレー、ヴァン・ジェーコブソン、ヘニングG.Schulzrinne、およびジョンWroclawskiは貴重なコメントを提供しました。 また、スティーブンCasnerとスティーブMcCanneはこのドキュメントを読み込み可能なフォームに手に入れるのに大いに助けました。
Turletti & Huitema Standards Track [Page 10] RFC 2032 RTP Payload Format for H.261 Video October 1996
Turletti&Huitema規格はビデオ1996年10月にH.261のためにRFC2032RTP有効搭載量形式を追跡します[10ページ]。
References
参照
[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] Sridhar Pingali, Don Towsley and James F. Kurose, A
comparison of sender-initiated and receiver-initiated
reliable multicast protocols, IEEE GLOBECOM '94.
送付者によって開始されて受信機で開始している信頼できるマルチキャストプロトコル(IEEE GLOBECOM94年)の[2]Sridhar PingaliとドンTowsleyとジェームスF.黒瀬、A比較。
[3] Thierry Turletti, H.261 software codec for
videoconferencing over the Internet INRIA Research Report
no 1834, January 1993.
[3]ティエリーTurletti、インターネットINRIA Research Reportノー1834、1993年1月の間のテレビ会議のためのH.261ソフトウェアコーデック。
[4] Thierry Turletti, INRIA Videoconferencing tool (IVS),
available by anonymous ftp from zenon.inria.fr in the
"rodeo/ivs/last_version" directory. See also URL
<http://www.inria.fr/rodeo/ivs.html>.
[4]ティエリーTurletti、「ロデオ/ivs/最後の_バージョン」ディレクトリでzenon.inria.frからのアノニマスFTPで利用可能なINRIA Videoconferencingツール(IVS)。 また、URL<http://www.inria.fr/ロデオ/ivs.html>を見てください。
[5] Frame structure for Audiovisual Services for a 64 to 1920
kbps Channel in Audiovisual Services ITU-T (International
Telecommunication Union - Telecommunication
Standardisation Sector) Recommendation H.221, 1990.
[5] Audiovisual Services ITU-T(国際電気通信連合--電気通信Standardisation Sector)推薦H.221、1990年に64のためのAudiovisual Servicesのために1920年のキロビット毎秒Channelに構造を縁どってください。
[6] Video codec for audiovisual services at p x 64 kbit/s
ITU-T (International Telecommunication Union -
Telecommunication Standardisation Sector) Recommendation
H.261, 1993.
[6] p x64kbit/s ITU-T(国際電気通信連合--電気通信Standardisation Sector)推薦H.261、1993での視聴覚のサービスのためのビデオコーデック。
[7] Digital Methods of Transmitting Television Information
ITU-R (International Telecommunication Union -
Radiocommunication Standardisation Sector) Recommendation
601, 1986.
[7] 伝えるテレビの情報ITU-R(国際電気通信連合--無線通信規格化セクター)推薦601、1986のデジタル方式。
[8] M.A Sasse, U. Bilting, C-D Schulz, T. Turletti, Remote
Seminars through MultiMedia Conferencing: Experiences
from the MICE project, Proc. INET'94/JENC5, Prague, June
1994, pp. 251/1-251/8.
[8] M. ザッセ、U.Bilting、C-Dシュルツ、T.Turletti、マルチメディア会議を通したリモートセミナー: Proc、MICEからの経験は突出しています。 JENC5、INET94年/プラハ1994年6月、ページ 251/1-251/8.
[9] Steve MacCanne, Van Jacobson, VIC Videoconferencing tool,
available by anonymous ftp from ee.lbl.gov in the
"conferencing/vic" directory.
[9] スティーブMacCanne、ヴァン・ジェーコブソン、「会議/vic」ディレクトリでee.lbl.govからのアノニマスFTPで利用可能なVIC Videoconferencingツール。
Turletti & Huitema Standards Track [Page 11]
Turletti&Huitema標準化過程[11ページ]
一覧
スポンサーリンク
