[要約] RFC 4629は、ITU-T Rec. H.263ビデオのRTPペイロード形式に関する仕様です。このRFCの目的は、H.263ビデオをRTPパケットにエンコードするための標準的な方法を提供することです。
Network Working Group J. Ott
Request for Comments: 4629 Helsinki University of Technology
Obsoletes: 2429 C. Bormann
Updates: 3555 Universitaet Bremen TZI
Category: Standards Track G. Sullivan
Microsoft
S. Wenger
Nokia
R. Even, Ed.
Polycom
January 2007
RTP Payload Format for ITU-T Rec. H.263 Video
ITU-T Rec。のRTPペイロード形式H.263ビデオ
Status of This Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
Abstract
概要
This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.
このドキュメントでは、リアルタイム転送プロトコル（RTP）を使用し、RTPを伝送する基本プロトコルのいずれかを使用して、転送用のH.263ビデオストリームをパケット化する方式について説明します。
The document also describes the syntax and semantics of the Session Description Protocol (SDP) parameters needed to support the H.263 video codec.
また、H.263ビデオコーデックをサポートするために必要なセッション記述プロトコル（SDP）パラメータの構文とセマンティクスについても説明します。
The document obsoletes RFC 2429 and updates the H263-1998 and H263-2000 media type in RFC 3555.
このドキュメントはRFC 2429を廃止し、RFC 3555のH263-1998およびH263-2000メディアタイプを更新します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. New H.263 Features ..............................................3
3. Usage of RTP ....................................................4
3.1. RTP Header Usage ...........................................5
3.2. Video Packet Structure .....................................6
4. Design Considerations ...........................................7
5. H.263+ Payload Header ...........................................9
5.1. General H.263+ Payload Header ..............................9
5.2. Video Redundancy Coding Header Extension ..................10
6. Packetization Schemes ..........................................12
6.1. Picture Segment Packets and Sequence Ending
Packets (P=1) .............................................12
6.1.1. Packets that begin with a Picture Start Code .......12
6.1.2. Packets that begin with GBSC or SSC ................13
6.1.3. Packets that begin with an EOS or EOSBS Code .......14
6.2. Encapsulating Follow-on Packet (P=0) ......................15
7. Use of this Payload Specification ..............................15
8. Media Type Definition ..........................................17
8.1. Media Type Registrations ..................................17
8.1.1. Registration of Media Type video/H263-1998 .........17
8.1.2. Registration of Media Type video/H263-2000 .........21
8.2. SDP Usage .................................................22
8.2.1. Usage with the SDP Offer Answer Model ..............23
9. Backward Compatibility to RFC 2429 .............................25
9.1. New Optional Parameters for SDP ...........................25
10. IANA Considerations ...........................................25
11. Security Considerations .......................................25
12. Acknowledgments ...............................................26
13. Changes from Previous Versions of the Documents ...............26
13.1. Changes from RFC 2429 ....................................26
13.2. Changes from RFC 3555 ....................................26
14. References ....................................................26
14.1. Normative References .....................................26
14.2. Informative References ...................................27
This document specifies an RTP payload header format applicable to the transmission of video streams based on the 1998 and 2000 versions of International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) Recommendation H.263 [H263]. Because the 1998 and 2000 versions of H.263 are a superset of the 1996 syntax, this format can also be used with the 1996 version of H.263 and is recommended for this use by new implementations. This format replaces the payload format in RFC 2190 [RFC2190], which continues to be used by some existing implementations, and can be useful for backward compatibility. New implementations supporting H.263 SHALL use the payload format described in this document. RFC 2190 is moved to historic status [RFC4628].
このドキュメントは、国際電気通信連合-電気通信標準化セクター（ITU-T）勧告H.263 [H263]の1998年と2000年のバージョンに基づくビデオストリームの送信に適用可能なRTPペイロードヘッダー形式を指定します。 H.263の1998バージョンと2000バージョンは1996構文のスーパーセットであるため、このフォーマットはH.263の1996バージョンでも使用でき、新しい実装での使用に推奨されています。この形式は、RFC 2190 [RFC2190]のペイロード形式を置き換えます。これは、一部の既存の実装で引き続き使用されており、下位互換性のために役立ちます。 H.263をサポートする新しい実装は、このドキュメントで説明されているペイロード形式を使用するものとします（SHALL）。 RFC 2190は履歴ステータス[RFC4628]に移行されました。
The document updates the media type registration that was previously in RFC 3555 [RFC3555].
このドキュメントは、以前にRFC 3555 [RFC3555]にあったメディアタイプ登録を更新します。
This document obsoletes RFC 2429 [RFC2429].
このドキュメントはRFC 2429 [RFC2429]を廃止します。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈され、準拠RTP実装の要件レベルを示します。
The 1998 version of ITU-T Recommendation H.263 added numerous coding options to improve codec performance over the 1996 version. In this document, the 1998 version is referred to as H.263+ and the 2000 version as H.263++.
ITU-T勧告H.263の1998バージョンでは、1996バージョンよりもコーデックのパフォーマンスを向上させるために、多数のコーディングオプションが追加されました。このドキュメントでは、1998年のバージョンをH.263 +、2000年のバージョンをH.263 ++と呼びます。
Among the new options, the ones with the biggest impact on the RTP payload specification and the error resilience of the video content are the slice structured mode, the independent segment decoding mode, the reference picture selection mode, and the scalability mode. This section summarizes the impact of these new coding options on packetization. Refer to [H263] for more information on coding options.
新しいオプションの中で、RTPペイロードの仕様とビデオコンテンツのエラー耐性に最も大きな影響を与えるのは、スライス構造化モード、独立セグメントデコードモード、参照画像選択モード、およびスケーラビリティモードです。このセクションでは、これらの新しいコーディングオプションがパケット化に与える影響をまとめています。コーディングオプションの詳細については、[H263]を参照してください。
The slice structured mode was added to H.263+ for three purposes: to provide enhanced error resilience capability, to make the bitstream more amenable for use with an underlying packet transport such as RTP, and to minimize video delay. The slice structured mode supports fragmentation at macroblock boundaries.
スライス構造化モードは、3つの目的でH.263 +に追加されました。拡張されたエラー回復機能を提供すること、ビットストリームをRTPなどの基になるパケットトランスポートで使用しやすくし、ビデオ遅延を最小限にすることです。スライス構造化モードは、マクロブロック境界での断片化をサポートします。
With the independent segment decoding (ISD) option, a video picture frame is broken into segments and encoded in such a way that each segment is independently decodable. Utilizing ISD in a lossy network environment helps to prevent the propagation of errors from one segment of the picture to others.
独立セグメントデコード（ISD）オプションを使用すると、ビデオ画像フレームがセグメントに分割され、各セグメントが独立してデコードできるようにエンコードされます。損失の多いネットワーク環境でISDを使用すると、画像の1つのセグメントから他のセグメントへのエラーの伝播を防ぐのに役立ちます。
The reference picture selection mode allows the use of an older reference picture rather than the one immediately preceding the current picture. Usually, the last transmitted frame is implicitly used as the reference picture for inter-frame prediction. If the reference picture selection mode is used, the data stream carries information on what reference frame should be used, indicated by the temporal reference as an ID for that reference frame. The reference picture selection mode may be used with or without a back channel, which provides information to the encoder about the internal status of the decoder. However, no special provision is made herein for carrying back channel information. The Extended RTP Profile for RTP Control Protocol (RTCP)-based Feedback [RFC4585] MAY be used as a back channel mechanism.
参照画像選択モードでは、現在の画像の直前の参照画像ではなく、古い参照画像を使用できます。通常、最後に送信されたフレームは、フレーム間予測の参照画像として暗黙的に使用されます。参照画像選択モードが使用される場合、データストリームは、どの参照フレームを使用すべきかについての情報を運び、その参照フレームのIDとして時間参照によって示されます。参照ピクチャ選択モードは、バックチャネルの有無にかかわらず使用できます。バックチャネルは、デコーダーの内部ステータスに関する情報をエンコーダーに提供します。しかしながら、チャネル情報を戻すための特別な規定はここでは行われない。 RTP制御プロトコル（RTCP）ベースのフィードバックの拡張RTPプロファイル[RFC4585]は、バックチャネルメカニズムとして使用できます。
H.263+ also includes bitstream scalability as an optional coding mode. Three kinds of scalability are defined: temporal, signal-to-noise ratio (SNR), and spatial scalability. Temporal scalability is achieved via the disposable nature of bi-directionally predicted frames, or B-frames. (A low-delay form of temporal scalability known as P-picture temporal scalability can also be achieved by using the reference picture selection mode, described in the previous paragraph.) SNR scalability permits refinement of encoded video frames, thereby improving the quality (or SNR). Spatial scalability is similar to SNR scalability except that the refinement layer is twice the size of the base layer in the horizontal dimension, vertical dimension, or both.
H.263 +には、オプションのコーディングモードとしてビットストリームのスケーラビリティも含まれています。 3種類のスケーラビリティが定義されています。時間的、信号対雑音比（SNR）、および空間的スケーラビリティです。時間的スケーラビリティは、双方向予測フレーム、つまりBフレームの使い捨ての性質によって実現されます。 （Pピクチャの時間スケーラビリティとして知られている低遅延の時間スケーラビリティは、前の段落で説明した参照ピクチャ選択モードを使用して実現することもできます。）SNRスケーラビリティにより、エンコードされたビデオフレームを改良して、品質を向上できますSNR）。空間スケーラビリティは、リファインメントレイヤーが水平方向、垂直方向、またはその両方のベースレイヤーのサイズの2倍であることを除いて、SNRスケーラビリティに似ています。
H.263++ added some new functionalities. Among the new functionalities are support for interlace mode, specified in H.263, annex W.6.3.11, and the definition of profiles and levels in H.263 annex X.
H.263 ++はいくつかの新しい機能を追加しました。新しい機能の中には、H.263、付録W.6.3.11で指定されているインターレースモードのサポート、およびH.263付録Xのプロファイルとレベルの定義があります。
When transmitting H.263+ video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting from the bitstream (including the fixed length codes and variable length codes) will be included in the packet, the only exception being that when the payload of a packet begins with a Picture, GOB, Slice, End of Sequence (EOS), or End of Sub-Bit Stream (EOSBS) start code, the first 2 (all-zero) bytes of the start code shall be removed and replaced by setting an indicator bit in the payload header.
H.263 +ビデオストリームをインターネット経由で送信する場合、エンコーダの出力を直接パケット化できます。ビットストリームから生成されるすべてのビット（固定長コードと可変長コードを含む）がパケットに含まれます。唯一の例外は、パケットのペイロードがピクチャ、GOB、スライス、シーケンスの終わり（EOS）で始まる場合です。 ）、またはサブビットストリームの終了（EOSBS）開始コード、開始コードの最初の2（すべてゼロ）バイトは削除され、ペイロードヘッダーにインジケータービットを設定することによって置き換えられます。
For H.263+ bitstreams coded with temporal, spatial, or SNR scalability, each layer may be transported to a different network address. More specifically, each layer may use a unique IP address and port number combination. The temporal relations between layers shall be expressed using the RTP timestamp so that they can be synchronized at the receiving ends in multicast or unicast applications.
時間的、空間的、またはSNRのスケーラビリティでコード化されたH.263 +ビットストリームの場合、各レイヤーは異なるネットワークアドレスに転送されます。より具体的には、各層は一意のIPアドレスとポート番号の組み合わせを使用できます。レイヤー間の時間的関係は、RTPタイムスタンプを使用して表現されるため、マルチキャストまたはユニキャストアプリケーションの受信側で同期できます。
The H.263+ video stream will be carried as payload data within RTP packets. A new H.263+ payload header is defined in Section 5; it updates the one specified in RFC 2190. This section defines the usage of the RTP fixed header and H.263+ video packet structure.
H.263 +ビデオストリームは、RTPパケット内のペイロードデータとして伝送されます。新しいH.263 +ペイロードヘッダーはセクション5で定義されています。 RFC 2190で指定されているものを更新します。このセクションでは、RTP固定ヘッダーとH.263 +ビデオパケット構造の使用法を定義します。
Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header used for H.263+ video streams are further emphasized here.
各RTPパケットは、固定RTPヘッダーで始まります。 H.263 +ビデオストリームに使用されるRTP固定ヘッダーの次のフィールドは、ここでさらに強調されています。
Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame and is 0 otherwise.
マーカービット（Mビット）：RTPヘッダーのマーカービットは、現在のパケットが現在のフレームの終わりを運ぶ場合は1に設定され、それ以外の場合は0に設定されます。
Payload Type (PT): The RTP profile for a particular class of applications will assign a payload type for this encoding, or, if that is not done, a payload type in the dynamic range shall be chosen by the sender.
ペイロードタイプ（PT）：特定のクラスのアプリケーションのRTPプロファイルは、このエンコーディングにペイロードタイプを割り当てます。または、それが行われない場合、ダイナミックレンジのペイロードタイプが送信者によって選択されます。
Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame data contained in the RTP data packet. The RTP timestamp shall be the same on successive packets if a video frame occupies more than one packet. In a multilayer scenario, all pictures corresponding to the same temporal reference should use the same timestamp. If temporal scalability is used (if B-frames are present), the timestamp may not be monotonically increasing in the RTP stream. If B-frames are transmitted on a separate layer and address, they must be synchronized properly with the reference frames. Refer to ITU-T Recommendation H.263 [H263] for information on required transmission order to a decoder. For an H.263+ video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of the RTP payload for H.261 stream [RFC2032]. Since both the H.263+ data and the RTP header contain time information, that timing information must run synchronously. That is, both the RTP timestamp and the temporal reference (TR in the picture header of H.263) should carry the same relative timing information. Any H.263+ picture clock frequency can be expressed as 1800000/(cd*cf) source pictures per second, in which cd is an integer from 1 to 127 and cf is either 1000 or 1001. Using the 90 kHz clock of the RTP timestamp, the time increment between each coded H.263+ picture should therefore be an integer multiple of (cd*cf)/20. This will always be an integer for any "reasonable" picture clock frequency (for example, it is 3003 for 30/1.001 Hz NTSC; 3600 for 25 Hz PAL; 3750 for 24 Hz film; and 1500, 1250, or 1200 for the computer display update rates of 60, 72, or 75 Hz, respectively). For RTP packetization of hypothetical H.263+ bitstreams using "unreasonable" custom picture clock frequencies, mathematical rounding could become necessary for generating the RTP timestamps.
タイムスタンプ：RTPタイムスタンプは、RTPデータパケットに含まれる最初のビデオフレームデータのサンプリングインスタンスをエンコードします。ビデオフレームが複数のパケットを占める場合、RTPタイムスタンプは連続するパケットで同じでなければなりません。多層シナリオでは、同じ時間参照に対応するすべての画像で同じタイムスタンプを使用する必要があります。時間的スケーラビリティが使用されている場合（Bフレームが存在する場合）、RTPストリームでタイムスタンプが単調に増加しない場合があります。 Bフレームが別のレイヤーとアドレスで送信される場合、それらは参照フレームと正しく同期する必要があります。デコーダーに必要な送信順序については、ITU-T勧告H.263 [H263]を参照してください。 H.263 +ビデオストリームの場合、RTPタイムスタンプは、90 kHzクロックに基づいており、H.261ストリームのRTPペイロード[RFC2032]と同じです。 H.263 +データとRTPヘッダーの両方に時間情報が含まれているため、そのタイミング情報は同期して実行する必要があります。つまり、RTPタイムスタンプと時間参照（H.263の画像ヘッダーのTR）の両方が同じ相対タイミング情報を伝える必要があります。 H.263 +の画像クロック周波数は、1秒あたり1800000 /（cd * cf）ソース画像として表現できます。cdは1〜127の整数で、cfは1000または1001です。RTPの90 kHzクロックの使用タイムスタンプ。したがって、各コード化H.263 +画像間の時間増分は、（cd * cf）/ 20の整数倍である必要があります。これは常に「妥当な」画像クロック周波数の整数です（たとえば、30 / 1.001 Hz NTSCの場合は3003、25 Hz PALの場合は3600、24 Hzフィルムの場合は3750、コンピュータの場合は1500、1250、または1200です。それぞれ60、72、または75 Hzの更新レートを表示します）。 「不合理な」カスタムピクチャクロック周波数を使用した仮想H.263 +ビットストリームのRTPパケット化では、RTPタイムスタンプを生成するために数学的な丸めが必要になる可能性があります。
A section of an H.263+ compressed bitstream is carried as a payload within each RTP packet. For each RTP packet, the RTP header is followed by an H.263+ payload header, which is followed by a number of bytes of a standard H.263+ compressed bitstream. The size of the H.263+ payload header is variable, depending on the payload involved, as detailed in the Section 4. The layout of the RTP H.263+ video packet is shown as
H.263 +圧縮ビットストリームのセクションは、各RTPパケット内のペイロードとして伝送されます。各RTPパケットでは、RTPヘッダーの後にH.263 +ペイロードヘッダーが続き、その後に標準のH.263 +圧縮ビットストリームのバイト数が続きます。 H.263 +ペイロードヘッダーのサイズは、セクション4で詳しく説明するように、関連するペイロードに応じて可変です。RTPH.263 +ビデオパケットのレイアウトは、次のように表示されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RTP Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Payload Header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: H.263+ Compressed Data Stream :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any H.263+ start codes can be byte aligned by an encoder by using the stuffing mechanisms of H.263+. As specified in H.263+, picture, slice, and EOSBS starts codes shall always be byte aligned, and GOB and EOS start codes may be byte aligned. For packetization purposes, GOB start codes should be byte aligned; however, since this is not required in H.263+, there may be some cases where GOB start codes are not aligned, such as when transmitting existing content, or when using H.263 encoders that do not support GOB start code alignment. In this case, Follow-on Packets (see Section 5.2) should be used for packetization.
H.263 +のスタッフィングメカニズムを使用することにより、H.263 +スタートコードをエンコーダでバイトアラインすることができます。 H.263 +で指定されているように、画像、スライス、およびEOSBSの開始コードは常にバイト単位で整列し、GOBおよびEOSの開始コードはバイト単位で整列することができます。パケット化のために、GOB開始コードはバイト単位で整列する必要があります。ただし、これはH.263 +では必要ないため、既存のコンテンツを送信するときや、GOBスタートコードのアライメントをサポートしないH.263エンコーダーを使用するときなど、GOBスタートコードがアライメントされない場合があります。この場合、パケット化には後続パケット（セクション5.2を参照）を使用する必要があります。
All H.263+ start codes (Picture, GOB, Slice, EOS, and EOSBS) begin with 16 zero-valued bits. If a start code is byte aligned and it occurs at the beginning of a packet, these two bytes shall be removed from the H.263+ compressed data stream in the packetization process and shall instead be represented by setting a bit (the P bit) in the payload header.
すべてのH.263 +スタートコード（画像、GOB、スライス、EOS、およびEOSBS）は、16個のゼロ値ビットで始まります。開始コードがバイト境界で整列され、パケットの先頭にある場合、これらの2バイトは、パケット化プロセスでH.263 +圧縮データストリームから削除され、代わりにビット（Pビット）を設定して表されます。ペイロードヘッダー内。
The goals of this payload format are to specify an efficient way of encapsulating an H.263+ standard compliant bitstream and to enhance the resiliency towards packet losses. Due to the large number of different possible coding schemes in H.263+, a copy of the picture header with configuration information is inserted into the payload header when appropriate. The use of that copy of the picture header along with the payload data can allow decoding of a received packet even in cases when another packet containing the original picture header becomes lost.
このペイロード形式の目的は、H.263 +標準に準拠したビットストリームをカプセル化する効率的な方法を指定し、パケット損失に対する回復力を高めることです。 H.263 +にはさまざまなコーディングスキームが多数あるため、構成情報を含む画像ヘッダーのコピーがペイロードヘッダーに適切に挿入されます。ペイロードデータと共に画像ヘッダーのコピーを使用すると、元の画像ヘッダーを含む別のパケットが失われた場合でも、受信したパケットをデコードできます。
There are a few assumptions and constraints associated with this H.263+ payload header design. The purpose of this section is to point out various design issues and also to discuss several coding options provided by H.263+ that may impact the performance of network-based H.263+ video.
このH.263 +ペイロードヘッダーの設計には、いくつかの仮定と制約があります。このセクションの目的は、さまざまな設計上の問題を指摘し、ネットワークベースのH.263 +ビデオのパフォーマンスに影響を与える可能性があるH.263 +によって提供されるいくつかのコーディングオプションについて説明することです。
o The optional slice structured mode described in Annex K of [H263] enables more flexibility for packetization. Similar to a picture segment that begins with a GOB header, the motion vector predictors in a slice are restricted to reside within its boundaries. However, slices provide much greater freedom in the selection of the size and shape of the area that is represented as a distinct decodable region. In particular, slices can have a size that is dynamically selected to allow the data for each slice to fit into a chosen packet size. Slices can also be chosen to have a rectangular shape, which is conducive for minimizing the impact of errors and packet losses on motion-compensated prediction. For these reasons, the use of the slice structured mode is strongly recommended for any applications used in environments where significant packet loss occurs.
o [H263]のAnnex Kで説明されているオプションのスライス構造化モードは、パケット化の柔軟性を高めます。 GOBヘッダーで始まる画像セグメントと同様に、スライス内の予測動きベクトルはその境界内に存在するように制限されています。ただし、スライスを使用すると、個別のデコード可能な領域として表される領域のサイズと形状をより自由に選択できます。特に、スライスのサイズは動的に選択され、各スライスのデータを選択したパケットサイズに合わせることができます。スライスは長方形の形状を持つように選択することもできます。これは、動き補償予測に対するエラーとパケット損失の影響を最小限に抑えるのに役立ちます。これらの理由により、重大なパケット損失が発生する環境で使用されるアプリケーションには、スライス構造化モードの使用を強くお勧めします。
o In non-rectangular slice structured mode, only complete slices SHOULD be included in a packet. In other words, slices should not be fragmented across packet boundaries. The only reasonable need for a slice to be fragmented across packet boundaries is when the encoder that generated the H.263+ data stream could not be influenced by an awareness of the packetization process (such as when sending H.263+ data through a network other than the one to which the encoder is attached, as in network gateway implementations). Optimally, each packet will contain only one slice.
o 長方形以外のスライス構造化モードでは、完全なスライスのみをパケットに含める必要があります（SHOULD）。つまり、スライスはパケットの境界を越えて断片化されるべきではありません。パケットの境界を越えてスライスを断片化するための唯一の合理的な必要性は、H.263 +データストリームを生成したエンコーダーがパケット化プロセスの認識の影響を受けない場合です（ネットワーク経由でH.263 +データを送信する場合など）。ネットワークゲートウェイの実装のように、エンコーダーが接続されているもの以外）。最適には、各パケットにはスライスが1つだけ含まれます。
o The independent segment decoding (ISD) described in Annex R of [H263] prevents any data dependency across slice or GOB boundaries in the reference picture. It can be utilized to improve resiliency further in high loss conditions.
o [H263]の付録Rで説明されている独立セグメントデコード（ISD）は、参照画像のスライスまたはGOBの境界を越えてデータが依存しないようにします。高損失状態での回復力をさらに向上させるために利用できます。
o If ISD is used in conjunction with the slice structure, the rectangular slice submode shall be enabled, and the dimensions and quantity of the slices present in a frame shall remain the same between each two intra-coded frames (I-frames), as required in H.263+. The individual ISD segments may also be entirely intra coded from time to time to realize quick error recovery without adding the latency time associated with sending complete INTRA-pictures.
o ISDがスライス構造と共に使用される場合、長方形スライスサブモードが有効になり、フレームに存在するスライスの寸法と数量は、必要に応じて、2つのイントラ符号化フレーム（Iフレーム）間で同じままになります。 H.263 +で。個々のISDセグメントは、完全なイントラ画像の送信に関連する待ち時間を追加することなく、迅速なエラー回復を実現するために、時々完全にイントラコード化することもできます。
o When the slice structure is not applied, the insertion of a (preferably byte-aligned) GOB header can be used to provide resync boundaries in the bitstream, as the presence of a GOB header eliminates the dependency of motion vector prediction across GOB boundaries. These resync boundaries provide natural locations for packet payload boundaries.
o スライス構造が適用されていない場合、GOBヘッダーの存在により、GOB境界をまたぐモーションベクトル予測の依存性が排除されるため、ビットストリームに再同期境界を提供するために（できればバイト境界で整列した）GOBヘッダーを挿入できます。これらの再同期境界は、パケットペイロード境界の自然な場所を提供します。
o H.263+ allows picture headers to be sent in an abbreviated form in order to prevent repetition of overhead information that does not change from picture to picture. For resiliency, sending a complete picture header for every frame is often advisable. This means (especially in cases with high packet loss probability in which picture header contents are not expected to be highly predictable) that the sender may find it advisable always to set the subfield UFEP in PLUSPTYPE to '001' in the H.263+ video bitstream. (See [H263] for the definition of the UFEP and PLUSPTYPE fields).
o H.263 +では、ピクチャごとに変化しないオーバーヘッド情報の繰り返しを防ぐために、ピクチャヘッダーを省略形で送信できます。回復力を高めるために、フレームごとに完全な画像ヘッダーを送信することをお勧めします。これは（特に、画像損失の可能性が高く、画像ヘッダーの内容が高度に予測可能でないと予想される場合）、送信者はH.263 +ビデオのPLUSPTYPEのサブフィールドUFEPを「001」に常に設定することをお勧めします。ビットストリーム。 （UFEPおよびPLUSPTYPEフィールドの定義については、[H263]を参照してください）。
o In a multi-layer scenario, each layer may be transmitted to a different network address. The configuration of each layer, such as the enhancement layer number (ELNUM), reference layer number (RLNUM), and scalability type should be determined at the start of the session and should not change during the course of the session.
o 多層シナリオでは、各層が異なるネットワークアドレスに送信される場合があります。拡張層番号（ELNUM）、参照層番号（RLNUM）、スケーラビリティタイプなどの各層の構成は、セッションの開始時に決定する必要があり、セッション中に変更しないでください。
o All start codes can be byte aligned, and picture, slice, and EOSBS start codes are always byte aligned. The boundaries of these syntactical elements provide ideal locations for placing packet boundaries.
o すべての開始コードはバイト単位で整列でき、画像、スライス、およびEOSBS開始コードは常にバイト単位で整列されます。これらの構文要素の境界は、パケット境界を配置するための理想的な場所を提供します。
o We assume that a maximum Picture Header size of 504 bits is sufficient. The syntax of H.263+ does not explicitly prohibit larger picture header sizes, but the use of such extremely large picture headers is not expected.
o ピクチャヘッダーの最大サイズは504ビットで十分であると想定しています。 H.263 +の構文は、より大きい画像ヘッダーサイズを明示的に禁止していませんが、そのような非常に大きい画像ヘッダーの使用は想定されていません。
For H.263+ video streams, each RTP packet shall carry only one H.263+ video packet. The H.263+ payload header shall always be present for each H.263+ video packet. The payload header is of variable length. A 16-bit field of the general payload header, defined in 5.1, may be followed by an 8 bit field for Video Redundancy Coding (VRC) information, and/or by a variable-length extra picture header as indicated by PLEN. These optional fields appear in the order given above, when present.
H.263 +ビデオストリームの場合、各RTPパケットは1つのH.263 +ビデオパケットのみを伝送します。 H.263 +ペイロードヘッダーは、各H.263 +ビデオパケットに対して常に存在します。ペイロードヘッダーは可変長です。 5.1で定義されている一般的なペイロードヘッダーの16ビットフィールドの後に、ビデオ冗長コーディング（VRC）情報用の8ビットフィールド、および/またはPLENで示される可変長の追加の画像ヘッダーが続く場合があります。これらのオプションのフィールドは、存在する場合、上記の順序で表示されます。
If an extra picture header is included in the payload header, the length of the picture header in number of bytes is specified by PLEN. The minimum length of the payload header is 16 bits, PLEN equal to 0 and no VRC information being present.
ペイロードヘッダーに追加の画像ヘッダーが含まれる場合、画像ヘッダーの長さ（バイト数）がPLENによって指定されます。ペイロードヘッダーの最小長は16ビットで、PLENは0で、VRC情報はありません。
The remainder of this section defines the various components of the RTP payload header. Section 6 defines the various packet types that are used to carry different types of H.263+ coded data, and Section 7 summarizes how to distinguish between the various packet types.
このセクションの残りの部分では、RTPペイロードヘッダーのさまざまなコンポーネントを定義します。セクション6では、さまざまなタイプのH.263 +コード化データを伝送するために使用されるさまざまなパケットタイプを定義し、セクション7では、さまざまなパケットタイプを区別する方法を要約します。
The H.263+ payload header is structured as follows:
H.263 +ペイロードヘッダーの構造は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |P|V| PLEN |PEBIT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RR: 5 bits
RR：5ビット
Reserved bits. It SHALL be zero and MUST be ignored by receivers.
予約ビット。それはゼロである必要があり、レシーバーによって無視されなければなりません。
P: 1 bit
P：1ビット
Indicates the picture start or a picture segment (GOB/Slice) start or a video sequence end (EOS or EOSBS). Two bytes of zero bits then have to be prefixed to the payload of such a packet to compose a complete picture/GOB/slice/EOS/EOSBS start code. This bit allows the omission of the two first bytes of the start codes, thus improving the compression ratio.
ピクチャの開始またはピクチャセグメント（GOB /スライス）の開始またはビデオシーケンスの終了（EOSまたはEOSBS）を示します。次に、完全な画像/ GOB /スライス/ EOS / EOSBS開始コードを構成するために、このようなパケットのペイロードの前に2ビットのゼロビットを付加する必要があります。このビットにより、開始コードの最初の2バイトを省略できるため、圧縮率が向上します。
V: 1 bit
V：1ビット
Indicates the presence of an 8-bit field containing information for Video Redundancy Coding (VRC), which follows immediately after the initial 16 bits of the payload header, if present. For syntax and semantics of that 8-bit VRC field, see Section 5.2.
存在する場合、ペイロードヘッダーの最初の16ビットの直後に続く、ビデオ冗長コーディング（VRC）の情報を含む8ビットフィールドの存在を示します。その8ビットVRCフィールドの構文とセマンティクスについては、セクション5.2を参照してください。
PLEN: 6 bits
PLEN：6ビット
Length, in bytes, of the extra picture header. If no extra picture header is attached, PLEN is 0. If PLEN>0, the extra picture header is attached immediately following the rest of the payload header. Note that the length reflects the omission of the first two bytes of the picture start code (PSC). See Section 6.1.
追加の画像ヘッダーの長さ（バイト単位）。追加の画像ヘッダーが添付されていない場合、PLENは0です。PLEN> 0の場合、追加の画像ヘッダーは、ペイロードヘッダーの残りの直後に追加されます。長さは、ピクチャスタートコード（PSC）の最初の2バイトの省略を反映していることに注意してください。セクション6.1を参照してください。
PEBIT: 3 bits
PEBIT：3ビット
Indicates the number of bits that shall be ignored in the last byte of the picture header. If PLEN is not zero, the ignored bits shall be the least significant bits of the byte. If PLEN is zero, then PEBIT shall also be zero.
ピクチャヘッダーの最後のバイトで無視されるビット数を示します。 PLENがゼロでない場合、無視されるビットはバイトの最下位ビットになります。 PLENがゼロの場合、PEBITもゼロになります。
Video Redundancy Coding (VRC) is an optional mechanism intended to improve error resilience over packet networks. Implementing VRC in H.263+ will require the Reference Picture Selection option described in Annex N of [H263]. By having multiple "threads" of independently inter-frame predicted pictures, damage to an individual frame will cause distortions only within its own thread, leaving the other threads unaffected. From time to time, all threads converge to a so-called sync frame (an INTRA picture or a non-INTRA picture that is redundantly represented within multiple threads); from this sync frame, the independent threads are started again. For more information on codec support for VRC, see [Vredun].
ビデオ冗長コーディング（VRC）は、パケットネットワークでのエラー耐性を向上させることを目的としたオプションのメカニズムです。 H.263 +にVRCを実装するには、[H263]の付録Nで説明されている参照画像選択オプションが必要です。独立したフレーム間予測画像の複数の「スレッド」を持つことにより、個々のフレームへの損傷は、それ自体のスレッド内でのみ歪みを引き起こし、他のスレッドには影響を与えません。時々、すべてのスレッドがいわゆる同期フレーム（複数のスレッド内で冗長的に表現されるINTRAピクチャまたは非INTRAピクチャ）に収束します。この同期フレームから、独立したスレッドが再び開始されます。 VRCのコーデックサポートの詳細については、[Vredun]を参照してください。
P-picture temporal scalability is another use of the reference picture selection mode and can be considered a special case of VRC in which only one copy of each sync frame may be sent. It offers a thread-based method of temporal scalability without the increased delay caused by the use of B pictures. In this use, sync frames sent in the first thread of pictures are also used for the prediction of a second thread of pictures that fall temporally between the sync frames to increase the resulting frame rate. In this use, the pictures in the second thread can be discarded in order to obtain a reduction of bit rate or decoding complexity without harming the ability to decode later pictures. A third or more threads, can also be added, but each thread is predicted only from the sync frames (which are sent at least in thread 0) or from frames within the same thread.
Pピクチャの時間スケーラビリティは、参照ピクチャ選択モードのもう1つの用途であり、各同期フレームの1つのコピーのみを送信できるVRCの特殊なケースと見なすことができます。 Bピクチャの使用による遅延の増加なしに、時間ベースのスケーラビリティのスレッドベースの方法を提供します。この使用法では、画像の最初のスレッドで送信された同期フレームは、同期フレームの間に一時的に入る画像の2番目のスレッドの予測にも使用され、結果のフレームレートが増加します。この使用法では、2番目のスレッドの画像を破棄して、後の画像をデコードする機能を損なうことなく、ビットレートまたはデコードの複雑さを減らすことができます。 3つ以上のスレッドを追加することもできますが、各スレッドは同期フレーム（少なくともスレッド0で送信される）または同じスレッド内のフレームからのみ予測されます。
While a VRC data stream is (like all H.263+ data) totally self-contained, it may be useful for the transport hierarchy implementation to have knowledge about the current damage status of each thread. On the Internet, this status can easily be determined by observing the marker bit, the sequence number of the RTP header, the thread-id, and a circling "packet per thread" number. The latter two numbers are coded in the VRC header extension.
VRCデータストリームは（すべてのH.263 +データのように）完全に自己完結型ですが、トランスポート階層の実装が各スレッドの現在の損傷状態に関する知識を持っていると便利です。インターネットでは、このステータスは、マーカービット、RTPヘッダーのシーケンス番号、スレッドID、および循環する「スレッドごとのパケット」番号を確認することで簡単に判断できます。後者の2つの番号は、VRCヘッダー拡張でコーディングされます。
The format of the VRC header extension is as follows:
VRCヘッダー拡張の形式は次のとおりです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| TID | Trun |S|
+-+-+-+-+-+-+-+-+
TID: 3 bits
時間：3ビット
Thread ID. Up to 7 threads are allowed. Each frame of H.263+ VRC data will use as reference information only sync frames or frames within the same thread. By convention, thread 0 is expected to be the "canonical" thread, which is the thread from which the sync frame should ideally be used. In the case of corruption or loss of the thread 0 representation, a representation of the sync frame with a higher thread number can be used by the decoder. Lower thread numbers are expected to contain representations of the sync frames equal to or better than higher thread numbers in the absence of data corruption or loss. See [Vredun] for a detailed discussion of VRC.
スレッドID。最大7つのスレッドが許可されます。 H.263 + VRCデータの各フレームは、同期情報または同じスレッド内のフレームのみを参照情報として使用します。慣例により、スレッド0は「正規の」スレッドであると予想されます。これは、同期フレームを理想的に使用する必要があるスレッドです。スレッド0表現の破損または損失の場合、より大きなスレッド番号を持つ同期フレームの表現をデコーダーで使用できます。スレッド数が少ない場合、データの破損や損失がない場合は、スレッド数が多い場合と同等またはそれ以上の同期フレームの表現が含まれることが期待されます。 VRCの詳細については、[Vredun]を参照してください。
Trun: 4 bits
回転：4ビット
Monotonically increasing (modulo 16) 4-bit number counting the packet number within each thread.
各スレッド内のパケット数をカウントする単調に増加する（モジュロ16）4ビット数。
S: 1 bit
S：1ビット
A bit that indicates that the packet content is for a sync frame. An encoder using VRC may send several representations of the same "sync" picture, in order to ensure that, regardless of which thread of pictures is corrupted by errors or packet losses, the reception of at least one representation of a particular picture is ensured (within at least one thread). The sync picture can then be used for the prediction of any thread. If packet losses have not occurred, then the sync frame contents of thread 0 can be used, and those of other threads can be discarded (and similarly for other threads). Thread 0 is considered the "canonical" thread, the use of which is preferable to all others. The contents of packets having lower thread numbers shall be considered as having a higher processing and delivery priority than those with higher thread numbers. Thus, packets having lower thread numbers for a given sync frame shall be delivered first to the decoder under loss-free and low-time-jitter conditions, which will result in the discarding of the sync contents of the higher-numbered threads as specified in Annex N of [H263].
パケットの内容が同期フレーム用であることを示すビット。 VRCを使用するエンコーダーは、同じ「同期」画像のいくつかの表現を送信することができます。これにより、エラーまたはパケット損失によって画像のどのスレッドが破損しても、特定の画像の少なくとも1つの表現の受信が保証されます（少なくとも1つのスレッド内）。同期画像は、任意のスレッドの予測に使用できます。パケット損失が発生していない場合は、スレッド0の同期フレームの内容を使用でき、他のスレッドの同期フレームの内容は破棄できます（他のスレッドでも同様）。スレッド0は「標準」スレッドと見なされ、他のすべてのスレッドよりも使用することが推奨されます。スレッド番号が小さいパケットの内容は、スレッド番号が大きいパケットよりも処理および配信の優先順位が高いと見なされます。したがって、所定の同期フレームのスレッド番号が小さいパケットは、損失のない低時間ジッターの条件下で最初にデコーダーに配信されます。これにより、以下で指定されている番号の大きいスレッドの同期コンテンツが破棄されます。 [H263]の付録N。
A picture segment packet is defined as a packet that starts at the location of a Picture, GOB, or slice start code in the H.263+ data stream. This corresponds to the definition of the start of a video picture segment as defined in H.263+. For such packets, P=1 always.
ピクチャセグメントパケットは、H.263 +データストリーム内のピクチャ、GOB、またはスライススタートコードの位置で始まるパケットとして定義されます。これは、H.263 +で定義されているビデオ画像セグメントの開始の定義に対応しています。そのようなパケットの場合、常にP = 1です。
An extra picture header can sometimes be attached in the payload header of such packets. Whenever an extra picture header is attached as signified by PLEN>0, only the last six bits of its picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte-aligned picture start code can be conveniently assembled on the receiving end by prepending the sixteen leading '0' bits.
このようなパケットのペイロードヘッダーには、追加の画像ヘッダーが添付されることがあります。 PLEN> 0で示される追加の画像ヘッダーが添付されている場合は常に、その画像開始コードの最後の6ビット（100000）のみがペイロードヘッダーに含まれます。先頭に16個の「0」ビットを付加することで、バイトアライメントの画像開始コードを備えた完全なH.263 +画像ヘッダーを受信側で簡単に組み立てることができます。
When PLEN>0, the end bit position corresponding to the last byte of the picture header data is indicated by PEBIT. The actual bitstream data shall begin on an 8-bit byte boundary following the payload header.
PLEN> 0の場合、ピクチャヘッダーデータの最後のバイトに対応する終了ビット位置はPEBITで示されます。実際のビットストリームデータは、ペイロードヘッダーに続く8ビットバイト境界で開始します。
A sequence ending packet is defined as a packet that starts at the location of an EOS or EOSBS code in the H.263+ data stream. This delineates the end of a sequence of H.263+ video data (more H.263+ video data may still follow later, however, as specified in ITU-T Recommendation H.263). For such packets, P=1 and PLEN=0 always.
シーケンス終了パケットは、H.263 +データストリームのEOSまたはEOSBSコードの場所で始まるパケットとして定義されます。これは、H.263 +ビデオデータのシーケンスの終わりを示します（ただし、ITU-T勧告H.263で指定されているように、さらに多くのH.263 +ビデオデータが後に続く場合があります）。そのようなパケットの場合、常にP = 1およびPLEN = 0です。
The optional header extension for VRC may or may not be present as indicated by the V bit flag.
VRCのオプションのヘッダー拡張は、Vビットフラグで示されるように存在する場合と存在しない場合があります。
Any packet that contains the whole or the start of a coded picture shall start at the location of the picture start code (PSC) and should normally be encapsulated with no extra copy of the picture header. In other words, normally PLEN=0 in such a case. However, if the coded picture contains an incomplete picture header (UFEP = "000"), then a representation of the complete (UFEP = "001") picture header may be attached during packetization in order to provide greater error resilience. Thus, for packets that start at the location of a picture start code, PLEN shall be zero unless both of the following conditions apply:
コード化された画像の全体または開始を含むパケットは、画像開始コード（PSC）の位置から開始し、通常は画像ヘッダーの追加のコピーなしでカプセル化する必要があります。つまり、このような場合は通常PLEN = 0です。ただし、コード化された画像に不完全な画像ヘッダー（UFEP = "000"）が含まれている場合、完全な（UFEP = "001"）画像ヘッダーの表現をパケット化中に添付して、エラー耐性を高めることができます。したがって、画像開始コードの位置で始まるパケットの場合、次の条件が両方とも当てはまらない限り、PLENはゼロになります。
1) The picture header in the H.263+ bitstream payload is incomplete (PLUSPTYPE present and UFEP="000").
1）H.263 +ビットストリームペイロードの画像ヘッダーが不完全です（PLUSPTYPEが存在し、UFEP = "000"）。
2) The additional picture header that is attached is not incomplete (UFEP="001").
2）添付されている追加の画像ヘッダーは不完全ではありません（UFEP = "001"）。
A packet that begins at the location of a Picture, GOB, slice, EOS, or EOSBS start code shall omit the first two (all zero) bytes from the H.263+ bitstream and signify their presence by setting P=1 in the payload header.
ピクチャ、GOB、スライス、EOS、またはEOSBSスタートコードの場所で始まるパケットは、H.263 +ビットストリームから最初の2バイト（すべてゼロ）を省略し、ペイロードにP = 1を設定することでその存在を示しますヘッダ。
Here is an example of encapsulating the first packet in a frame (without an attached redundant complete picture header):
以下は、フレーム内の最初のパケットをカプセル化する例です（冗長な完全な画像ヘッダーが付加されていません）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0| bitstream data without the :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: first two 0 bytes of the PSC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For a packet that begins at the location of a GOB or slice start code (GBSC), PLEN may be zero or nonzero, depending on whether a redundant picture header is attached to the packet. In environments with very low packet loss rates, or when picture header contents are very seldom likely to change (except as can be detected from the GOB Frame ID (GFID) syntax of H.263+), a redundant copy of the picture header is not required. However, in less ideal circumstances a redundant picture header should be attached for enhanced error resilience, and its presence is indicated by PLEN>0.
GOBまたはスライススタートコード（GBSC）の位置で始まるパケットの場合、冗長な画像ヘッダーがパケットに添付されているかどうかに応じて、PLENがゼロまたはゼロ以外になる場合があります。パケット損失率が非常に低い環境、または画像ヘッダーの内容がほとんど変更されない（H.263 +のGOBフレームID（GFID）構文から検出できる場合を除く）場合、画像ヘッダーの冗長コピーは必要ありません。ただし、あまり理想的でない状況では、エラー耐性を強化するために冗長な画像ヘッダーを添付する必要があり、その存在はPLEN> 0で示されます。
Assuming a PLEN of 9 and P=1, below is an example of a packet that begins with a byte-aligned GBSC or a Slice Start Code (SSC):
PLENが9でP = 1であると仮定すると、以下はバイト境界のGBSCまたはスライス開始コード（SSC）で始まるパケットの例です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0 0 1 0 0 1|PEBIT|1 0 0 0 0 0| picture header :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: starting with TR, PTYPE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | bitstream :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: data starting with GBSC/SSC without its first two 0 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notice that only the last six bits of the picture start code, '100000', are included in the payload header. A complete H.263+ picture header with byte aligned picture start code can be conveniently assembled, if needed, on the receiving end by prepending the sixteen leading '0' bits.
ペイロードヘッダーに含まれているのは、ピクチャスタートコードの最後の6ビット「100000」だけであることに注意してください。必要に応じて、先頭に16個の「0」ビットを付加することにより、バイトアライメントされたピクチャスタートコードを備えた完全なH.263 +ピクチャヘッダーを簡単にアセンブルできます。
For a packet that begins with an EOS or EOSBS code, PLEN shall be zero, and no Picture, GOB, or Slice start codes shall be included within the same packet. As with other packets beginning with start codes, the two all-zero bytes that begin the EOS or EOSBS code at the beginning of the packet shall be omitted, and their presence shall be indicated by setting the P bit to 1 in the payload header.
EOSまたはEOSBSコードで始まるパケットの場合、PLENはゼロであり、同じパケット内に画像、GOB、またはスライススタートコードが含まれていてはなりません。開始コードで始まる他のパケットと同様に、パケットの先頭でEOSまたはEOSBSコードを開始する2つのすべて0のバイトは省略され、その存在はペイロードヘッダーのPビットを1に設定することによって示されます。
System designers should be aware that some decoders may interpret the loss of a packet containing only EOS or EOSBS information as the loss of essential video data and may thus respond by not displaying some subsequent video information. Since EOS and EOSBS codes do not actually affect the decoding of video pictures, they are somewhat unnecessary to send at all. Because of the danger of misinterpretation of the loss of such a packet (which can be detected by the sequence number), encoders are generally to be discouraged from sending EOS and EOSBS.
システム設計者は、一部のデコーダーがEOSまたはEOSBS情報のみを含むパケットの損失を本質的なビデオデータの損失として解釈し、後続のビデオ情報を表示しないことで応答する場合があることに注意する必要があります。 EOSおよびEOSBSコードは実際にはビデオ画像のデコードに影響しないため、送信する必要はまったくありません。このようなパケット（シーケンス番号によって検出される可能性があります）の損失を誤って解釈する危険性があるため、エンコーダーは通常、EOSおよびEOSBSを送信しないようにしてください。
Below is an example of a packet containing an EOS code:
以下は、EOSコードを含むパケットの例です。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RR |1|V|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Follow-on Packet contains a number of bytes of coded H.263+ data that do not start at a synchronization point. That is, a Follow-on Packet does not start with a Picture, GOB, Slice, EOS, or EOSBS header, and it may or may not start at a macroblock boundary. Since Follow-on Packets do not start at synchronization points, the data at the beginning of a Follow-on Packet is not independently decodable. For such packets, P=0 always. If the preceding packet of a Follow-on Packet got lost, the receiver may discard that Follow-on Packet, as well as all other following Follow-on Packets. Better behavior, of course, would be for the receiver to scan the interior of the packet payload content to determine whether any start codes are found in the interior of the packet that can be used as resync points. The use of an attached copy of a picture header for a Follow-on Packet is useful only if the interior of the packet or some subsequent Follow-on Packet contains a resync code, such as a GOB or slice start code. PLEN>0 is allowed, since it may allow resync in the interior of the packet. The decoder may also be resynchronized at the next segment or picture packet.
後続パケットには、同期ポイントで開始しない、コード化されたH.263 +データのバイト数が含まれています。つまり、フォローオンパケットは、ピクチャ、GOB、スライス、EOS、またはEOSBSヘッダーで開始されず、マクロブロック境界で開始される場合と開始されない場合があります。後続パケットは同期ポイントで開始されないため、後続パケットの先頭のデータは個別にデコードできません。そのようなパケットの場合、常にP = 0です。後続パケットの先行パケットが失われた場合、受信者はその後続パケットだけでなく、後続の他のすべての後続パケットも破棄する可能性があります。もちろん、より良い動作は、レシーバーがパケットのペイロードコンテンツの内部をスキャンして、再同期ポイントとして使用できるパケットの内部に開始コードが見つかったかどうかを判断することです。後続パケットに画像ヘッダーの添付コピーを使用すると、パケットの内部または後続の後続パケットに、GOBやスライススタートコードなどの再同期コードが含まれている場合にのみ役立ちます。 PLEN> 0は、パケットの内部での再同期を許可する場合があるため、許可されます。デコーダはまた、次のセグメントまたは画像パケットで再同期されてもよい。
Here is an example of a Follow-on Packet (with PLEN=0):
以下は、PLEN = 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| RR |0|V|0|0|0|0|0|0|0|0|0| bitstream data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
There is no syntactical difference between a picture segment packet and a Follow-on Packet, other than the indication P=1 for picture segment or sequence ending packets and P=0 for Follow-on Packets. See the following for a summary of the entire packet types and ways to distinguish between them.
ピクチャセグメントパケットとシーケンス終了パケットの表示P = 1および後続パケットのP = 0以外は、ピクチャセグメントパケットと後続パケットの間に構文上の違いはありません。パケットタイプ全体の概要とそれらを区別する方法については、以下を参照してください。
It is possible to distinguish between the different packet types by checking the P bit and the first 6 bits of the payload along with the header information. The following table shows the packet type for permutations of this information (see also the picture/GOB/Slice header descriptions in H.263+ for details):
ヘッダー情報とともにペイロードのPビットと最初の6ビットをチェックすることで、異なるパケットタイプを区別できます。次の表は、この情報の順列のパケットタイプを示しています（詳細については、H.263 +のpicture / GOB / Sliceヘッダーの説明も参照してください）。
-------------+--------------+----------------------+----------------
First 6 bits | P-Bit | PLEN | Packet | Remarks
of Payload |(payload hdr.)| |
-------------+--------------+----------------------+----------------
100000 | 1 | 0 | Picture | Typical Picture
100000 | 1 | > 0 | Picture | Note UFEP
1xxxxx | 1 | 0 | GOB/Slice/EOS/EOSBS | See possible GNs
1xxxxx | 1 | > 0 | GOB/Slice | See possible GNs
Xxxxxx | 0 | 0 | Follow-on |
Xxxxxx | 0 | > 0 | Follow-on | Interior Resync
-------------+--------------+----------------------+----------------
The details regarding the possible values of the five bit Group Number (GN) field that follows the initial "1" bit when the P-bit is "1" for a GOB, Slice, EOS, or EOSBS packet are found in Section 5.2.3 of H.263 [H263].
GOB、スライス、EOS、またはEOSBSパケットのPビットが「1」の場合、最初の「1」ビットに続く5ビットのグループ番号（GN）フィールドの可能な値に関する詳細は、セクション5.2に記載されています。 H.263 [H263]の3。
As defined in this specification, every start of a coded frame (as indicated by the presence of a PSC) has to be encapsulated as a picture segment packet. If the whole coded picture fits into one packet of reasonable size (which is dependent on the connection characteristics), this is the only type of packet that may need to be used. Due to the high compression ratio achieved by H.263+, it is often possible to use this mechanism, especially for small spatial picture formats such as Quarter Common Intermediate Format (QCIF) and typical Internet packet sizes around 1500 bytes.
この仕様で定義されているように、（PSCの存在によって示される）コード化フレームのすべての開始は、画像セグメントパケットとしてカプセル化する必要があります。コード化された画像全体が（接続特性に依存する）妥当なサイズの1つのパケットに収まる場合、これが使用する必要がある唯一のタイプのパケットです。 H.263 +によって達成された高い圧縮率により、特にQuarter Common Intermediate Format（QCIF）などの小さな空間画像フォーマットや約1500バイトの一般的なインターネットパケットサイズに対して、このメカニズムを使用することがしばしば可能です。
If the complete coded frame does not fit into a single packet, two different ways for the packetization may be chosen. In case of very low or zero packet loss probability, one or more Follow-on Packets may be used for coding the rest of the picture. Doing so leads to minimal coding and packetization overhead, as well as to an optimal use of the maximal packet size, but does not provide any added error resilience.
完全なコード化フレームが単一のパケットに収まらない場合、パケット化に2つの異なる方法を選択できます。パケット損失確率が非常に低いかゼロの場合、1つ以上の後続パケットを使用して、残りの画像をコーディングできます。そうすることで、コーディングとパケット化のオーバーヘッドが最小限になり、最大パケットサイズが最適に使用されますが、エラー回復力は追加されません。
The alternative is to break the picture into reasonably small partitions, called Segments (by using the Slice or GOB mechanism), that do offer synchronization points. By doing so and using the Picture Segment payload with PLEN>0, decoding of the transmitted packets is possible even in cases in which the Picture packet containing the picture header was lost (provided any necessary reference picture is available). Picture Segment packets can also be used in conjunction with Follow-on Packets for large segment sizes.
代替策は、同期点を提供する（スライスまたはGOBメカニズムを使用して）セグメントと呼ばれるかなり小さなパーティションに画像を分割することです。これを行い、PLEN> 0の画像セグメントペイロードを使用することにより、画像ヘッダーを含む画像パケットが失われた場合でも、送信されたパケットのデコードが可能です（必要な参照画像が利用できる場合）。ピクチャセグメントパケットは、大きなセグメントサイズの後続パケットと組み合わせて使用することもできます。
This section specifies optional parameters that MAY be used to select optional features of the H.263 codec. The parameters are specified here as part of the Media Type registration for the ITU-T H.263 codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also provided for applications that use SDP. Multiple parameters SHOULD be expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
このセクションでは、H.263コーデックのオプション機能を選択するために使用できるオプションパラメータを指定します。パラメータは、ITU-T H.263コーデックのメディアタイプ登録の一部としてここで指定されます。 SDPを使用するアプリケーションでは、セッション記述プロトコル（SDP）[RFC4566]へのパラメーターのマッピングも提供されます。複数のパラメータは、parameter = valueペアのセミコロンで区切られたリストの形式で、メディアタイプ文字列として表現する必要があります。
This section describes the media types and names associated with this payload format. The section updates the previous registered version in RFC 3555 [RFC3555].
このセクションでは、このペイロード形式に関連付けられているメディアタイプと名前について説明します。このセクションは、RFC 3555 [RFC3555]で以前に登録されたバージョンを更新します。
Type name: video
タイプ名：ビデオ
Subtype name: H263-1998
サブタイプ名：H263-1998
Required parameters: None
必須パラメーター：なし
Optional parameters:
オプションのパラメーター：
SQCIF: Specifies the MPI (Minimum Picture Interval) for SQCIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
SQCIF：SQCIF解決のMPI（最小画像間隔）を指定します。許容値は1〜32の整数値で、1秒あたり30 /（1.001 *指定された値）フレームの最大フレームレートに対応します。
QCIF: Specifies the MPI (Minimum Picture Interval) for QCIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
QCIF：QCIF解像度のMPI（最小画像間隔）を指定します。許容値は1〜32の整数値で、1秒あたり30 /（1.001 *指定された値）フレームの最大フレームレートに対応します。
CIF: Specifies the MPI (Minimum Picture Interval) for CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
CIF：CIF解像度のMPI（最小画像間隔）を指定します。許容値は1〜32の整数値で、1秒あたり30 /（1.001 *指定された値）フレームの最大フレームレートに対応します。
CIF4: Specifies the MPI (Minimum Picture Interval) for 4CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
CIF4：4CIF解像度のMPI（最小画像間隔）を指定します。許容値は1〜32の整数値で、1秒あたり30 /（1.001 *指定された値）フレームの最大フレームレートに対応します。
CIF16: Specifies the MPI (Minimum Picture Interval) for 16CIF resolution. Permissible values are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 * the specified value) frames per second.
CIF16：16CIF解像度のMPI（最小画像間隔）を指定します。許容値は1〜32の整数値で、1秒あたり30 /（1.001 *指定された値）フレームの最大フレームレートに対応します。
CUSTOM: Specifies the MPI (Minimum Picture Interval) for a custom-defined resolution. The custom parameter receives three comma-separated values, Xmax, Ymax, and MPI. The Xmax and Ymax parameters describe the number of pixels in the X and Y axis and must be evenly divisible by 4. The permissible values for MPI are integer values from 1 to 32, which correspond to a maximum frame rate of 30/(1.001 *the specified value).
CUSTOM：カスタム定義の解像度のMPI（最小画像間隔）を指定します。カスタムパラメータは、Xmax、Ymax、MPIの3つのコンマ区切り値を受け取ります。 XmaxパラメータとYmaxパラメータは、X軸とY軸のピクセル数を示し、4で割り切れる必要があります。MPIの許容値は1〜32の整数値で、最大フレームレート30 /（1.001 *指定された値）。
A system that declares support of a specific MPI for one of the resolutions SHALL also implicitly support a lower resolution with the same MPI.
解像度の1つに対する特定のMPIのサポートを宣言するシステムは、同じMPIでより低い解像度を暗黙的にサポートする必要があります（SHALL）。
A list of optional annexes specifies which annexes of H.263 are supported. The optional annexes are defined as part of H263-1998, H263-2000. H.263 annex X [H263] defines profiles that group annexes for specific applications. A system that supports a specific annex SHALL specify its support using the optional parameters. If no annex is specified, then the stream is Baseline H.263.
オプションの附属書のリストは、H.263のどの附属書がサポートされるかを指定します。オプションの附属書は、H263-1998、H263-2000の一部として定義されています。 H.263附属書X [H263]は、特定のアプリケーションの附属書をグループ化するプロファイルを定義しています。特定の附属書をサポートするシステムは、オプションのパラメーターを使用してサポートを指定する必要があります。附属書が指定されていない場合、ストリームはベースラインH.263です。
The allowed optional parameters for the annexes are "F", "I", "J", "T", "K", "N", and "P".
別館で使用できるオプションのパラメータは、「F」、「I」、「J」、「T」、「K」、「N」、「P」です。
"F", "I", "J", and "T" if supported, SHALL have the value "1". If not supported, they should not be listed or SHALL have the value "0".
「F」、「I」、「J」、および「T」は、サポートされている場合、値「1」を持つ必要があります。サポートされていない場合は、リストに含めないか、値「0」にする必要があります。
"K" can receive one of four values 1 - 4:
「K」は、1〜4の4つの値のいずれかを受け取ります。
1: Slices In Order, Non-Rectangular
1：順番にスライス、非長方形
2: Slices In Order, Rectangular
2：スライスの順序、長方形
3: Slices Not Ordered, Non-Rectangular
3：スライスの順序付けなし、非長方形
4: Slices Not Ordered, Rectangular
4：スライスの順序付けなし、長方形
"N": Reference Picture Selection mode - Four numeric choices (1 - 4) are available, representing the following modes:
「N」：参照画像選択モード-次のモードを表す4つの数値の選択肢（1〜4）を使用できます。
1: NEITHER: No back-channel data is returned from the decoder to the encoder.
1：いずれも：デコーダからエンコーダにバックチャネルデータが返されません。
2: ACK: The decoder returns only acknowledgment messages.
2：ACK：デコーダは確認応答メッセージのみを返します。
3: NACK: The decoder returns only non-acknowledgment messages.
3：NACK：デコーダーは非確認応答メッセージのみを返します。
4: ACK+NACK: The decoder returns both acknowledgment and non-acknowledgment messages.
4：ACK + NACK：デコーダーは、確認応答メッセージと非確認応答メッセージの両方を返します。
No special provision is made herein for carrying back channel information. The Extended RTP Profile for RTCP-based Feedback [RFC4585] MAY be used as a back channel mechanism.
ここでは、チャネル情報を戻すための特別な規定はありません。 RTCPベースのフィードバックの拡張RTPプロファイル[RFC4585]は、バックチャネルメカニズムとして使用できます。
"P": Reference Picture Resampling, in which the following submodes are represented as a number from 1 to 4:
"P"：参照画像のリサンプリング。次のサブモードは1〜4の数値として表されます。
1: dynamicPictureResizingByFour
1：dynamicPictureResizingByFour
2: dynamicPictureResizingBySixteenthPel
3: dynamicWarpingHalfPel
3：dynamicWarpingHalfPel
4: dynamicWarpingSixteenthPel
4：dynamicWarpingSixteenthPel
Example: P=1,3
例：P = 1,3
PAR: Arbitrary Pixel Aspect Ratio. Defines the width:height ratio by two colon-separated integers between 0 and 255. Default ratio is 12:11, if not otherwise specified.
PAR：任意のピクセルアスペクト比。幅と高さの比率を、コロンで区切られた2つの整数（0〜255）で定義します。特に指定がない場合、デフォルトの比率は12:11です。
CPCF: Arbitrary (Custom) Picture Clock Frequency: CPCF is a comma-separated list of eight parameters specifying a custom picture clock frequency and the MPI (minimum picture interval) for the supported picture sizes when using that picture clock frequency. The first two parameters are cd, which is an integer from 1 to 127, and cf, which is either 1000 or 1001. The custom picture clock frequency is given by the formula 1800000/(cd*cf) provided in the RTP Timestamp semantics in Section 3.1 above (as specified in H.263 section 5.1.7). Following the values of cd and cf, the remaining six parameters are SQCIFMPI, QCIFMPI, CIFMPI, CIF4MPI, CIF16MPI, and CUSTOMMPI, which each specify an integer MPI (minimum picture interval) for the standard picture sizes SQCIF, QCIF, CIF, 4CIF, 16CIF, and CUSTOM, respectively, as described above. The MPI value indicates a maximum frame rate of 1800000/(cd*cf*MPI) frames per second for MPI parameters having a value in the range from 1 to 2048, inclusive. An MPI value of 0 specifies that the associated picture size is not supported for the custom picture clock frequency. If the CUSTOMMPI parameter is not equal to 0, the CUSTOM parameter SHALL also be present (so that the Xmax and Ymax dimensions of the custom picture size are defined).
CPCF：任意（カスタム）の画像クロック周波数：CPCFは、その画像クロック周波数を使用するときにサポートされる画像サイズのカスタム画像クロック周波数とMPI（最小画像間隔）を指定する8つのパラメーターのコンマ区切りリストです。最初の2つのパラメータは、1〜127の整数であるcdと、1000または1001のいずれかであるcfです。カスタムピクチャクロック周波数は、次の式のRTPタイムスタンプセマンティクスで提供される式1800000 /（cd * cf）で指定されます。上記のセクション3.1（H.263セクション5.1.7で指定）。 cdとcfの値に続いて、残りの6つのパラメーターはSQCIFMPI、QCIFMPI、CIFMPI、CIF4MPI、CIF16MPI、およびCUSTOMMPIで、それぞれ標準の画像サイズSQCIF、QCIF、CIF、4CIFの整数MPI（最小画像間隔）を指定します。上記のように、それぞれ16CIFおよびCUSTOM。 MPI値は、1から2048までの範囲の値を持つMPIパラメータの最大フレームレート1800000 /（cd * cf * MPI）フレーム/秒を示します。 MPI値0は、関連する画像サイズがカスタム画像クロック周波数でサポートされていないことを示します。 CUSTOMMPIパラメータが0でない場合は、CUSTOMパラメータも存在する必要があります（そのため、カスタム画像サイズのXmaxおよびYmax寸法が定義されます）。
BPP: BitsPerPictureMaxKb. Maximum number of bits in units of 1024 bits allowed to represent a single picture. If this parameter is not present, then the default value, based on the maximum supported resolution, is used. BPP is integer value between 0 and 65536.
BPP：BitsPerPictureMaxKb。 1つの画像を表すために許可されている1024ビット単位の最大ビット数。このパラメーターが存在しない場合は、サポートされている最大解像度に基づくデフォルト値が使用されます。 BPPは0〜65536の整数値です。
HRD: Hypothetical Reference Decoder. See annex B of H.263 specification [H263]. This parameter, if supported, SHALL have the value "1". If not supported, it should not be listed or SHALL have the value "0".
HRD：仮想参照デコーダー。 H.263仕様の付録B [H263]を参照してください。このパラメータは、サポートされている場合、値「1」を持つ必要があります。サポートされていない場合は、リストされていないか、値が「0」である必要があります。
Encoding considerations:
エンコードに関する考慮事項：
This media type is framed and binary; see Section 4.8 in [RFC4288]
このメディアタイプはフレーム付きでバイナリです。 [RFC4288]のセクション4.8をご覧ください
Security considerations: See Section 11 of RFC 4629
セキュリティに関する考慮事項：RFC 4629のセクション11をご覧ください
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.263 stream without any of the annexes. Most decoders support at least QCIF and CIF fixed resolutions, and they are expected to be available almost in every H.263-based video application.
これらはレシーバーオプションです。現在の実装では、SDPでオプションのパラメーターを送信しません。それらはオプションのパラメータを無視し、付属資料なしでH.263ストリームをエンコードします。ほとんどのデコーダは、少なくともQCIFおよびCIFの固定解像度をサポートしており、ほとんどすべてのH.263ベースのビデオアプリケーションで利用できると予想されています。
Published specification: RFC 4629
公開された仕様：RFC 4629
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Audio and video streaming and conferencing tools.
オーディオとビデオのストリーミングおよび会議ツール。
Additional information: None
追加情報：なし
Person and email address to contact for further information:
詳細について連絡する人とメールアドレス：
Roni Even: roni.even@polycom.co.il
Roni Even：roni.even@polycom.co.il
Intended usage: COMMON
使用目的：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 [RFC 3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。
Author: Roni Even
作成者：Roni Even
Change controller:
コントローラを変更：
IETF Audio/Video Transport working group, delegated from the IESG.
IESGから委任されたIETF Audio / Video Transportワーキンググループ。
Type name: video
タイプ名：ビデオ
Subtype name: H263-2000
サブタイプ名：H263-2000
Required parameters: None
必須パラメーター：なし
Optional parameters:
オプションのパラメーター：
The optional parameters of the H263-1998 type MAY be used with this media subtype. Specific optional parameters that may be used with the H263-2000 type are as follows:
H263-1998タイプのオプションパラメータは、このメディアサブタイプで使用できます。 H263-2000タイプで使用できる特定のオプションパラメータは次のとおりです。
PROFILE: H.263 profile number, in the range 0 through 10, specifying the supported H.263 annexes/subparts based on H.263 annex X [H263]. The annexes supported in each profile are listed in table X.1 of H.263 annex X. If no profile or H.263 annex is specified, then the stream is Baseline H.263 (profile 0 of H.263 annex X).
PROFILE：H.263プロファイル番号。0〜10の範囲で、H.263 annex X [H263]に基づいてサポートされているH.263付属/サブパーツを指定します。各プロファイルでサポートされる付録は、H.263付録Xの表X.1にリストされています。プロファイルまたはH.263付録が指定されていない場合、ストリームはベースラインH.263（H.263付録Xのプロファイル0）です。
LEVEL: Level of bitstream operation, in the range 0 through 100, specifying the level of computational complexity of the decoding process. The level are described in table X.2 of H.263 annex X.
LEVEL：ビットストリーム操作のレベル。範囲は0〜100で、デコードプロセスの計算の複雑さのレベルを指定します。レベルは、H.263附属書Xの表X.2に記載されています。
According to H.263 annex X, support of any level other than level 45 implies support of all lower levels. Support of level 45 implies support of level 10.
H.263附属書Xによると、レベル45以外のレベルのサポートは、すべての下位レベルのサポートを意味します。レベル45のサポートは、レベル10のサポートを意味します。
A system that specifies support of a PROFILE MUST specify the supported LEVEL.
PROFILEのサポートを指定するシステムは、サポートされるLEVELを指定する必要があります。
INTERLACE: Interlaced or 60 fields indicates the support for interlace display mode, as specified in H.263 annex W.6.3.11. This parameter, if supported SHALL have the value "1". If not supported, it should not be listed or SHALL have the value "0".
INTERLACE：H.263 annex W.6.3.11で指定されているように、インターレースまたは60フィールドはインターレース表示モードのサポートを示します。このパラメーターは、サポートされている場合、値「1」を持つ必要があります。サポートされていない場合は、リストされていないか、値が「0」である必要があります。
Encoding considerations:
エンコードに関する考慮事項：
This media type is framed and binary; see Section 4.8 in [RFC4288]
このメディアタイプはフレーム付きでバイナリです。 [RFC4288]のセクション4.8をご覧ください
Security considerations: See Section 11 of RFC 4629 Interoperability considerations:
セキュリティに関する考慮事項：RFC 4629の相互運用性に関する考慮事項のセクション11をご覧ください。
The optional parameters PROFILE and LEVEL SHALL NOT be used with any of the other optional parameters.
オプションパラメータPROFILEおよびLEVELは、他のオプションパラメータと一緒に使用することはできません。
Published specification: RFC 4629
公開された仕様：RFC 4629
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Audio and video streaming and conferencing tools.
オーディオとビデオのストリーミングおよび会議ツール。
Additional information: None
追加情報：なし
Person and email address to contact for further information :
詳細について連絡する人とメールアドレス：
Roni Even: roni.even@polycom.co.il
Roni Even：roni.even@polycom.co.il
Intended usage: COMMON
使用目的：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 [RFC 3550]を介した転送に対してのみ定義されます。現在、他のフレーミングプロトコル内のトランスポートは定義されていません。
Author: Roni Even
作成者：Roni Even
Change controller:
コントローラを変更：
IETF Audio/Video Transport working group delegated from the IESG.
IESGから委任されたIETF Audio / Video Transportワーキンググループ。
The media types video/H263-1998 and video/H263-2000 are mapped to fields in the Session Description Protocol (SDP) as follows:
メディアタイプvideo / H263-1998およびvideo / H263-2000は、次のようにセッション記述プロトコル（SDP）のフィールドにマップされます。
o The media name in the "m=" line of SDP MUST be video.
o SDPの「m =」行のメディア名はビデオである必要があります。
o The encoding name in the "a=rtpmap" line of SDP MUST be H263-1998 or H263-2000 (the media subtype).
o SDPの「a = rtpmap」行のエンコーディング名は、H263-1998またはH263-2000（メディアサブタイプ）でなければなりません。
o The clock rate in the "a=rtpmap" line MUST be 90000.
o 「a = rtpmap」行のクロックレートは90000でなければなりません。
o The optional parameters, if any, MUST be included in the "a=fmtp" line of SDP. These parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs. The optional parameters PROFILE and LEVEL SHALL NOT be used with any of the other optional parameters.
o オプションのパラメーターがある場合は、SDPの「a = fmtp」行に含める必要があります。これらのパラメータは、parameter = valueペアのセミコロンで区切られたリストの形式で、メディアタイプ文字列として表されます。オプションパラメータPROFILEおよびLEVELは、他のオプションパラメータと一緒に使用することはできません。
For offering H.263 over RTP using SDP in an Offer/Answer model [RFC3264], the following considerations are necessary.
オファー/アンサーモデル[RFC3264]でSDPを使用してH.263 over RTPを提供するには、次の考慮事項が必要です。
Codec options (F,I,J,K,N,P,T): These options MUST NOT appear unless the sender of these SDP parameters is able to decode those options. These options designate receiver capabilities even when sent in a "sendonly" offer.
コーデックオプション（F、I、J、K、N、P、T）：これらのオプションは、これらのSDPパラメーターの送信者がこれらのオプションをデコードできる場合を除き、表示してはなりません（MUST NOT）。これらのオプションは、「sendonly」オファーで送信された場合でも、レシーバー機能を指定します。
Profile: The offer of a SDP profile parameter signals that the offerer can decode a stream that uses the specified profile. Each profile uses different H.263 annexes, so there is no implied relationship between them. An answerer SHALL NOT change the profile parameter and MUST reject the payload type containing an unsupported profile. A decoder that supports a profile SHALL also support H.263 baseline profile (profile 0). An offerer is RECOMMENDED to offer all the different profiles it is interested to use as individual payload types. In addition an offerer, sending an offer using the PROFILE optional parameter, is RECOMMENDED to offer profile 0, as this will enable communication, and in addition allows an answerer to add those profiles it does support in an answer.
プロファイル：SDPプロファイルパラメータの提供は、提供者が指定されたプロファイルを使用するストリームをデコードできることを示します。各プロファイルは異なるH.263附属書を使用するため、それらの間に暗黙の関係はありません。応答者はプロファイルパラメータを変更してはならず（SHALL NOT）、サポートされていないプロファイルを含むペイロードタイプを拒否する必要があります。プロファイルをサポートするデコーダは、H.263ベースラインプロファイル（プロファイル0）もサポートする必要があります（SHALL）。提供者は、個々のペイロードタイプとして使用したいすべての異なるプロファイルを提供することをお勧めします。さらに、PROFILEオプションパラメータを使用してオファーを送信するオファー提供者は、プロファイル0を提供することをお勧めします。これにより、通信が可能になり、さらに、回答者がサポートするプロファイルを回答に追加できるようになります。
LEVEL: The LEVEL parameter in an offer indicates the maximum computational complexity supported by the offerer in performing decoding for the given PROFILE. An answerer MAY change the value (both up and down) of the LEVEL parameter in its answer to indicate the highest value it supports.
LEVEL：オファーのLEVELパラメーターは、特定のプロファイルのデコードを実行する際にオファー側がサポートする最大の計算の複雑さを示します。回答者は、回答のLEVELパラメータの値（上下両方）を変更して、サポートする最大値を示すことができます（MAY）。
INTERLACE: The parameter MAY be included in either offer or answer to indicate that the offerer or answerer respectively supports reception of interlaced content. The inclusion in either offer or answer is independent of each other.
INTERLACE：オファーまたはアンサーのいずれかにパラメーターを含めて、提供者または回答者がそれぞれインターレースコンテンツの受信をサポートしていることを示す場合があります。オファーまたはアンサーに含めることは、互いに独立しています。
Picture sizes and MPI: Supported picture sizes and their corresponding minimum picture interval (MPI) information for H.263 can be combined. All picture sizes can be advertised to the other party, or only a subset. The terminal announces only those picture sizes (with their MPIs) which it is willing to receive. For example, MPI=2 means that the maximum (decodable) picture rate per second is 15/1.001 (approximately 14.985).
画像サイズとMPI：サポートされている画像サイズと、対応するH.263の最小画像間隔（MPI）情報を組み合わせることができます。すべての画像サイズを相手に、またはサブセットのみにアドバタイズできます。端末は、受信できる画像サイズ（MPIを含む）のみを通知します。たとえば、MPI = 2は、1秒あたりの最大（デコード可能）画像レートが15 / 1.001（約14.985）であることを意味します。
If the receiver does not specify the picture size/MPI optional parameter, then it SHOULD be ready to receive QCIF resolution with MPI=1.
レシーバーが画像サイズ/ MPIオプションパラメーターを指定しない場合、MPI = 1でQCIF解像度を受信する準備ができている必要があります。
Parameters offered first are the most preferred picture mode to be received.
最初に提供されるパラメータは、受信される最も好ましい画像モードです。
Here is an example of the usage of these parameters:
これらのパラメータの使用例を次に示します。
CIF=4;QCIF=3;SQCIF=2;CUSTOM=360,240,2
This means that the encoder SHOULD send CIF picture size, which it can decode at MPI=4. If that is not possible, then QCIF with MPI value 3 should be sent; if neither are possible, then SQCIF with MPI value=2. The receiver is capable of (but least preferred) decoding custom picture sizes (max 360x240) with MPI=2. Note that most decoders support at least QCIF and CIF fixed resolutions, and that they are expected to be available almost in every H.263-based video application.
これは、エンコーダーがCIF画像サイズを送信する必要があることを意味します。これは、MPI = 4でデコードできます。それが不可能な場合は、MPI値3のQCIFを送信する必要があります。どちらも可能でない場合は、MPI値= 2のSQCIF。レシーバーは、MPI = 2でカスタムピクチャサイズ（最大360x240）をデコードできます（ただし、推奨されません）。ほとんどのデコーダーは少なくともQCIFおよびCIFの固定解像度をサポートしており、ほとんどすべてのH.263ベースのビデオアプリケーションで利用できると予想されていることに注意してください。
Below is an example of H.263 SDP in an offer:
以下は、オファー内のH.263 SDPの例です。
a=fmtp:xx CIF=4;QCIF=2;F=1;K=1
This means that the sender of this message can decode an H.263 bit stream with the following options and parameters: preferred resolution is CIF (at up to 30/4.004 frames per second), but if that is not possible then QCIF size is also supported (at up to 30/2.002 frames per second). Advanced Prediction mode (AP) and slicesInOrder-NonRect options MAY be used.
つまり、このメッセージの送信者は、次のオプションとパラメーターを使用してH.263ビットストリームをデコードできます。優先解像度はCIF（最大30 / 4.004フレーム/秒）ですが、それが不可能な場合はQCIFサイズも使用できます。サポートされています（最大30 / 2.002フレーム/秒）。 Advanced Prediction mode（AP）およびslicesInOrder-NonRectオプションを使用できます。
Below is an example of H.263 SDP in an offer that includes the CPCF parameter.
以下は、CPCFパラメータを含むオファーのH.263 SDPの例です。
a=fmtp:xx CPCF=36,1000,0,1,1,0,0,2;CUSTOM=640,480,2;CIF=1;QCIF=1
This means that the sender of this message can decode an H.263 bit stream with a preferred custom picture size of 640x480 at a maximum frame rate of 25 frames per second using a custom picture clock frequency of 50 Hz. If that is not possible, then the 640x480 picture size is also supported at up to 30/2.002 frames per second using the ordinary picture clock frequency of 30/1.001 Hz. If neither of those is possible, then the CIF and QCIF picture sizes are also supported at up to 50 frames per second using the custom picture clock frequency of 50 Hz or up to 30/1.001 frames per second using the ordinary picture clock frequency of 30/1.001 Hz, and CIF is preferred over QCIF.
つまり、このメッセージの送信者は、50 Hzのカスタム画像クロック周波数を使用して、毎秒25フレームの最大フレームレートで640x480の優先カスタム画像サイズのH.263ビットストリームをデコードできます。それが不可能な場合は、通常の画像クロック周波数30 / 1.001 Hzを使用して、640x480の画像サイズも最大30 / 2.002フレーム/秒でサポートされます。これらのどちらも可能でない場合、CIFおよびQCIFの画像サイズは、50 Hzのカスタム画像クロック周波数を使用して最大50フレーム/秒、または通常の画像クロック周波数30を使用して最大30 / 1.001フレーム/秒でサポートされます。 /1.001 Hz、CIFはQCIFよりも優先されます。
The following limitation applies for usage of these media types when performing offer/answer for sessions using multicast transport. An answerer SHALL NOT change any of the parameters in an answer, instead if the indicated values are not supported the payload type MUST be rejected.
マルチキャストトランスポートを使用してセッションのオファー/アンサーを実行するときのこれらのメディアタイプの使用には、次の制限が適用されます。回答者は回答のパラメータを変更してはならず（SHALL NOT）、代わりに、示された値がサポートされていない場合は、ペイロードタイプを拒否する必要があります。
The current document is a revision of RFC 2429 and obsoletes it. This section will address the backward compatibility issues.
現在のドキュメントはRFC 2429の改訂版であり、廃止されました。このセクションでは、下位互換性の問題について説明します。
The document adds new optional parameters to the H263-1998 and H263- 2000 payload type, defined in RFC 3555 [RFC3555]. Since these are optional parameters we expect that old implementations will ignore these parameters, and that new implementations that will receive the H263-1998 and H263-2000 payload types with no parameters will behave as if the other side can accept H.263 at QCIF resolution at a frame rate not exceeding 15/1.001 (approximately 14.985) frames per second.
このドキュメントは、RF3 3555 [RFC3555]で定義されているH263-1998およびH263- 2000ペイロードタイプに新しいオプションパラメータを追加します。これらはオプションのパラメーターであるため、古い実装はこれらのパラメーターを無視し、パラメーターなしでH263-1998およびH263-2000ペイロードタイプを受信する新しい実装は、反対側がQCIF解決でH.263を受け入れることができるかのように動作します。 15 / 1.001（約14.985）フレーム/秒を超えないフレームレート。
This document updates the H.263 (1998) and H.263 (2000) media types, described in RFC 3555 [RFC3555]. The updated media type registrations are in Section 8.1.
このドキュメントは、RFC 3555 [RFC3555]で説明されているH.263（1998）およびH.263（2000）メディアタイプを更新します。更新されたメディアタイプ登録はセクション8.1にあります。
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile (for example, [RFC3551]). This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed after compression, so there is no conflict between the two operations.
この仕様で定義されたペイロード形式を使用するRTPパケットは、RTP仕様[RFC3550]および適切なRTPプロファイル（[RFC3551]など）で説明されているセキュリティの考慮事項に従います。これは、メディアストリームの機密性が暗号化によって達成されることを意味します。このペイロード形式で使用されるデータ圧縮はエンドツーエンドで適用されるため、圧縮後に暗号化を実行できるため、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.
受信側の計算負荷が均一でない圧縮技術を使用したデータエンコーディングには、潜在的なサービス拒否の脅威が存在します。攻撃者は、復号化が複雑な病理学的データグラムをストリームに挿入し、レシーバーを過負荷にする可能性があります。少なくともRTPパケットの認証の使用が推奨されます。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [RFC2032] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
他のIPベースのプロトコルと同様に、状況によっては、受信側は、必要以上に多くのパケットを受信しただけで過負荷になる場合があります。ネットワーク層認証は、望ましくないソースからのパケットを破棄するために使用できますが、認証自体の処理コストが高すぎる可能性があります。マルチキャスト環境では、特定のソースのプルーニングがIGMP [RFC2032]の将来のバージョンとマルチキャストルーティングプロトコルに実装され、受信者が到達可能なソースを選択できるようになります。
A security review of this payload format found no additional considerations beyond those in the RTP specification.
このペイロード形式のセキュリティレビューでは、RTP仕様以外の考慮事項は見つかりませんでした。
This is to acknowledge the work done by Chad Zhu, Linda Cline, Gim Deisher, Tom Gardos, Christian Maciocco, and Donald Newell from Intel Corp., who co-authored RFC 2429.
これは、RFC 2429を共同執筆したIntel Corp.のChad Zhu、Linda Cline、Gim Deisher、Tom Gardos、Christian Maciocco、およびDonald Newellの功績を認めるものです。
We would also like to acknowledge the work of Petri Koskelainen from Nokia and Nermeen Ismail from Cisco, who helped with composing the text for the new media types.
また、新しいメディアタイプのテキストの作成を支援してくれた、NokiaのPetri KoskelainenとCiscoのNermeen Ismailの仕事にも感謝します。
The changes from the RFC 2429 are:
RFC 2429からの変更点は次のとおりです。
1. The H.263 1998 and 2000 media type are now in the payload specification.
1. H.263 1998および2000メディアタイプがペイロード仕様に含まれるようになりました。
2. Added optional parameters to the H.263 1998 and 2000 media types.
2. H.263 1998および2000メディアタイプにオプションパラメータを追加しました。
3. Mandate the usage of RFC 2429 for all H.263. RFC 2190 payload format should be used only to interact with legacy systems.
3. すべてのH.263に対してRFC 2429の使用を義務付けます。 RFC 2190ペイロード形式は、レガシーシステムとやり取りする場合にのみ使用してください。
This document adds new optional parameters to the H263-1998 and H263-2000 payload types.
このドキュメントでは、H263-1998およびH263-2000ペイロードタイプに新しいオプションパラメータを追加しています。
[H263] International Telecommunications Union - Telecommunication Standardization Sector, "Video coding for low bit rate communication", ITU-T Recommendation H.263, January 2005.
[H263]国際電気通信連合-電気通信標準化部門、「低ビットレート通信用のビデオコーディング」、ITU-T勧告H.263、2005年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[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プロファイル」、STD 65、RFC 3551、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タイプ登録」、RFC 3555、2003年7月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC2032] Turletti, T., "RTP Payload Format for H.261 Video Streams", RFC 2032, October 1996.
[RFC2032] Turletti、T。、「RTP Payload Format for H.261 Video Streams」、RFC 2032、1996年10月。
[RFC2190] Zhu, C., "RTP Payload Format for H.263 Video Streams", RFC 2190, September 1997.
[RFC2190]朱C。、「RTP Payload Format for H.263 Video Streams」、RFC 2190、1997年9月。
[RFC2429] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
[RFC2429] Bormann、C.、Cline、L.、Deisher、G.、Gardos、T.、Maciocco、C.、Newell、D.、Ott、J.、Sullivan、G.、Wenger、S。、およびC Zhu、「1998バージョンのITU-T Rec。H.263ビデオ（H.263 +）のRTPペイロード形式」、RFC 2429、1998年10月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、2002年6月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、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] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、2006年7月。
[RFC4628] Even, R., "RTP Payload Format for H.263 Moving RFC 2190 to Historic Status", RFC 4628, January 2007.
[RFC4628]でも、R。、「RFC 2190を歴史的なステータスに移行するH.263のRTPペイロード形式」、RFC 4628、2007年1月。
[Vredun] Wenger, S., "Video Redundancy Coding in H.263+", Proc. Audio-Visual Services over Packet Networks, Aberdeen, U.K. 9/1997, September 1997.
[Vredun] Wenger、S。、「H.263 +でのビデオ冗長コーディング」、Proc。パケットネットワーク上のオーディオビジュアルサービス、アバディーン、イギリス9 / 1997、1997年9月。
Authors' Addresses
著者のアドレス
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 02015 TKK, Finland
Joerg Ott Helsinki University of Technology Networking Laboratory PO Box 3000 02015 TKK、フィンランド
EMail: jo@netlab.tkk.fi
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, GERMANY
Carsten Bormann Universitaet Bremen TZI PO Box 330440 D-28334ブレーメン、ドイツ
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Gary Sullivan Microsoft Corp. One Microsoft Way Redmond, WA 98052 USA
がｒｙ すっぃゔぁん みｃろそｆｔ こｒｐ。 おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ うさ
EMail: garysull@microsoft.com
Stephan Wenger Nokia Research Center P.O. Box 100 33721 Tampere Finland
ステファンウェンガーノキアリサーチセンターP.O.ボックス100 33721タンペレフィンランド
EMail: stewe@stewe.org
Roni Even (editor) Polycom 94 Derech Em Hamoshavot Petach Tikva 49130 Israel
Roni Even（編集者）Polycom 94 Derech Em Hamoshavot Petach Tikva 49130イスラエル
EMail: roni.even@polycom.co.il
Full Copyright Statement
完全な著作権表示
Copyright (C) The IETF Trust (2007).
Copyright（C）IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネット社会、IETFトラスト、およびインターネットエンジニアリングタスクフォースはすべてを否認します。明示または黙示を問わず、ここに含まれる情報の使用が商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害しないことを保証するものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許申請、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。