RFC4587 日本語訳
4587 RTP Payload Format for H.261 Video Streams. R. Even. August 2006. (Format: TXT=37477 bytes) (Obsoletes RFC2032) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Even Request for Comments: 4587 Polycom Obsoletes: 2032 August 2006 Category: Standards Track
コメントを求めるワーキンググループのR.の同等の要求をネットワークでつないでください: 4587Polycomは以下を時代遅れにします。 2032 2006年8月のカテゴリ: 標準化過程
RTP Payload Format for H.261 Video Streams
H.261ビデオストリームのための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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
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を運ぶ基本的なプロトコルのいずれでも。
The memo also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.
また、メモは記述プロトコル(SDP)パラメタがH.261ビデオコーデックを支持する必要があったSessionの構文と意味論について説明します。メディアタイプ登録はこのペイロード形式のために含まれています。
This specification obsoletes RFC 2032.
この仕様はRFC2032を時代遅れにします。
Even Standards Track [Page 1] RFC 4587 H.261 RTP payload format August 2006
Standards Track[1ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Structure of the Packet Stream ..................................3
3.1. Overview of the ITU-T Recommendation H.261 .................3
3.2. Considerations for Packetization ...........................4
4. Specification of the Packetization Scheme .......................5
4.1. Usage of RTP ...............................................5
4.2. Recommendations for Operation with Hardware Codecs .........8
5. Packet Loss Issues ..............................................9
6. IANA Considerations ............................................10
6.1. Media Type Registrations ..................................10
6.1.1. Registration of MIME Media Type video/H261 .........10
6.2. SDP Parameters ............................................12
6.2.1. Usage with the SDP Offer Answer Model ..............12
7. Backward Compatibility to RFC 2032 .............................13
7.1. Optional H.261-Specific Control Packets ...................13
7.2. New SDP Optional Parameters ...............................13
8. Security Considerations ........................................14
9. Acknowledgements ...............................................14
10. Changes from RFC 2032 .........................................14
11. References ....................................................15
11.1. Normative References .....................................15
11.2. Informative References ...................................15
1. 序論…3 2. 用語…3 3. パケットの流れの構造…3 3.1. ITU-T推薦H.261の概観…3 3.2. Packetizationのための問題…4 4. Packetization計画の仕様…5 4.1. RTPの使用法…5 4.2. ハードウェアコーデックとの操作のための推薦…8 5. パケット損失問題…9 6. IANA問題…10 6.1. メディアは登録証明書をタイプします…10 6.1.1. MIMEメディアタイプビデオ/H261の登録…10 6.2. SDPパラメタ…12 6.2.1. SDP申し出答えモデルがある用法…12 7. RFC2032への後方の互換性…13 7.1. 任意のH.261特有のコントロールパケット…13 7.2. 新しいSDP任意のパラメタ…13 8. セキュリティ問題…14 9. 承認…14 10. RFC2032からの変化…14 11. 参照…15 11.1. 標準の参照…15 11.2. 有益な参照…15
Even Standards Track [Page 2] RFC 4587 H.261 RTP payload format August 2006
Standards Track[2ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
1. Introduction
1. 序論
ITU-T Recommendation H.261 [H261] specifies the encoding used by ITU-T-compliant video-conference codecs. Although this encoding was originally specified for fixed-data rate Integrated Services Digital Network (ISDN) circuits, experiments [INRIA], [MICE] have shown that they can also be used over packet-switched networks, such as the Internet.
ITU-T Recommendation H.261[H261]が使用されていた状態でコード化を指定する、ITU T対応する、テレビ会議コーデック。 このコード化は実験[INRIA]、元々固定データ信号速度Integrated Services Digital Network(ISDN)サーキットに指定されていて、[MICE]はまた、パケット交換網の上でそれらを使用できるのを示しました、インターネットなどのようにことでしたが。
The purpose of this memo is to specify the RTP payload format for encapsulating H.261 video streams in RTP [RFC3550].
このメモの目的はRTP[RFC3550]でH.261ビデオストリームをカプセルに入れるのにRTPペイロード形式を指定することです。
This document obsoletes RFC 2032 and updates the "video/h261" media type that was registered in RFC 3555.
このドキュメントは、RFC2032を時代遅れにして、RFC3555に示された「ビデオ/h261」メディアタイプをアップデートします。
2. Terminology
2. 用語
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] and indicate requirement levels for compliant RTP implementations.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で[RFC2119]について説明して、対応する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 to 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, whereas 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 ITU-R Recommendation 601 [BT601].
H.261コード化は組分けの階層構造として組織化されます。 ビデオストリームはBlocks(GOB)のGroupsの1セットとして組織化されるイメージ、またはフレームの系列で構成されます。 H.261「絵」が本書では「フレーム」と呼ばれることに注意してください。 各GOBは11マクロブロック(MB)の3つの線のセットを持っています。 各MBは16×16画素のグループの情報を運びます: 4ブロックの8×8画素に輝度情報を指定しますが、8×8画素だけの解像度のときに2つの「赤く」て「青い」色差成分で色差情報を与えます。 それらの標本値を表すこれらのコンポーネントとコードがITU-R Recommendation601[BT601]で定義されるようにあります。
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番号とデフォルト数量詞を指定します。
Even Standards Track [Page 3] RFC 4587 H.261 RTP payload format August 2006
Standards Track[3ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
- 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 that 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, which is a word of 16 bits, 0000 0000 0000 0001. This pattern is included at the beginning of 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 zero bits followed by four bits with a value of one; that stuffing pattern can only be entered between the encoding of MBs, or just before the GOB separator.
H.261ハフマン符号化は特別な「GOB始め」パターンを含んでいます。(それは、16ビット(0000 0000 0000 0001)の単語です)。 このパターンは、それぞれのGOBヘッダー(そしてそれぞれのフレームヘッダーの始めにも)の始めに2GOBsの間の分離をマークするために含まれていて、事実上、現在のGOBが終えられるというインディケータとして使用されます。 また、コード化は詰め物のパターンを含んでいます、7ゼロ・ビットを落ち着かせて、1の値に従った4ビットを続いて落ち着かせます。 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 px 64 kbps circuits according to specification H.221 [H221].
ISDNサーキットの上の操作のために設計されたH.261コーデックはH.261と仲間推薦で指定されたいくつかのレベルのコード化で構成された流れを少し起こします。 ハフマン符号化から生じるビットは512ビットのフレームに配置されます、同期の2ビット、492ビットのデータ、および誤り検出方式の18ビットを含んでいて。 仕様H.221[H221]に応じて、512ビットのフレームは、次に、オーディオストリームによって交錯されて、px64キロビット毎秒サーキットの上に送られます。
For 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 suitable 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 hierarchical structure of the 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 decode its components properly.
しかしながら、UDPデータグラムの頼り無いストリームで直接ハフマン符号化の結果を伝えるのにおいて、貧しい誤り抵抗の特性があるでしょう。 H.261ビットストリームの階層構造の結果は人が、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.
単一のパケットで各イメージを運ぶことができるなら、この要件は問題を生じさせないでしょうに。 しかしながら、それ自体でビデオ画像か1GOBさえ時々単一のパケットをうまくはめ込むことができないくらい大きい場合があります。
Even Standards Track [Page 4] RFC 4587 H.261 RTP payload format August 2006
Standards Track[4ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
Therefore, the MB is taken as the unit of fragmentation. Packets must start and end on an MB boundary; that is, an 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.
したがって、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 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 macroblock address (MBA) encoded in the previous packet), the quantizer value in effect prior to the start of this packet (GQUANT, MQUANT, or zero in the 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.
各パケットがパケット損失の面前で効率的な再同期のために独自に処理されるのを許容するために、フレームヘッダーとGOBヘッダーからの何らかの州の情報が各パケットで運ばれて、そのパケットのMBが解読されるのを許容します。 事実上、この州の情報はパケット(事実上、(すなわち、アドレス(MBA)が前のパケットでコード化した最後のmacroblock)、量子化器がこのパケット(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 3-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の使用法
Each RTP packet starts with a fixed RTP header, as explained in RFC 3550 [RFC3550]. The following fields of the RTP fixed header used for H.261 video streams are further emphasized here:
それぞれのRTPパケットはRFC3550[RFC3550]で説明されるように固定RTPヘッダーから始めます。 H.261ビデオストリームに使用されるヘッダーに固定されたRTPの以下の分野はここでさらに強調されます:
- Payload type. The assignment of an RTP payload type for this
packet format is outside the scope of this document and will not be
specified here. It is expected that the RTP profile for a
particular class of applications will assign a payload type for
this encoding, or, if that is not done, then a payload type in the
dynamic range shall be chosen.
- 有効搭載量タイプ。 このパケット・フォーマットのためのRTPペイロードタイプの課題は、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 特定のクラスのアプリケーションのためのRTPプロフィールがこのコード化のためのペイロードタイプを選任すると予想されるものとするか、またはそれが完了していないなら、ダイナミックレンジにおけるペイロードタイプは選ばれるものとします。
- 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 SHALL be the same on all of
those packets. Packets from different video images MUST have a
different timestamp so that frames may be distinguished by the
timestamp. For H.261 video streams, the RTP timestamp is based on
a 90-kHz clock. This clock rate is a multiple of the natural H.261
frame rate (i.e., 30000/1001 or approximately 29.97 Hz). That way,
- RTPタイムスタンプはRTPデータ・パケットに含まれた最初のビデオ画像の標本抽出の瞬間をコード化します。 ビデオ画像は1つ以上のパケット、タイムスタンプSHALLを占領します。それらのパケットのすべてで同じであってください。 異なったビデオ画像からのパケットには、異なったタイムスタンプが、タイムスタンプがフレームを区別できるように、なければなりません。 H.261ビデオストリームにおいて、RTPタイムスタンプは90kHzの時計に基づいています。 このクロックレートは自然なH.261フレームレート(すなわち、30000/1001Hzかおよそ29.97Hz)の倍数です。 そのように
Even Standards Track [Page 5] RFC 4587 H.261 RTP payload format August 2006
Standards Track[5ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
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 MUST be random
(unpredictable) to make known-plaintext attacks on encryption more
difficult; see RTP [RFC3550]. Note that if multiple frames are
encoded in a packet (e.g., when there are very few 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[RFC3550]を見てください。 複数のフレームがパケットでコード化されるなら(例えば、いつ、2つのイメージの間には、ほんのわずかな変化がありますか)、1日以降表示時間についてフレームに計算するのが必要であることに注意してください、H.261フレームヘッダーでタイミング情報を使用して。 RTPタイムスタンプがパケットの最初のフレームの表示時間を与えるだけであるので、これが必要です。
- The marker bit of the RTP header MUST be set to one in the last
packet of a video frame; otherwise, it MUST be 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.
- ビデオフレームの最後のパケットの1つにRTPヘッダーのマーカービットを設定しなければなりません。 さもなければ、それはゼロであるに違いありません。 したがって、検出する次のパケット(現在のフレームを終えるスタートコードを含む)を待つために、新しいフレームを表示するのは必要ではありません。
The H.261 data SHALL follow the RTP header, as in the following:
H.261データSHALLは以下のように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 follows:
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
スタートビット位置の(SBIT): 3ビット
Number of most significant bits that should be ignored in the
first data octet.
最初のデータ八重奏で無視されるべきである最上位ビットの数。
Even Standards Track [Page 6] RFC 4587 H.261 RTP payload format August 2006
Standards Track[6ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
End bit position (EBIT): 3 bits
ビット位置(EBIT)を終わらせてください: 3ビット
Number of least significant bits that should be ignored in the
last data octet.
最後のデータ八重奏で無視されるべきである最下位ビットの数。
INTRA-frame encoded data (I): 1 bit
INTRA-フレームはデータ(I)をコード化しました: 1ビット
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 meaning of this bit should not be changed during the
course of the RTP session.
この流れがINTRA-フレームコード化されたブロックだけを含むなら、1にセットしてください。 この流れがINTRA-フレームコード化されたブロックを含むかもしれないなら、0にセットしてください。 RTPセッションのコースの間、このビットの意味を変えるべきではありません。
Motion Vector flag (V): 1 bit
動きVectorは(V)に旗を揚げさせます: 1ビット
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
meaning of this bit should not be changed during the course of the
session.
運動ベクトルがこの流れに使用されないなら、0にセットしてください。 運動ベクトルがこの流れに使用されるかもしれないなら、1にセットしてください。 セッションのコースの間、このビットの意味を変えるべきではありません。
GOB number (GOBN): 4 bits
GOB番号(GOBN): 4ビット
Encodes the GOB number in effect at the start of the packet. Set
to 0 if the packet begins with a GOB header.
事実上、パケットの始めでGOB番号をコード化します。 パケットがGOBヘッダーと共に始まるなら、0にセットしてください。
Macroblock address predictor (MBAP): 5 bits
Macroblockは予言者(MBAP)を記述します: 5ビット
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 shall not 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アドレス予言者(すなわち、前のパケットでコード化された最後のMBA)をコード化します。 この予言者は0--32(1--有効なMBAs33を予測する)から変化しますが、GOBヘッダーとMB1の間でビットストリームを断片化できないので、パケットの始めの予言者は0歳にならないでしょう。 したがって、範囲は1--32です。(その32は、5ビット適合するように-1偏られます)。 例えば、MBAPが0歳であるなら、MBA予言者の値は1です。 パケットがGOBヘッダーと共に始まるなら、0にセットしてください。
Quantizer (QUANT): 5 bits
量子化器(舟棹): 5ビット
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.
事実上、量子化器はこのパケットの始まりの前に(MQUANTかGQUANT)を評価します。 パケットがGOBヘッダーと共に始まるなら、0にセットしてください。
Horizontal motion vector data (HMVD): 5 bits
水平動ベクトルデータ(HMVD): 5ビット
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 motion
compensation (MC). HMVD is encoded as a 2s complement number, and
'10000' corresponding to the value -16 is forbidden (motion vector
fields range from +/-15).
参照水平動ベクトルデータ(MVD)。 V旗が0であるかパケットがGOBヘッダーと共に始まるか、または前のパケットでコード化された最後のMBのMTYPEが動き補償(M.C.)でなかったときに、0にセットしてください。 値-16に対応する2補数数、および'10000'が禁じられるとき(動きベクトル場は+/-15から変化します)、HMVDはコード化されます。
Even Standards Track [Page 7] RFC 4587 H.261 RTP payload format August 2006
Standards Track[7ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
Vertical motion vector data (VMVD): 5 bits
上下動ベクトルデータ(VMVD): 5ビット
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 2s complement number, and '10000' corresponding to
the value -16 SHALL not be used (motion vector fields range from
+/-15).
参照上下動ベクトルデータ(MVD)。 V旗が0であるかパケットがGOBヘッダーと共に始まるか、または前のパケットでコード化された最後のMBのMTYPEがM.C.でなかったときに、0にセットしてください。 VMVDは2補数番号、および値に対応する'10000'-16SHALLとしてコード化されます。使用されないでください(+/-15からの運動ベクトル分野の範囲)。
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 the bit stream was decoded. Therefore, these bits cannot change for the duration of the stream. A conforming implementation can always set V=1 and I=0.
IとV旗がヒント旗であることに注意してください。 ビットストリームからすなわち、それらを推論できます。 それらは、デコーダがビットストリームが解読される前にこれらのヒントが提供されないなら可能でない最適化をするのを許容するために含まれています。 したがって、これらのビットは流れの持続時間のために変化できません。 従う実現はいつもV=1とI=0を設定できます。
The H.261 stream SHALL be used without BCH error correction and without error correction framing.
H.261流れのSHALLはBCHエラー修正なしで使用されて、エラー修正縁どっています。
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 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 decompress the stream fully, so this requires relatively little processing; examples of implementations can be found in some public H.261 codecs, such as IVS [IVS] and VIC [VIC].) 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.
H.261データに含まれていたGOB-スタートパターンを使用して、ハードウェアコーデックのためのPacketizersはGOB境界を些細なことに理解できます。 (ソフトウェアエンコーダが既に境界を知ることに注意してください。) 最も安いpacketization実現はGOBレベルでパケットをうまくはめ込むすべてのGOBsをpacketizeすることです。 しかし、GOBが大き過ぎるときに、packetizerは、MB断片化をするためにそれを分析しなければなりません。 (これが比較的小さい処理を必要とするように、ハフマン符号化だけを分析しなければならなくて、流れを完全に減圧するのは必要でないことに注意してください; いくつかの公共のH.261コーデックで実現に関する例を見つけることができます、IVS[IVS]やVIC[VIC]のように。) 可能であるときに、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(すなわち、パケットの間の)の間に詰め物のパターンを挿入することによって、維持されるかもしれません。
Even Standards Track [Page 8] RFC 4587 H.261 RTP payload format August 2006
Standards Track[8ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
5. Packet Loss Issues
5. パケット損失問題
On the Internet, most packet losses are due to network congestion rather than to transmission errors. Using UDP, no mechanism is available at the sender to know whether 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 sequence number field that can be used to detect packet loss.
インターネットに、ほとんどのパケット損失が伝送エラーにというよりむしろネットワークの混雑のためにあります。 UDPを使用して、どんなメカニズムも首尾よくパケットを受け取ったか否かに関係なく、知る送付者で利用可能ではありません。 パケット損失を扱うのはアプリケーション(すなわち、符号化器とデコーダ)まで達しています。 それぞれのRTPパケットはパケット損失を検出するのに使用できる一連番号分野を含んでいます。
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 an MB be 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 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). 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.
(3) 崩壊したイメージを修理する最も速い方法はパケット損失が検出された後にINTRA-フレーム符号化画像軽い飲食物を要求することです。 これを達成する1つの手段はデコーダがパケットのリストが失った符号化器に発信することです。 符号化器は、INTRA-フレーム方式(すなわち、コード化された完全なINTRA-フレーム)で以下のビデオフレームのあらゆるGOBのあらゆるMBをコード化すると決めることができます。 符号化器がパケットからそれのMBが損失で影響を受けた一連番号を推論できるなら、それは、INTRA-フレーム方式によるそれらのMBだけを送ることによって、帯域幅を救うことができます。 このモードは指すポイントでの特に有能な接続かデコーダの数がいつ下位であるかということです。
The H.261-specific control packets FIR and NACK, as described in RFC 2032, SHALL NOT be used to request image refreshment. Old implementations are encouraged to use the methods described in this section. Image refreshment may be needed due to packet loss or due to application requirements. An example of application requirement may be the change of the speaker in a voice-activated multipoint video switching conference. There are two methods that can be used for requesting image refreshment. The first method is by using the Extended RTP Profile for RTCP-based Feedback and sending RTCP generic
SHALL NOT、H.261特有はRFC2032で説明されるようにパケットのFIRとナックを監督します。イメージ軽い飲食物を要求するのが使用されます。 古い実現がこのセクションで説明された方法を使用するよう奨励されます。 イメージ軽い飲食物がパケット損失のためかアプリケーション要件のため必要であるかもしれません。 アプリケーション要件に関する例は音声操作の多点ビデオ切り換え会議で、スピーカーの変化であるかもしれません。 イメージ軽い飲食物を要求するのに使用できる2つの方法があります。 RTCPベースのFeedbackにExtended RTP Profileを使用して、最初の方法はRTCPジェネリックを送ることです。
Even Standards Track [Page 9] RFC 4587 H.261 RTP payload format August 2006
Standards Track[9ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
control packets, as described in RFC 4585 [RFC4585]. The second method is by using application protocol-specific commands, such as H.245 [ITU.H245] FastUpdateRequest.
RFC4585[RFC4585]で説明されるようにパケットを制御してください。 2番目の方法はH.245[ITU.H245]FastUpdateRequestなどのアプリケーションのプロトコル特有の命令を使用することです。
6. IANA Considerations
6. IANA問題
This section updates the H.261 media type described in RFC 3555 [RFC3555].
このセクションはRFC3555[RFC3555]で説明されたH.261メディアタイプをアップデートします。
This section specifies optional parameters that MAY be used to select optional features of the payload format. The parameters are specified here as part of the MIME subtype registration for the ITU-T H.261 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for those applications that use SDP. Multiple parameters SHOULD be expressed as a media type string, in the form of a semicolon-separated list of parameters.
このセクションはペイロード形式に関するオプション機能を選択するのに使用されるかもしれない任意のパラメタを指定します。 ITU-T H.261コーデックのためのMIME「副-タイプ」登録の一部としてここでパラメタを指定します。また、Session記述プロトコル(SDP)[RFC4566]へのパラメタに関するマッピングをSDPを使用するそれらのアプリケーションに提供します。 aメディアがストリングをタイプするので複数のパラメタSHOULDが急送されて、aの形では、パラメタのリストはセミコロンで分離していました。
6.1. Media Type Registrations
6.1. メディアは登録証明書をタイプします。
This section describes the media types and names associated with this payload format. The section updates the previous registered version in RFC 3555 [RFC3555]. This registration uses the template defined in RFC 4288 [RFC4288]
このセクションはこのペイロード形式に関連しているメディアタイプと名前について説明します。 セクションはRFC3555[RFC3555]の前の登録済みのバージョンをアップデートします。 この登録はRFC4288で定義されたテンプレートを使用します。[RFC4288]
6.1.1. Registration of MIME Media Type video/H261
6.1.1. MIMEメディアタイプビデオ/H261の登録
MIME media type name: video
MIMEメディア型名: ビデオ
MIME subtype name: H261
MIME「副-タイプ」は以下を命名します。 H261
Required parameters: None
必要なパラメタ: なし
Optional parameters:
任意のパラメタ:
CIF. This parameter has the format of parameter=value. It
describes the maximum supported frame rate for CIF resolution.
Permissible values are integer values 1 to 4, and it means that
the maximum rate is 29.97/specified value.
CIF。 このパラメタには、パラメタ=価値の形式があります。 それはCIF解決の最大の支持されたフレーム速度について説明します。 許容値は1〜4に整数値です、そして、それは最高率が29.97/規定値であることを意味します。
QCIF. This parameter has the format of parameter=value. It
describes the maximum supported frame rate for QCIF resolution.
Permissible values are integer values 1 to 4, and it means that
the maximum rate is 29.97/specified value.
QCIF。 このパラメタには、パラメタ=価値の形式があります。 それはQCIF解決の最大の支持されたフレーム速度について説明します。 許容値は1〜4に整数値です、そして、それは最高率が29.97/規定値であることを意味します。
Even Standards Track [Page 10] RFC 4587 H.261 RTP payload format August 2006
Standards Track[10ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
D. Specifies support for still image graphics according to H.261,
annex D. If supported, the parameter value SHALL be "1". If not
supported, the parameter SHOULD NOT be used or SHALL have the
value "0".
H.261、Ifが支えた別館D.、パラメタ価値のSHALLによると、D.は静止画像グラフィックスのサポートを指定します。「1インチ」ということになってください。 支持される、パラメタSHOULD、使用されないでください。さもないと、SHALLには値「0インチ」があります。
Encoding considerations:
問題をコード化します:
This media type is framed and binary, see Section 4.8 in
[RFC4288].
セクション4.8は、[RFC4288]でこのメディアタイプが縁どられて2進であることを見ます。
Security considerations: See Section 8
セキュリティ問題: セクション8を見てください。
Interoperability considerations:
相互運用性問題:
These are receiver options; current implementations will not send
any optional parameters in their SDP. They will ignore the
optional parameters and will encode the H.261 stream without annex
D. Most decoders support at least QCIF resolutions, and they are
expected to be available in almost every H.261-based video
application.
これらは受信機オプションです。 現在の実現はそれらのSDPのどんな任意のパラメタも送らないでしょう。 彼らは、任意のパラメタを無視して、別館D.なしでH.261の流れをコード化するでしょう。Mostデコーダは少なくともQCIF解決を支持します、そして、ほとんどあらゆるH.261ベースのビデオ・アプリケーションで利用可能であると予想されます。
Published specification: RFC 4587
広められた仕様: RFC4587
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
Audio and video streaming and conferencing applications.
オーディオ、ビデオ・ストリーミング、および会議アプリケーション。
Additional information: None
追加情報: なし
Person and email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
Roni Even: roni.even@polycom.co.il
ロニ、同等: roni.even@polycom.co.il
Intended usage: COMMON
意図している用法: 一般的
Restrictions on usage:
用法における制限:
This media type depends on RTP framing and thus is only defined
for transfer via RTP [RFC3550]. Transport within other framing
protocols is not defined at this time.
このメディアタイプは、RTP縁どりによって、その結果、転送のためにRTP[RFC3550]を通して定義されるだけです。 他の縁どりプロトコルの中の輸送はこのとき、定義されません。
Author: Roni Even
以下を書いてください。 ロニ、同等
Change controller:
コントローラを変えてください:
IETF Audio/Video Transport working group, delegated from the IESG.
IESGから代表として派遣されたIETF Audio/ビデオTransportワーキンググループ。
Even Standards Track [Page 11] RFC 4587 H.261 RTP payload format August 2006
Standards Track[11ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
6.2. SDP Parameters
6.2. SDPパラメタ
The MIME media type video/H261 string is mapped to fields in the Session Description Protocol (SDP) as follows:
メディアタイプビデオ/H261が結ぶMIMEは以下のSession記述プロトコル(SDP)の分野に写像されます:
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 H261 (the
MIME subtype).
o コード化はH261が(MIME「副-タイプ」)であったなら"a=rtpmap"でSDP MUSTの台詞を命名します。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o "a=rtpmap"線におけるクロックレートは90000であるに違いありません。
o The optional parameters "CIF", "QCIF", and "D", if any, SHALL be
included in the "a=fmtp" line of SDP. These parameters are
expressed as a MIME media type string, in the form of as a
semicolon-separated list of parameters
o 任意のパラメタもしあれば"CIF"、"QCIF"、および「D」はSDPの"a=fmtp"線に含まれているものとします。 これらのパラメタはメディアがパラメタのセミコロンで切り離されたリストとしてフォームでのストリングをタイプするMIMEとして言い表されます。
6.2.1. Usage with the SDP Offer Answer Model
6.2.1. SDP申し出答えモデルがある用法
When H.261 is offered over RTP using SDP in an Offer/Answer model [RFC3264] the following considerations are necessary.
Offer/答えモデル[RFC3264]でSDPを使用することでRTPの上にH.261を提供するとき、以下の問題が必要です。
Codec options: (D) This option MUST NOT appear unless the sender of this SDP message is able to decode this option. This option SHALL be considered a receiver's capability even when it is sent in a "sendonly" offer.
コーデックオプション: (D) このSDPメッセージの送付者がこのオプションを解読できないなら、このオプションは現れてはいけません。 "sendonly"申し出でそれを送るときさえ、これは考えられた受信機のaものが能力であったならSHALLにゆだねます。
Picture sizes and MPI:
サイズとMPIについて描写してください:
Supported picture sizes and their corresponding minimum picture interval (MPI) information for H.261 can be combined. All picture sizes may be advertised to the other party, or only a subset of it. Using the recvonly or sendrev direction attribute, a terminal SHOULD announce those picture sizes (with their MPIs) that it is willing to receive. For example, CIF=2 means that receiver can receive a CIF picture and that the frame rate SHALL be less then 15 frames per second.
支持された絵のサイズとH.261のためのそれらの対応する最小の絵の間隔(MPI)情報を結合できます。 他のパーティー、またはそれの部分集合だけにすべての絵のサイズの広告を出すかもしれません。 recvonlyかsendrev指示属性を使用する端末のSHOULDがそれが受けても構わないと思っているそれらの絵のサイズ(それらのMPIsと)を発表します。 例えば、CIF=2は受信機がCIFの絵を受けることができて、フレームレートSHALLが1秒あたり当時の、より少ない15個のフレームであることを意味します。
When the direction attribute is sendonly, the parameters describe the capabilities of the stream that the sender can produce.
指示属性がsendonlyなときに、パラメタは送付者が起こすことができる流れの能力について説明します。
Implementations following this specification SHALL specify at least one supported picture size.
この仕様SHALLに続く実現が少なくとも1つの支持された絵のサイズを指定します。
If the receiver does not specify the picture size/MPI parameter, then it is safe to assume that it is an implementation that follows RFC 2032. In that case, it is RECOMMENDED to assume that such a receiver is able to support reception of QCIF resolution with MPI=1.
受信機が絵のサイズ/MPIパラメタを指定しないなら、それがRFC2032に続く実現であると仮定するのは安全です。 その場合、それはそのような受信機がMPI=1とのQCIF解決のレセプションを支持できると仮定するRECOMMENDEDです。
Even Standards Track [Page 12] RFC 4587 H.261 RTP payload format August 2006
Standards Track[12ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
Parameters offered first are the most preferred picture mode to be received.
最初に提供されたパラメタは受け取られるべき最も都合のよい絵のモードです。
An example of media representation in SDP is as follows CIF at 15 frames per second, QCIF at 30 frames per second and annex D
SDPのメディア表現に関する例は、15個のフレームの1秒あたりの以下の通りのCIFと、30個のフレームの1秒あたりのQCIFと別館Dです。
m=video 49170/2 RTP/AVP 31
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=2;QCIF=1;D=1
ビデオ49170/2RTP/AVP31m=a=rtpmap: 31H261/90000 a=fmtp: 31CIF=2; QCIF=1; D=1
This means that the sender of this message can decode an H.261 bit stream with the following options and parameters: preferred resolution is CIF (its MPI is 2), but if that is not possible, then QCIF size is also supported. Still image using annex D MAY be used.
これは、このメッセージの送付者が以下のオプションとパラメタがあるH.261ビットストリームを解読できることを意味します: 都合のよい解決はCIF(MPIは2歳である)ですが、それが可能でないなら、また、QCIFサイズは支持されます。 別館Dを使用する静止画像は使用されるかもしれません。
7. Backward Compatibility to RFC 2032
7. RFC2032への後方の互換性
The current document replaces RFC 2032. This section will address the major backward compatibility issues.
現在のドキュメントはRFC2032を取り替えます。 このセクションは主要な後方の互換性の問題を記述するでしょう。
7.1. Optional H.261-Specific Control Packets
7.1. 任意のH.261特有のコントロールパケット
RFC 2032 defined two H.261-specific RTCP control packets, "Full INTRA-frame Request" and "Negative Acknowledgement". Support of these control packets was optional. 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 encoder. The destination port for these control packets is the same port that the encoder uses as a source port for transmitting RTP (data) packets. Therefore, these packets may be considered "reverse" control packets. This memo suggests generic methods to address the same requirement. The authors of the documents are not aware of products that support these control packets. Since these are optional features, new implementations SHALL ignore them, and they SHALL NOT be used by new implementations.
2つのRFC2032の定義されたH.261特有のRTCPコントロールパケット、「完全なイントラフレーム要求」、および「否定的承認。」 これらのコントロールパケットのサポートは任意でした。 H.261特有のコントロールパケットはそれらがRTPセッション(しばしばマルチキャストアドレスである)のための正常なRTCP送付先輸送アドレスに伝えられないという点において正常なRTCPパケットと異なっています。 代わりに、直接デコーダからエンコーダまでのユニキャストでこれらのコントロールパケットを送ります。 これらのコントロールパケットのための仕向港はエンコーダがRTP(データ)パケットを伝えるのにソース港として使用する同じポートです。 したがって、これらのパケットは「逆」のコントロールパケットであると考えられるかもしれません。 このメモは同じ要件を記述する一般的方法を示します。 ドキュメントの作者はこれらのコントロールパケットを支持する製品を意識していません。 これら、オプション機能、SHALLが無視する新しい実現がそれらと、それらである、SHALL NOT、新しい実現で、使用されてください。
7.2. New SDP Optional Parameters
7.2. 新しいSDP任意のパラメタ
The document adds new optional parameters to the H261 payload type. Since these are optional parameters, we expect that old implementations ignore these parameters, whereas new implementations that receive the H261 payload type capabilities with no parameters will assume that it is an old implementation and will send H.261 at QCIF resolution and 30 frames per second.
ドキュメントは新しい任意のパラメタをH261ペイロードタイプに追加します。 これらが任意のパラメタであるので、私たちは、古い実現がパラメタなしでH261ペイロードタイプ能力を受ける新しい実現が、それが古い実現であると仮定しますが、これらのパラメタを無視して、QCIF解決と30個のフレームの1秒あたりのH.261を送ると予想します。
Even Standards Track [Page 13] RFC 4587 H.261 RTP payload format August 2006
Standards Track[13ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
8. Security Considerations
8. セキュリティ問題
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 appropriate RTP profile (e.g., [RFC3551]). This implies that confidentiality of the media streams is achieved by encryption. SRTP [RFC3711] may be used to provide both encryption and integrity protection of RTP flow. Because the data compression used with this payload format is applied end to end, encryption will be performed after compression, so there is no conflict between the two operations.
この仕様に基づき定義されたペイロード書式を使用するRTPパケットはRTP仕様[RFC3550]、およびどんな適切なRTPプロフィール(例えば、[RFC3551])でも議論したセキュリティ問題を受けることがあります。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 SRTP[RFC3711]は、暗号化とRTP流動の保全保護の両方を提供するのに使用されるかもしれません。 このペイロード形式と共に使用されるデータ圧縮が終わらせる適用された終わりであるので、暗号化が圧縮の後に実行されるので、2つの操作の間には、闘争が全くありません。
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver to be overloaded. The usage of authentication of at least the RTP packet is RECOMMENDED. H.261 is vulnerable to such attacks because it is possible for an attacker to generate RTP packets containing frames that affect the decoding process of future frames. Therefore, the usage of data origin authentication and data integrity protection of at least the RTP packet is RECOMMENDED; for example, with SRTP.
潜在的サービスの否定の脅威は、zデータの符号化のために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者は、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機を積みすぎさせることができます。 少なくともRTPパケットの認証の用法はRECOMMENDEDです。 攻撃者が将来のフレームの解読過程に影響するフレームを含むRTPパケットを発生させるのが、可能であるので、H.261はそのような攻撃に傷つきやすいです。 したがって、データ起源認証の用法と少なくともRTPパケットのデータ保全保護はRECOMMENDEDです。 例えばSRTPと共に。
Note that the appropriate mechanism to ensure confidentiality and integrity of RTP packets and their payloads is very dependent on the application and on the transport and signaling protocols employed. Thus, although SRTP is given as an example above, other possible choices exist.
RTPパケットとそれらのペイロードの秘密性と保全を確実にする適切な手段がアプリケーションと、そして、輸送と使われたシグナリングプロトコルに非常に依存していることに注意してください。 したがって、例としてSRTPを上に与えますが、他の可能な選択は存在しています。
9. Acknowledgements
9. 承認
This is to acknowledge the authors of RFC 2032, Thierry Turletti and Christian Huitema. Special thanks for the work done by Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped with drafting the text for the new MIME types.
これは、RFC2032、ティエリーTurletti、およびクリスチャンのHuitemaの作者を承認するためのものです。 ペトリKoskelainenによってノキアとNermeenイスマイルからシスコから行われた仕事の特別な感謝。シスコは、新しいMIMEの種類のためにテキストを作成するのに助けました。
10. Changes from RFC 2032
10. RFC2032からの変化
The changes from the RFC 2032 are:
RFC2032からの変化は以下の通りです。
1. The H.261 MIME type is now in the payload specification.
1. H.261MIMEの種類が現在、ペイロード仕様にあります。
2. Added optional parameters to the H.261 MIME type
2. H.261MIMEの種類への付記された任意のパラメタ
3. Deprecated the H.261 specific control packets
3. 非難されて、H.261詳細はパケットを制御します。
4. Editorial changes to be in line with RFC editing procedures
4. 手順を編集するRFCに沿ってある編集の変化
Even Standards Track [Page 14] RFC 4587 H.261 RTP payload format August 2006
Standards Track[14ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[H261] International Telecommunications Union, "Video codec for
audiovisual services at px 64 kbit/s", ITU Recommendation
H.261, March 1993.
[H261]国際Telecommunications Union、「px64kbit/sでの視聴覚のサービスのためのビデオコーデック」、ITU Recommendation H.261、1993年3月。
[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月。
[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月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65,
RFC 3551, July 2003.
[RFC3551] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[RFC3555] CasnerとS.とP.Hoschka、「RTP有効搭載量形式のMIMEの種類登録」、RFC3555、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
11.2. Informative References
11.2. 有益な参照
[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月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
Rey, "Extended RTP Profile for Real-time Transport
Control Protocol (RTCP)-based Feedback (RTP/AVPF)", RFC
4585, July 2006.
[RFC4585]オット、J.、ウェンガー、S.、佐藤、N.、バーマイスター、C.、およびJ.レイは「リアルタイムの輸送制御プロトコル(RTCP)ベースのフィードバック(RTP/AVPF)のためにRTPプロフィールを広げました」、RFC4585、2006年7月。
[ITU.H245] International Telecommunications Union, "CONTROL PROTOCOL
FOR MULTIMEDIA COMMUNICATION", ITU Recommendation H.245,
2003.
[ITU.H245]国際電気通信組合、「マルチメディア通信のための制御プロトコル」、ITU推薦H.245、2003。
[INRIA] Turletti, T., "H.261 software codec for videoconferencing
over the Internet", INRIA Research Report 1834,
January 1993.
[INRIA] Turletti、T.、「インターネットの上のテレビ会議のためのH.261ソフトウェアコーデック」、INRIA Research Report1834、1993年1月。
Even Standards Track [Page 15] RFC 4587 H.261 RTP payload format August 2006
Standards Track[15ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
[IVS] Turletti, T., "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>.
[IVS]Turletti、T.、「ロデオ/ivs/最後の_バージョン」ディレクトリでzenon.inria.frからのアノニマスFTPで利用可能な「INRIA Videoconferencingツール(IVS)。」 また、URL<http://www.inria.fr/ロデオ/ivs.html>を見てください。
[BT601] International Telecommunications Union, "Studio encoding
parameters of digital television for standard 4:3 and
wide-screen 16:9 aspect ratios", ITU-R Recommendation
BT.601-5, October 1995.
[BT601]国際Telecommunications Union、「標準の4:3とワイドスクリーン16:9アスペクトレシオのためにデジタル・テレビのパラメタをコード化するスタジオ」、ITU-R Recommendation BT.601-5(1995年10月)。
[MICE] Sasse, MA., Bilting, U., Schultz, CD., and T. Turletti,
"Remote Seminars through MultiMedia Conferencing:
Experiences from the MICE project", Proc. INET'94/JENC5,
Prague pp. 251/1-251/8, June 1994.
[ネズミ] ザッセ(MA)、CD Bilting、U.、シュルツ、T.Turletti、「マルチメディア会議を通したリモートセミナー:」 「MICEプロジェクトからの経験」、Proc。 INET JENC5、94年/プラハのページ 251/1-251/8と、1994年6月。
[VIC] MacCanne, S., "VIC Videoconferencing tool, available by
anonymous ftp from ee.lbl.gov in the "conferencing/vic"
directory".
[VIC] MacCanne、S.、「「会議/vic」ディレクトリでee.lbl.govからのアノニマスFTPで利用可能なVIC Videoconferencingツール。」
[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行進。
[H221] International Telecommunications Union, "Frame structure
for a 64 to 1920 kbit/s channel in audiovisual
teleservices", ITU Recommendation H.221, May 1999.
[H221]国際Telecommunications Union、「64〜1920kbit/sチャンネルのために視聴覚の遠隔サービスで構造を縁どってください」、ITU Recommendation H.221、1999年5月。
Author's Address
作者のアドレス
Roni Even Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
ロニ同等のPolycom94DerechイエムHamoshavot Petach Tikva49130イスラエル
EMail: roni.even@polycom.co.il
メール: roni.even@polycom.co.il
Even Standards Track [Page 16] RFC 4587 H.261 RTP payload format August 2006
Standards Track[16ページ]RFC4587H.261 RTPペイロード形式2006年8月さえ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Even Standards Track [Page 17]
標準化過程さえ[17ページ]
一覧
スポンサーリンク
