RFC1890 日本語訳
1890 RTP Profile for Audio and Video Conferences with Minimal Control.Audio-Video Transport Working Group, H. Schulzrinne. January 1996. (Format: TXT=37509 bytes) (Obsoleted by RFC3551) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Audio-Video Transport Working Group
Request for Comments: 1890 H. Schulzrinne
Category: Standards Track GMD Fokus
January 1996
コメントを求めるワーキンググループオーディオのビデオ輸送ワーキンググループ要求をネットワークでつないでください: 1890時間Schulzrinneカテゴリ: 標準化過程GMD Fokus1996年1月
RTP Profile for Audio and Video Conferences with Minimal Control
最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings.
このメモはリアルタイムのトランスポート・プロトコル(RTP)、バージョン2、および関連制御プロトコルの使用のためのプロフィールについて説明します、RTCP、最小量のコントロールとのオーディオとビデオ「マルチ-関係者」会議の中で。 それはオーディオとテレビ会議システムに適したRTP仕様の中でジェネリック分野の解釈を提供します。 特に、このドキュメントは1セットのデフォルトマッピングをペイロード形式数からencodingsまで定義します。
The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
また、ドキュメントはオーディオとビデオ・データがRTPの中でどう運ばれるかもしれないかを説明します。 RTPの中で使用されると、それは標準のencodingsと彼らの名前の1セットを定義します。 しかしながら、コード化定義は特定の移送機構の如何にかかわらず使用されます。 記述は参照実装と詳細な規格に指針を提供します。 このドキュメントはオーディオ、ビデオ、および他のリアルタイムのマルチメディア応用の作成者のための援助として意味されます。
1. Introduction
1. 序論
This profile defines aspects of RTP left unspecified in the RTP Version 2 protocol definition (RFC 1889). This profile is intended for the use within audio and video conferences with minimal session control. In particular, no support for the negotiation of parameters or membership control is provided. The profile is expected to be useful in sessions where no negotiation or membership control are used (e.g., using the static payload types and the membership indications provided by RTCP), but this profile may also be useful in conjunction with a higher-level control protocol.
このプロフィールはRTPバージョン2プロトコル定義(RFC1889)で不特定の状態で残っているRTPの局面を定義します。 このプロフィールは使用のためにオーディオとテレビ会議システムの中で最小量のセッション制御で意図します。 特に、パラメタか会員資格コントロールの交渉のサポートを全く提供しません。 プロフィールがセッションのときに交渉でない会員資格コントロールがないのが使用されている(例えば、静的なペイロードタイプとRTCPによって提供された会員資格指摘を使用します)ところで役に立つと予想されますが、このプロフィールもまた、よりハイレベルの制御プロトコルに関連して役に立つかもしれません。
Schulzrinne Standards Track [Page 1] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[1ページ]
Use of this profile occurs by use of the appropriate applications; there is no explicit indication by port number, protocol identifier or the like.
このプロフィールの使用は適切なアプリケーションの使用で起こります。 ポートナンバー、プロトコル識別子または同様のものによるどんな明白な指示もありません。
Other profiles may make different choices for the items specified here.
他のプロフィールで、ここで項目のための異なった選択を指定するかもしれません。
2. RTP and RTCP Packet Forms and Protocol Behavior
2. RTP、RTCPパケット用紙、およびプロトコルの振舞い
The section "RTP Profiles and Payload Format Specification" enumerates a number of items that can be specified or modified in a profile. This section addresses these items. Generally, this profile follows the default and/or recommended aspects of the RTP specification.
「RTPプロフィールと有効搭載量書式仕様」というセクションはプロフィールで指定するか、または変更できる件数を列挙します。 このセクションはこれらの項目を扱います。一般に、このプロフィールはRTP仕様のデフォルト、そして/または、お勧めの局面に続きます。
RTP data header: The standard format of the fixed RTP data header is
used (one marker bit).
RTPデータヘッダー: 固定RTPデータヘッダーの標準書式は(1マーカービット)使用されます。
Payload types: Static payload types are defined in Section 6.
有効搭載量は以下をタイプします。 静的なペイロードタイプはセクション6で定義されます。
RTP data header additions: No additional fixed fields are appended to
the RTP data header.
RTPデータヘッダー追加: どんな追加固定野原もRTPデータヘッダーに追加しません。
RTP data header extensions: No RTP header extensions are defined, but
applications operating under this profile may use such
extensions. Thus, applications should not assume that the RTP
header X bit is always zero and should be prepared to ignore the
header extension. If a header extension is defined in the
future, that definition must specify the contents of the first
16 bits in such a way that multiple different extensions can be
identified.
RTPデータヘッダー拡張子: RTPヘッダー拡張子は全く定義されませんが、このプロフィールの下で作動するアプリケーションはそのような拡張子を使用するかもしれません。 したがって、アプリケーションは、RTPヘッダーXビットがいつもゼロであり、ヘッダー拡大を無視するように準備されるべきであると仮定するべきではありません。 ヘッダー拡大が将来定義されるなら、その定義は複数の異なった拡大を特定できるような方法で最初の16ビットのコンテンツを指定しなければなりません。
RTCP packet types: No additional RTCP packet types are defined by
this profile specification.
RTCPパケットはタイプされます: どんな追加RTCPパケットタイプもこのプロフィール仕様で定義されません。
RTCP report interval: The suggested constants are to be used for the
RTCP report interval calculation.
RTCPは間隔を報告します: 提案された定数はRTCPレポート間隔計算に使用されることです。
SR/RR extension: No extension section is defined for the RTCP SR or
RR packet.
SR/RR拡張子: 拡大部は全くRTCP SRかRRパケットのために定義されません。
SDES use: Applications may use any of the SDES items described.
While CNAME information is sent every reporting interval, other
items should be sent only every fifth reporting interval.
SDES使用: アプリケーションは項目が説明したSDESのいずれも使用するかもしれません。 あらゆる報告間隔CNAME情報を送る間、あらゆるだけ5番目に報告している間隔を他の項目に送るべきです。
Security: The RTP default security services are also the default
under this profile.
セキュリティ: また、RTPデフォルトセキュリティー・サービスはこのプロフィールの下のデフォルトです。
Schulzrinne Standards Track [Page 2] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[2ページ]
String-to-key mapping: A user-provided string ("pass phrase") is
hashed with the MD5 algorithm to a 16-octet digest. An n-bit key
is extracted from the digest by taking the first n bits from the
digest. If several keys are needed with a total length of 128
bits or less (as for triple DES), they are extracted in order
from that digest. The octet ordering is specified in RFC 1423,
Section 2.2. (Note that some DES implementations require that
the 56-bit key be expanded into 8 octets by inserting an odd
parity bit in the most significant bit of the octet to go with
each 7 bits of the key.)
ストリングから重要へのマッピング: ユーザによって提供されたストリング(「句を通過する」)はMD5アルゴリズムで16八重奏のダイジェストに論じ尽くされます。 n-ビットキーは、ダイジェストからダイジェストから最初のnビット取ることによって、抽出されます。 数個のキーが128ビット(三重のDESのような)以下の全長で必要であるなら、彼らはそのダイジェストから整然とした状態で抽出されます。 八重奏注文はRFC1423、セクション2.2で指定されます。 (いくつかのDES実装が、キーの各7ビットを伴うために56ビットのキーが八重奏の最も重要なビットに奇数パリティビットを挿入することによって8つの八重奏に広げられるのを必要とすることに注意してください。)
It is suggested that pass phrases are restricted to ASCII letters, digits, the hyphen, and white space to reduce the the chance of transcription errors when conveying keys by phone, fax, telex or email.
パス句がASCII手紙か、ケタか、ハイフンと、電話でキーを運ぶとき転写誤りの可能性を小さくする余白か、ファックスか、テレックスかメールに制限されることが提案されます。
The pass phrase may be preceded by a specification of the encryption algorithm. Any characters up to the first slash (ASCII 0x2f) are taken as the name of the encryption algorithm. The encryption format specifiers should be drawn from RFC 1423 or any additional identifiers registered with IANA. If no slash is present, DES-CBC is assumed as default. The encryption algorithm specifier is case sensitive.
暗号化アルゴリズムの仕様でパス句は先行されるかもしれません。 最初のスラッシュ(ASCII0x2f)までのどんなキャラクタも暗号化アルゴリズムの名前としてみなされます。 RFC1423から暗号化形式特許説明書の作成書を得るべきでしたか、またはどんな追加識別子もIANAとともに記名しました。 どんなスラッシュも存在していないなら、DES-CBCはデフォルトとして想定されます。 暗号化アルゴリズム特許説明書の作成書は大文字と小文字を区別しています。
The pass phrase typed by the user is transformed to a canonical form before applying the hash algorithm. For that purpose, we define return, tab, or vertical tab as well as all characters contained in the Unicode space characters table. The transformation consists of the following steps: (1) convert the input string to the ISO 10646 character set, using the UTF-8 encoding as specified in Annex P to ISO/IEC 10646-1:1993 (ASCII characters require no mapping, but ISO 8859-1 characters do); (2) remove leading and trailing white space characters; (3) replace one or more contiguous white space characters by a single space (ASCII or UTF-8 0x20); (4) convert all letters to lower case and replace sequences of characters and non-spacing accents with a single character, where possible. A minimum length of 16 key characters (after applying the transformation) should be enforced by the application, while applications must allow up to 256 characters of input.
ハッシュアルゴリズムを適用する前に、ユーザによってタイプされたパス句は標準形に変えられます。 そのために、私たちはユニコード間隔文字テーブルに含まれたすべてのキャラクタと同様にリターン、タブ、または垂直タブを定義します。 変換は以下のステップから成ります: (1) ISO10646文字集合に入力ストリングを変換してください、Annex Pでの指定されるとしてのUTF-8コード化をISO/IEC10646-1に使用して: 1993(ASCII文字は、写像するのを必要としませんが、ISO8859-1キャラクタは必要です) (2) 主で引きずっている余白キャラクタを外してください。 (3) シングルスペース(ASCIIかUTF-8 0x20)のそばで1つ以上の隣接の余白キャラクタを取り替えてください。 (4) すべての手紙を変換して、ケースを下ろして、可能であるところでキャラクタと非スペースアクセントの系列を単独のキャラクタに置き換えてください。 16の主要なキャラクタ(変換を適用した後の)の最小の長さはアプリケーションによって励行されるべきです、アプリケーションが入力の最大256のキャラクタを許容しなければなりませんが。
Underlying protocol: The profile specifies the use of RTP over
unicast and multicast UDP. (This does not preclude the use of
these definitions when RTP is carried by other lower-layer
protocols.)
基本的なプロトコル: プロフィールはユニキャストとマルチキャストUDPの上でRTPの使用を指定します。 (RTPが他の下位層プロトコルによって運ばれるとき、これはこれらの定義の使用を排除しません。)
Transport mapping: The standard mapping of RTP and RTCP to
transport-level addresses is used.
マッピングを輸送してください: 輸送レベルアドレスへのRTPとRTCPの標準のマッピングは使用されています。
Schulzrinne Standards Track [Page 3] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[3ページ]
Encapsulation: No encapsulation of RTP packets is specified.
カプセル化: RTPパケットのカプセル化は全く指定されません。
3. Registering Payload Types
3. 有効搭載量を示すのはタイプされます。
This profile defines a set of standard encodings and their payload types when used within RTP. Other encodings and their payload types are to be registered with the Internet Assigned Numbers Authority (IANA). When registering a new encoding/payload type, the following information should be provided:
このプロフィールは標準のencodingsの1セットを定義します、そして、RTPの中で使用されると、それらのペイロードはタイプされます。 他のencodingsと彼らのペイロードタイプはインターネットAssigned民数記Authorityに示されることになっています(IANA)。 新しいコード化/ペイロードタイプを示すとき、以下の情報を提供するべきです:
o name and description of encoding, in particular the RTP
timestamp clock rate; the names defined here are 3 or 4
characters long to allow a compact representation if needed;
o 名前とコード化の記述、特にRTPタイムスタンプ時計は評価します。 必要であるなら、ここで定義された名前はコンパクトな表現を許容するために長い3か4つのキャラクタです。
o indication of who has change control over the encoding (for
example, ISO, CCITT/ITU, other international standardization
bodies, a consortium or a particular company or group of
companies);
o だれにコード化(例えば、ISO、CCITT/ITU、他の国際標準化本体、共同体、特定の会社または企業グループ)の変化コントロールがあるかしるし。
o any operating parameters or profiles;
o どんな運転パラメータやプロフィールも。
o a reference to a further description, if available, for
example (in order of preference) an RFC, a published paper, a
patent filing, a technical report, documented source code or a
computer manual;
o 例えば(好みの順に)、RFC、利用可能であるなら発行された論文、aがファイルしながら特許をとるさらなる記述の参照(技術報告書)はソースコードかコンピュータのマニュアルを記録しました。
o for proprietary encodings, contact information (postal and
email address);
o そして、独占encodings、問い合わせ先、(郵便、Eメールアドレス)、。
o the payload type value for this profile, if necessary (see
below).
o このプロフィールのための必要なら(以下を見る)ペイロードタイプ価値。
Note that not all encodings to be used by RTP need to be assigned a static payload type. Non-RTP means beyond the scope of this memo (such as directory services or invitation protocols) may be used to establish a dynamic mapping between a payload type drawn from the range 96-127 and an encoding. For implementor convenience, this profile contains descriptions of encodings which do not currently have a static payload type assigned to them.
すべてのRTPによって使用されるべきencodingsが、静的なペイロードタイプに割り当てられる必要であるというわけではないことに注意してください。 このメモ(ディレクトリサービスか招待プロトコルなどの)の範囲を超えた非RTP手段は、範囲96-127から得られたペイロードタイプとコード化の間のダイナミックなマッピングを証明するのに使用されるかもしれません。 作成者便宜のために、このプロフィールは現在静的なペイロードタイプを彼らに選任させないencodingsの記述を含んでいます。
The available payload type space is relatively small. Thus, new static payload types are assigned only if the following conditions are met:
利用可能なペイロードタイプスペースは比較的小さいです。 したがって、以下の条件が満たされる場合にだけ、新しい静的なペイロードタイプは選任されます:
o The encoding is of interest to the Internet community at
large.
o コード化は全体のインターネットコミュニティに興味があります。
Schulzrinne Standards Track [Page 4] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[4ページ]
o It offers benefits compared to existing encodings and/or is
required for interoperation with existing, widely deployed
conferencing or multimedia systems.
o それが、既存のencodingsと比べて、利益を提供する、そして/または、interoperationに存在、広く配布している会議またはマルチメディア・システムで必要です。
o The description is sufficient to build a decoder.
o 記述は、デコーダを組立てるために十分です。
4. Audio
4. オーディオ
4.1 Encoding-Independent Recommendations
4.1 コード化して独立している推薦
For applications which send no packets during silence, the first packet of a talkspurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero.
沈黙の間にパケットを全く送らないアプリケーションにおいて、talkspurt(沈黙の期間の後の最初のパケット)の最初のパケットは、RTPデータヘッダーにマーカービットをはめ込むことによって、区別されます。 沈黙抑圧のないアプリケーションはゼロにビットを設定します。
The RTP clock rate used for generating the RTP timestamp is independent of the number of channels and the encoding; it equals the number of sampling periods per second. For N-channel encodings, each sampling period (say, 1/8000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.)
RTPタイムスタンプを生成するのに使用されるRTPクロックレートはチャンネルの数とコード化から独立しています。 それは1秒あたりのサンプリング周期の数と等しいです。 N-チャンネルencodingsに関しては、各サンプリング周期(たとえば、1/8000の2番目)はNサンプルを生成します。 (この用語は、標準ですが、いくらか紛らわしいです、1秒単位で生成されたサンプルの総数が次にチャンネルが数える標本抽出率回であるので。)
If multiple audio channels are used, channels are numbered left-to- right, starting at one. In RTP audio packets, information from lower-numbered channels precedes that from higher-numbered channels. For more than two channels, the convention followed by the AIFF-C audio interchange format should be followed [1], using the following notation:
チャンネルが複数のオーディオであるなら使用されている、チャンネルは、番号付の左から1からの右です。 RTPオーディオパケットでは、より低く番号付のチャンネルからの情報は、より高く番号付のチャンネルからそれに先行します。 2個以上のチャンネルにおいて、AIFF-Cオーディオ置き換え形式があとに続いたコンベンションが続かれるべきである、[1]以下の記法を使用して、
l left r right c center S surround F front R rear
lは後部でr権利cセンターS取り囲むものF戦線Rを出ました。
channels description channel
1 2 3 4 5 6
___________________________________________________________
2 stereo l r
3 l r c
4 quadrophonic Fl Fr Rl Rr
4 l c r S
5 Fl Fr Fc Sl Sr
6 l lc c r rc S
記述チャンネル1 2 3 4 5 6を向けます。___________________________________________________________ 2 ステレオl r3l r4c quadrophonic FlフランのRl Rr4l c r5S FlフランのFc Sl Sr6l lc c r rc S
Schulzrinne Standards Track [Page 5] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[5ページ]
Samples for all channels belonging to a single sampling instant must be within the same packet. The interleaving of samples from different channels depends on the encoding. General guidelines are given in Section 4.2 and 4.3.
同じパケットの中に瞬間を抽出するシングルに属すオール・チャンネルへのサンプルがあるに違いありません。 異なったチャンネルからのサンプルのインターリービングはコード化であることによります。 セクション4.2と4.3で一般的ガイドラインを与えます。
The sampling frequency should be drawn from the set: 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000 Hz. (The Apple Macintosh computers have native sample rates of 22254.54 and 11127.27, which can be converted to 22050 and 11025 with acceptable quality by dropping 4 or 2 samples in a 20 ms frame.) However, most audio encodings are defined for a more restricted set of sampling frequencies. Receivers should be prepared to accept multi-channel audio, but may choose to only play a single channel.
セットからサンプリング周波数を得るべきです: 8000、11025、16000、22050、24000、32000、44100、および48000Hz。 (アップルマッキントッシュのコンピュータには、22254.54と11127.27のネイティブの見本郵送料率、どれを22050に変換できるか、そして、および20msフレームで4か2個のサンプルを下げるのによる合格品質がある11025があります。) しかしながら、ほとんどのオーディオのencodingsがさらに制限されたセットのサンプリング周波数のために定義されます。 受信機は、マルチチャンネルオーディオを受け入れるように準備されるべきですが、単独のチャンネルを使うだけであるのを選ぶかもしれません。
The following recommendations are default operating parameters. Applications should be prepared to handle other values. The ranges given are meant to give guidance to application writers, allowing a set of applications conforming to these guidelines to interoperate without additional negotiation. These guidelines are not intended to restrict operating parameters for applications that can negotiate a set of interoperable parameters, e.g., through a conference control protocol.
以下の推薦はデフォルト操作パラメタです。 アプリケーションは他の値を扱うように準備されるべきです。 与えられた範囲はアプリケーション作家に指導を与えることになっています、これらのガイドラインに従う1セットのアプリケーションが追加交渉なしで共同利用するのを許容して。 これらのガイドラインが1セットの共同利用できるパラメタを交渉できるアプリケーションのための運転パラメータを制限することを意図しません、例えば、会議制御プロトコルを通して。
For packetized audio, the default packetization interval should have a duration of 20 ms, unless otherwise noted when describing the encoding. The packetization interval determines the minimum end-to- end delay; longer packets introduce less header overhead but higher delay and make packet loss more noticeable. For non-interactive applications such as lectures or links with severe bandwidth constraints, a higher packetization delay may be appropriate. A receiver should accept packets representing between 0 and 200 ms of audio data. This restriction allows reasonable buffer sizing for the receiver.
デフォルトpacketization間隔には、packetizedオーディオのために、20msの持続時間があるべきです、コード化について説明するとき、別の方法で注意されない場合。 packetization間隔は最小の終わりから終わりへの遅れを決定します。 より長いパケットで、より少ないヘッダーオーバーヘッドにもかかわらず、より高い遅れを導入して、パケット損失は、よりめぼしくなります。 厳しい帯域幅規制との講演かリンクなどの非対話的なアプリケーションにおいて、より高いpacketization遅れは適切であるかもしれません。 受信機はオーディオデータの0〜200msを表すパケットを受け入れるはずです。 この制限は受信機のために妥当なバッファサイズ処理を許容します。
4.2 Guidelines for Sample-Based Audio Encodings
4.2 サンプルベースのオーディオEncodingsのためのガイドライン
In sample-based encodings, each audio sample is represented by a fixed number of bits. Within the compressed audio data, codes for individual samples may span octet boundaries. An RTP audio packet may contain any number of audio samples, subject to the constraint that the number of bits per sample times the number of samples per packet yields an integral octet count. Fractional encodings produce less than one octet per sample.
サンプルベースのencodingsでは、それぞれのオーディオのサンプルは固定数のビットによって表されます。 圧縮されたオーディオデータの中では、個々のサンプルのためのコードは八重奏境界にかかるかもしれません。 RTPオーディオパケットは1パケットあたりのサンプルの数が不可欠の八重奏をもたらすというサンプル時間あたりのビットの数が重要であるという規制を条件としていろいろなオーディオのサンプルを含むかもしれません。 断片的なencodingsは1サンプルあたり1つ未満の八重奏を起こします。
The duration of an audio packet is determined by the number of samples in the packet.
パケットのサンプルの数に従って、オーディオパケットの持続時間は決定しています。
Schulzrinne Standards Track [Page 6] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[6ページ]
For sample-based encodings producing one or more octets per sample, samples from different channels sampled at the same sampling instant are packed in consecutive octets. For example, for a two-channel encoding, the octet sequence is (left channel, first sample), (right channel, first sample), (left channel, second sample), (right channel, second sample), .... For multi-octet encodings, octets are transmitted in network byte order (i.e., most significant octet first).
1サンプルあたり1つ以上の八重奏を起こすサンプルベースのencodingsに関しては、瞬間を抽出する同じくらいで抽出された異なったチャンネルからのサンプルは連続した八重奏で詰められています。 例えば、八重奏系列が2チャンネルのコード化のための、(左のチャンネル、最初のサンプル)である、(正しいチャンネル、最初のサンプル)、(左のチャンネル、2番目のサンプル)、(正しいチャンネル、2番目のサンプル)、… マルチ八重奏encodingsに関しては、八重奏がネットワークバイトオーダーで伝えられる、(すなわち、最も重要な八重奏、1番目)
The packing of sample-based encodings producing less than one octet per sample is encoding-specific.
1サンプルあたり1つ未満の八重奏を起こすサンプルベースのencodingsのパッキングはコード化して特定です。
4.3 Guidelines for Frame-Based Audio Encodings
4.3 フレームベースのオーディオEncodingsのためのガイドライン
Frame-based encodings encode a fixed-length block of audio into another block of compressed data, typically also of fixed length. For frame-based encodings, the sender may choose to combine several such frames into a single message. The receiver can tell the number of frames contained in a message since the frame duration is defined as part of the encoding.
フレームベースのencodingsは別のブロックの圧縮されたデータへのオーディオと、通常、固定長についても固定長ブロックをコード化します。 フレームベースのencodingsのために、送付者は、そのようないくつかのフレームをただ一つのメッセージに結合するのを選ぶかもしれません。 受信機はフレーム持続時間がコード化の一部と定義されるのでメッセージに含まれたフレームの数を言うことができます。
For frame-based codecs, the channel order is defined for the whole block. That is, for two-channel audio, right and left samples are coded independently, with the encoded frame for the left channel preceding that for the right channel.
フレームベースのコーデックに関しては、チャンネル注文を全体のブロックと定義します。 すなわち、2チャンネルのオーディオにおいて、左右なサンプルは独自にコード化されます、左のチャンネルのためのコード化されたフレームが正しいチャンネルのためにそれに先行していて。
All frame-oriented audio codecs should be able to encode and decode several consecutive frames within a single packet. Since the frame size for the frame-oriented codecs is given, there is no need to use a separate designation for the same encoding, but with different number of frames per packet.
すべてのフレーム指向のオーディオコーデックが、単一のパケットの中のいくつかの連続したフレームをコード化して、解読できるはずです。 フレーム指向のコーデックのためのフレーム・サイズを与えるので、同じコード化に別々の名称を使用しますが、異なった数の1パケットあたりのフレームで使用する必要は全くありません。
Schulzrinne Standards Track [Page 7] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[7ページ]
4.4 Audio Encodings
4.4 オーディオEncodings
encoding sample/frame bits/sample ms/frame
____________________________________________________
1016 frame N/A 30
DVI4 sample 4
G721 sample 4
G722 sample 8
G728 frame N/A 2.5
GSM frame N/A 20
L8 sample 8
L16 sample 16
LPC frame N/A 20
MPA frame N/A
PCMA sample 8
PCMU sample 8
VDVI sample var.
サンプル/フレームビット/サンプルms/フレームをコード化します。____________________________________________________ 1016年のフレームN/A30DVI4サンプル4G721サンプル4G722サンプル8G728フレームN/A2.5GSMフレームN/A20L8サンプル8L16サンプル16LPCフレームN/A20MPAフレームN/A PCMAサンプル8PCMUサンプル8VDVIサンプルvar.
Table 1: Properties of Audio Encodings
テーブル1: オーディオEncodingsの特性
The characteristics of standard audio encodings are shown in Table 1 and their payload types are listed in Table 2.
標準のオーディオencodingsの特性はTable1とそれらのペイロードにタイプがTable2に記載されているのが示されます。
4.4.1 1016
4.4.1 1016
Encoding 1016 is a frame based encoding using code-excited linear prediction (CELP) and is specified in Federal Standard FED-STD 1016 [2,3,4,5].
1016をコード化するのは、使用のコードで興奮している直線的な予測をコード化しながら基づくフレーム(CELP)であり、連邦規格FED-STD1016[2、3、4、5]で指定されます。
The U. S. DoD's Federal-Standard-1016 based 4800 bps code excited linear prediction voice coder version 3.2 (CELP 3.2) Fortran and C simulation source codes are available for worldwide distribution at no charge (on DOS diskettes, but configured to compile on Sun SPARC stations) from: Bob Fenichel, National Communications System, Washington, D.C. 20305, phone +1-703-692-2124, fax +1-703-746-4960.
U.S.DoDの連邦政府の標準の1016は以下から4800年の直線的な予測音声符号器バージョン3.2(CELP3.2)FortranとCシミュレーションソースコードが世界的な分配に無料で利用可能であるのに興奮しているビーピーエスコード(Sun SPARCステーションでコンパイルするためにディスケットの、しかし、構成されたDOSの)を基礎づけました。 ボブ・フェニヘル、National Communications System、ワシントンDC20305電話+1-703-692-2124はファックスで+1-703-746-4960を送ります。
4.4.2 DVI4
4.4.2 DVI4
DVI4 is specified, with pseudo-code, in [6] as the IMA ADPCM wave type. A specification titled "DVI ADPCM Wave Type" can also be found in the Microsoft Developer Network Development Library CD ROM published quarterly by Microsoft. The relevant section is found under Product Documentation, SDKs, Multimedia Standards Update, New Multimedia Data Types and Data Techniques, Revision 3.0, April 15, 1994. However, the encoding defined here as DVI4 differs in two respects from these recommendations:
IMA ADPCMがタイプを振るとき、DVI4は[6]で中間コードで指定されます。 また、年4回でマイクロソフトによって発行されたMicrosoftDeveloperNetwork Development図書館CD-ROMで「DVI ADPCM波のタイプ」と題をつけられた仕様は見つけることができます。 関連セクションはProduct DocumentationとSDKsとMultimedia Standards UpdateとNew Multimedia Data TypesとData Techniques、Revision3.0、1994年4月15日の下で見つけられます。 しかしながら、ここでDVI4と定義されたコード化はこれらの推薦と2つの点において異なります:
Schulzrinne Standards Track [Page 8] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[8ページ]
o The header contains the predicted value rather than the first
sample value.
o ヘッダーは最初の標本値よりむしろ予測値を含んでいます。
o IMA ADPCM blocks contain odd number of samples, since the
first sample of a block is contained just in the header
(uncompressed), followed by an even number of compressed
samples. DVI4 has an even number of compressed samples only,
using the 'predict' word from the header to decode the first
sample.
o IMA ADPCMブロックはサンプルの奇数を含んでいます、1ブロックの最初のサンプルがまさしく圧縮されたサンプルの偶数があとに続いたヘッダー(解凍される)に含まれているので。 DVI4には、圧縮されたサンプルだけの偶数があります、最初のサンプルを解読するのにヘッダーからの'予測'単語を使用して。
Each packet contains a single DVI block. The profile only defines the 4-bit-per-sample version, while IMA also specifies a 3-bit-per-sample encoding.
各パケットは1つのDVIブロックを含んでいます。 プロフィールは1サンプルあたり4ビットのバージョンを定義するだけですが、また、IMAは1サンプルあたり3ビットコード化を指定します。
The "header" word for each channel has the following structure:
各チャンネルに対する「ヘッダー」単語には、以下の構造があります:
int16 predict; /* predicted value of first sample
from the previous block (L16 format) */
u_int8 index; /* current index into stepsize table */
u_int8 reserved; /* set to zero by sender, ignored by receiver */
int16、予測します。 /*は前のブロック(L16形式)*/u_int8インデックスから最初のサンプルの値を予測しました。 電流が索引をつける/*はint8が予約したテーブル*/u_をstepsizeします。 /*は受信機*/によって無視された送付者でゼロにセットしました。
Packing of samples for multiple channels is for further study.
さらなる研究には複数のチャンネルへのサンプルのパッキングがあります。
The document, "IMA Recommended Practices for Enhancing Digital Audio Compatibility in Multimedia Systems (version 3.0)", contains the algorithm description. It is available from:
「マルチメディア・システム(バージョン3.0)のデジタル・オーディオの互換性を高めるためのIMA推奨案」というドキュメントはアルゴリズム記述を含んでいます。 それは以下から利用可能です。
Interactive Multimedia Association 48 Maryland Avenue, Suite 202 Annapolis, MD 21401-8011 USA phone: +1 410 626-1380
Interactive Multimedia Association48メリーランドアベニュー、Suite202MD21401-8011アナポリス(米国)電話: +1 410 626-1380
4.4.3 G721
4.4.3 G721
G721 is specified in ITU recommendation G.721. Reference implementations for G.721 are available as part of the CCITT/ITU-T Software Tool Library (STL) from the ITU General Secretariat, Sales Service, Place du Nations, CH-1211 Geneve 20, Switzerland. The library is covered by a license.
G721はITU推薦G.721で指定されます。 G.721のための参照実装はITUの一般事務局からのITU CCITT/T Software Tool図書館(STL)、Sales Service、Place du Nations、CH-1211ジュネーブ20スイスの一部として利用可能です。 ライブラリはライセンスでカバーされています。
4.4.4 G722
4.4.4 G722
G722 is specified in ITU-T recommendation G.722, "7 kHz audio-coding within 64 kbit/s".
ITU-T推薦G.722、「64kbit/sの中の7kHzのオーディオ符号化」でG722は指定されます。
G728 is specified in ITU-T recommendation G.728, "Coding of speech at 16 kbit/s using low-delay code excited linear prediction".
G728はITU-T推薦G.728、「低い遅れコードを使用する16kbit/sのスピーチのコード化は直線的な予測を起こしたところ」で指定されます。
Schulzrinne Standards Track [Page 9] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[9ページ]
4.4.6 GSM
4.4.6 GSM
GSM (group speciale mobile) denotes the European GSM 06.10 provisional standard for full-rate speech transcoding, prI-ETS 300 036, which is based on RPE/LTP (residual pulse excitation/long term prediction) coding at a rate of 13 kb/s [7,8,9]. The standard can be obtained from
GSM(グループspecialeモバイル)は全額料金スピーチコード変換のヨーロッパのGSM06.10暫定基準、prI-ETS300 036を指示します。(prI-ETSは、13の速度でkb/s[7、8、9]をコード化しながら、RPE/LTP(残りのパルス励起/長期予測)に基づいています)。 規格を得ることができます。
ETSI (European Telecommunications Standards Institute) ETSI Secretariat: B.P.152 F-06561 Valbonne Cedex France Phone: +33 92 94 42 00 Fax: +33 93 65 47 16
ETSI(規格が設けるヨーロッパのテレコミュニケーション)ETSI事務局: B.P.152F-06561Valbonne Cedexフランス電話: +33 92 94 42 00、Fax: +33 93 65 47 16
4.4.7 L8
4.4.7 L8
L8 denotes linear audio data, using 8-bits of precision with an offset of 128, that is, the most negative signal is encoded as zero.
L8は直線的なオーディオデータを指示します、128のオフセットと共に精度の8ビットを使用して、すなわち、最も否定的な信号がゼロとしてコード化されます。
4.4.8 L16
4.4.8 L16
L16 denotes uncompressed audio data, using 16-bit signed representation with 65535 equally divided steps between minimum and maximum signal level, ranging from -32768 to 32767. The value is represented in two's complement notation and network byte order.
L16は解凍されたオーディオデータを指示します、最小の、そして、最大の信号レベルの間の等しく分割された65535ステップで16ビットの署名している表現を使用して、-32768〜32767まで及んで。 値は2の補数記法とネットワークバイトオーダーで表されます。
4.4.9 LPC
4.4.9 LPC
LPC designates an experimental linear predictive encoding contributed by Ron Frederick, Xerox PARC, which is based on an implementation written by Ron Zuckerman, Motorola, posted to the Usenet group comp.dsp on June 26, 1992.
LPCはロンフレディリックによって寄付された実験的な直線的な予言のコード化を指定します、とゼロックスPARC(ロンザッカーマン、モトローラによって書かれた実装に基づいている)は1992年6月26日にUsenetグループcomp.dspに掲示しました。
4.4.10 MPA
4.4.10 MPA
MPA denotes MPEG-I or MPEG-II audio encapsulated as elementary streams. The encoding is defined in ISO standards ISO/IEC 11172-3 and 13818-3. The encapsulation is specified in work in progress [10], Section 3. The authors can be contacted at
MPAがMPEG-Iを指示するか、または基本であるとしてカプセル化されたMPEG-IIオーディオは流れます。コード化はISO規格ISO/IECで11172-3に13818-3に定義されます。 カプセル化は処理中の作業[10]、セクション3で指定されます。 作者に連絡できます。
Don Hoffman Sun Microsystems, Inc. Mail-stop UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA electronic mail: don.hoffman@eng.sun.com
ホフマンサン・マイクロシステムズ・インクメール停止UMPK14-305 2550ガルシア・Avenueカリフォルニア94043-1100マウンテンビュー(米国)電子メールを身につけてください: don.hoffman@eng.sun.com
Schulzrinne Standards Track [Page 10] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[10ページ]
Sampling rate and channel count are contained in the payload. MPEG-I audio supports sampling rates of 32000, 44100, and 48000 Hz (ISO/IEC 11172-3, section 1.1; "Scope"). MPEG-II additionally supports ISO/IEC 11172-3 Audio...").
標本抽出率とチャンネルカウントはペイロードに含まれています。 MPEG-Iオーディオは32000、44100、および48000Hzの標本抽出率をサポートします(ISO/IEC11172-3、セクション1.1; 「見てください」)。 「MPEG-IIは、ISO/IEC11172-3がAudioであるとさらに、サポートします」…).
4.4.11 PCMA
4.4.11 PCMA
PCMA is specified in CCITT/ITU-T recommendation G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. Code to convert between linear and A-law companded data is available in [6]. A detailed description is given by Jayant and Noll [11].
PCMAはITU CCITT/T推薦G.711で指定されます。 オーディオデータは対数のスケーリングの後に1サンプルあたり8ビットとしてコード化されます。 直線的であることの間で変換するコードとcompandedされたA-法のデータは[6]で利用可能です。 詳述はJayantとノル[11]によって与えられています。
4.4.12 PCMU
4.4.12 PCMU
PCMU is specified in CCITT/ITU-T recommendation G.711. Audio data is encoded as eight bits per sample, after logarithmic scaling. Code to convert between linear and mu-law companded data is available in [6]. PCMU is the encoding used for the Internet media type audio/basic. A detailed description is given by Jayant and Noll [11].
PCMUはITU CCITT/T推薦G.711で指定されます。 オーディオデータは対数のスケーリングの後に1サンプルあたり8ビットとしてコード化されます。 直線的であることの間で変換するコードとcompandedされたμ法のデータは[6]で利用可能です。 PCMUはインターネットメディアタイプにオーディオ的であるか、または基本的に使用されるコード化です。 詳述はJayantとノル[11]によって与えられています。
4.4.13 VDVI
4.4.13 VDVI
VDVI is a variable-rate version of DVI4, yielding speech bit rates of between 10 and 25 kb/s. It is specified for single-channel operation only. It uses the following encoding:
VDVIはDVI4の変動金利バージョンであり、もたらすのは10〜25kb/sのスピーチビット伝送速度です。 それは単独のチャンネル操作だけに指定されます。 それは以下のコード化を使用します:
DVI4 codeword VDVI bit pattern
__________________________________
0 00
1 010
2 1100
3 11100
4 111100
5 1111100
6 11111100
7 11111110
8 10
9 011
10 1101
11 11101
12 111101
13 1111101
14 11111101
15 11111111
DVI4符号語VDVIビット・パターン__________________________________ 0 00 1 010 2 1100 3 11100 4 111100 5 1111100 6 11111100 7 11111110 8 10 9 011 10 1101 11 11101 12 111101 13 1111101 14 11111101 15 11111111
Schulzrinne Standards Track [Page 11] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[11ページ]
5. Video
5. ビデオ
The following video encodings are currently defined, with their abbreviated names used for identification:
彼らの略称が識別に使用されている状態で、以下のビデオencodingsは現在、定義されます:
5.1 CelB
5.1 CelB
The CELL-B encoding is a proprietary encoding proposed by Sun Microsystems. The byte stream format is described in work in progress [12]. The author can be contacted at
CELL-Bコード化はサン・マイクロシステムズによって提案された独占コード化です。バイト・ストリーム形式は処理中の作業[12]で説明されます。 作者に連絡できます。
Michael F. Speer Sun Microsystems Computer Corporation 2550 Garcia Ave MailStop UMPK14-305 Mountain View, CA 94043 United States electronic mail: michael.speer@eng.sun.com
マイケルF.シュペーアサン・マイクロシステムズコンピュータ社2550のガルシアAve MailStop UMPK14-305マウンテンビュー(カリフォルニア)94043合衆国電子メール: michael.speer@eng.sun.com
5.2 JPEG
5.2 JPEG
The encoding is specified in ISO Standards 10918-1 and 10918-2. The RTP payload format is as specified in work in progress [13]. Further information can be obtained from
コード化はISO Standards10918-1と10918-2で指定されます。 RTPペイロード形式が処理中の作業[13]で指定されるようにあります。 詳細を得ることができます。
Steven McCanne Lawrence Berkeley National Laboratory M/S 46A-1123 One Cyclotron Road Berkeley, CA 94720 United States Phone: +1 510 486 7520 electronic mail: mccanne@ee.lbl.gov
スティーブンMcCanneローレンスバークレーの国家の研究所M/S46A-1123 1サイクロトロンRoadカリフォルニア94720バークレー(合衆国)は以下に電話をします。 +1 7520年の510 486電子メール: mccanne@ee.lbl.gov
5.3 H261
5.3 H261
The encoding is specified in CCITT/ITU-T standard H.261. The packetization and RTP-specific properties are described in work in progress [14]. Further information can be obtained from
コード化はITU CCITT/T標準のH.261で指定されます。 packetizationとRTP特有の性質は処理中の作業[14]で説明されます。 詳細を得ることができます。
Thierry Turletti Office NE 43-505 Telemedia, Networks and Systems Laboratory for Computer Science Massachusetts Institute of Technology 545 Technology Square Cambridge, MA 02139 United States electronic mail: turletti@clove.lcs.mit.edu
ティエリーTurlettiオフィスNE43-505Telemedia、NetworksとSystemsコンピュータ科学研究所マサチューセッツ工科大学545Technology Squareケンブリッジ(MA)02139合衆国電子メール: turletti@clove.lcs.mit.edu
Schulzrinne Standards Track [Page 12] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[12ページ]
5.4 MPV
5.4 MPV
MPV designates the use MPEG-I and MPEG-II video encoding elementary streams as specified in ISO Standards ISO/IEC 11172 and 13818-2, respectively. The RTP payload format is as specified in work in progress [10], Section 3. See the description of the MPA audio encoding for contact information.
MPVはそれぞれISO Standards ISO/IEC11172における指定されるとしてのMPEG-IとMPEG-IIのビデオのコード化の基本のストリームと13818-2に使用を指定します。 RTPペイロード形式が処理中の作業[10]、セクション3で指定されるようにあります。 問い合わせ先のためのMPAオーディオコード化の記述を見てください。
5.5 MP2T
5.5 MP2T
MP2T designates the use of MPEG-II transport streams, for either audio or video. The encapsulation is described in work in progress, [10], Section 2. See the description of the MPA audio encoding for contact information.
MP2TはオーディオかビデオのどちらかのためにMPEG-IIの使用を輸送ストリームに指定します。 カプセル化は処理中の作業、[10]、セクション2で説明されます。 問い合わせ先のためのMPAオーディオコード化の記述を見てください。
5.6 nv
5.6 nv
The encoding is implemented in the program 'nv', version 4, developed at Xerox PARC by Ron Frederick. Further information is available from the author:
コード化は'nv'(バージョン4)がゼロックスPARCでロンフレディリックで開発したプログラムで実装されます。 詳細は作者から利用可能です:
Ron Frederick Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 United States electronic mail: frederic@parc.xerox.com
ロンフレディリックゼロックスパロアルト研究センター3333Coyoteヒル・Roadカリフォルニア94304パロアルト(合衆国)電子メール: frederic@parc.xerox.com
6. Payload Type Definitions
6. 有効搭載量型定義
Table 2 defines this profile's static payload type values for the PT field of the RTP data header. A new RTP payload format specification may be registered with the IANA by name, and may also be assigned a static payload type value from the range marked in Section 3.
テーブル2は太平洋標準時の間のタイプ値がさばくこのプロフィールのRTPデータヘッダーの静的なペイロードを定義します。 新しいRTPペイロード書式仕様は名前によってIANAに示されて、また、セクション3に示される範囲から静的なペイロードタイプ価値を割り当てられるかもしれません。
In addition, payload type values in the range 96-127 may be defined dynamically through a conference control protocol, which is beyond the scope of this document. For example, a session directory could specify that for a given session, payload type 96 indicates PCMU encoding, 8,000 Hz sampling rate, 2 channels. The payload type range marked 'reserved' has been set aside so that RTCP and RTP packets can be reliably distinguished (see Section "Summary of Protocol Constants" of the RTP protocol specification).
さらに、範囲96-127のペイロードタイプ値は会議制御プロトコルを通してダイナミックに定義されるかもしれません。制御プロトコルがこのドキュメントの範囲にあります。 例えば、セッションディレクトリは、与えられたセッションのために、ペイロードタイプ96がPCMUコード化を示すと指定するかもしれません、8,000Hzの標本抽出率、2個のチャンネル。 '予約されていること'が示されるペイロードタイプ範囲は、RTCPとRTPパケットを確かに区別できる(「プロトコル定数の概要」というRTPプロトコル仕様のセクションを見る)ようにかたわらに置かれました。
An RTP source emits a single RTP payload type at any given time; the interleaving of several RTP payload types in a single RTP session is not allowed, but multiple RTP sessions may be used in parallel to send multiple media. The payload types currently defined in this
RTPソースはその時々で単独のRTPペイロードタイプを放ちます。 ただ一つのRTPセッションにおける、いくつかのRTPペイロードタイプのインターリービングは許容されていませんが、複数のRTPセッションが、マルチメディアを送るのに平行で使用されるかもしれません。 現在これで定義されているペイロードタイプ
Schulzrinne Standards Track [Page 13] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[13ページ]
profile carry either audio or video, but not both. However, it is allowed to define payload types that combine several media, e.g., audio and video, with appropriate separation in the payload format. Session participants agree through mechanisms beyond the scope of this specification on the set of payload types allowed in a given session. This set may, for example, be defined by the capabilities of the applications used, negotiated by a conference control protocol or established by agreement between the human participants.
プロフィールは、オーディオかビデオのどちらかを運びますが、ともに運ぶというわけではありません。 しかしながら、それはペイロード形式で適切な分離があるいくつかのメディアを合併するペイロードタイプ、例えば、オーディオ、およびビデオを定義できます。 セッション関係者は与えられたセッションのときに許容されたペイロードタイプのセットに関するこの仕様の範囲を超えたメカニズムを通して同意します。 例えば、このセットは人間の関係者の間で申し合わせて使用されるか、会議制御プロトコルによって交渉されるか、または確立されたアプリケーションの能力によって定義されるかもしれません。
Audio applications operating under this profile should, at minimum, be able to send and receive payload types 0 (PCMU) and 5 (DVI4). This allows interoperability without format negotiation and successful negotation with a conference control protocol.
最小限では、このプロフィールの下で作動するオーディオアプリケーションは、ペイロードタイプ0(PCMU)と5(DVI4)を送って、受け取ることができるべきです。 これは会議制御プロトコルがある形式交渉とうまくいっているnegotationなしで相互運用性を許容します。
All current video encodings use a timestamp frequency of 90,000 Hz, the same as the MPEG presentation time stamp frequency. This frequency yields exact integer timestamp increments for the typical 24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates and 50, 59.94 and 60 Hz field rates. While 90 kHz is the recommended rate for future video encodings used within this profile, other rates are possible. However, it is not sufficient to use the video frame rate (typically between 15 and 30 Hz) because that does not provide adequate resolution for typical synchronization requirements when calculating the RTP timestamp corresponding to the NTP timestamp in an RTCP SR packet [15]. The timestamp resolution must also be sufficient for the jitter estimate contained in the receiver reports.
すべての現在のビデオencodingsはMPEGとして9万Hzのタイムスタンプ頻度に、同じようにプレゼンテーションタイムスタンプ頻度を使用します。 この頻度は25の典型的な24(HDTV)のための正確な整数タイムスタンプ増分と(PAL)と(NTSC)と30Hz(HDTV)の29.97のフレームレートと50、59.94、および60Hzの分野レートをもたらします。 このプロフィールの中に使用されたencodings、90kHzは将来のビデオのお勧めのレートですが、他のレートは可能です。 しかしながら、それは、RTCP SRパケット[15]でNTPタイムスタンプに対応するRTPタイムスタンプについて計算するとき、それが典型的な同期要件のための適切な解決を提供しないので、ビデオフレームレート(通常15〜30Hz)を使用するために十分ではありません。 また、タイムスタンプ解決も受信機レポートに含まれたジター見積りに十分であるに違いありません。
The standard video encodings and their payload types are listed in Table 2.
標準のビデオencodingsと彼らのペイロードタイプはTable2に記載されています。
7. Port Assignment
7. ポート課題
As specified in the RTP protocol definition, RTP data is to be carried on an even UDP port number and the corresponding RTCP packets are to be carried on the next higher (odd) port number.
RTPデータがRTPプロトコル定義で指定されるように同等のUDPポートナンバーで運ばれることであり、対応するRTCPパケットは次の、より高い(変な)ポートナンバーで運ばれることになっています。
Applications operating under this profile may use any such UDP port pair. For example, the port pair may be allocated randomly by a session management program. A single fixed port number pair cannot be required because multiple applications using this profile are likely to run on the same host, and there are some operating systems that do not allow multiple processes to use the same UDP port with different multicast addresses.
このプロフィールの下で作動するアプリケーションはどんなそのようなUDPポート組も使用するかもしれません。 例えば、セッション管理プログラムで手当たりしだいにポート組を割り当てるかもしれません。 このプロフィールを使用する複数のアプリケーションが同じホストで走りそうであって、複数のプロセスが異なったマルチキャストアドレスがある同じUDPポートを使用できないいくつかのオペレーティングシステムがあるので、固定1ポートナンバー組を必要とすることができません。
Schulzrinne Standards Track [Page 14] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[14ページ]
PT encoding audio/video clock rate channels
name (A/V) (Hz) (audio)
_______________________________________________________________
0 PCMU A 8000 1
1 1016 A 8000 1
2 G721 A 8000 1
3 GSM A 8000 1
4 unassigned A 8000 1
5 DVI4 A 8000 1
6 DVI4 A 16000 1
7 LPC A 8000 1
8 PCMA A 8000 1
9 G722 A 8000 1
10 L16 A 44100 2
11 L16 A 44100 1
12 unassigned A
13 unassigned A
14 MPA A 90000 (see text)
15 G728 A 8000 1
16--23 unassigned A
24 unassigned V
25 CelB V 90000
26 JPEG V 90000
27 unassigned V
28 nv V 90000
29 unassigned V
30 unassigned V
31 H261 V 90000
32 MPV V 90000
33 MP2T AV 90000
34--71 unassigned ?
72--76 reserved N/A N/A N/A
77--95 unassigned ?
96--127 dynamic ?
オーディオ/ビデオクロックレートをコード化するPTが名前(A/V)(Hz)(オーディオ)にチャネルを開設します。_______________________________________________________________ 0PCMU A8000 1 1 1016A8000 1 2G721A8000 1 3GSM A8000 1 4割り当てられなかったA8000 1 5DVI4A、8000 1 6DVI4A16000 1 7LPC A8000 1 8PCMA A8000 1 9G722A8000 1 10L16A44100 2 11L16A44100 1 12が割り当てなかった、A13がV25CelB V90000 26JPEG V90000 27が割り当てられなかったA24が割り当てられなかったA8000 1 16--23をA14MPA A90000(テキストを見ます)15G728に割り当てなかった、H261V90000 32MPV V90000 33MP2T AV90000 34--71が割り当てなかったV31が割り当てられなかったV30が割り当てられなかった割り当てられなかったV28nv V90000 29-- 72--76 予約されたN/A N/A N/A77--95に割り当てられませんか? 96--127 ダイナミックですか?
Table 2: Payload types (PT) for standard audio and video encodings
テーブル2: 標準のオーディオとビデオencodingsのための有効搭載量タイプ(太平洋標準時の)
However, port numbers 5004 and 5005 have been registered for use with this profile for those applications that choose to use them as the default pair. Applications that operate under multiple profiles may use this port pair as an indication to select this profile if they are not subject to the constraint of the previous paragraph. Applications need not have a default and may require that the port pair be explicitly specified. The particular port numbers were chosen to lie in the range above 5000 to accomodate port number allocation practice within the Unix operating system, where port numbers below 1024 can only be used by privileged processes and port numbers between 1024 and 5000 are automatically assigned by the operating
しかしながら、デフォルトが対にされるとき、ポートNo.5004と5005は使用のためにそれらを使用するのを選ぶそれらのアプリケーションのためのこのプロフィールに示されました。 それらは前のパラグラフの規制を受けることがないなら、複数のプロフィールの下で作動するアプリケーションが、このプロフィールを選択するのに指示としてこのポート組を使用するかもしれません。 アプリケーションは、デフォルトを持つ必要はなくて、ポート組が明らかに指定されるのを必要とするかもしれません。 指定港番号はUnixオペレーティングシステムの中に範囲に5000年より上でaccomodateポートナンバー配分練習に横たわるために選ばれて、どこで特権があるプロセスで1024の下におけるポートナンバーを使用できるだけであるか、そして、1024年と5000年の間ときのポートナンバーが作動で自動的に割り当てられるということでした。
Schulzrinne Standards Track [Page 15] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[15ページ]
system.
システム。
8. Bibliography
8. 図書目録
[1] Apple Computer, "Audio interchange file format AIFF-C," Aug.
1991. (also ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z).
[1]アップル・コンピューター、「オーディオ置き換えファイルはAIFF-Cをフォーマットする」1991年8月。 ( ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z も。)
[2] Office of Technology and Standards, "Telecommunications: Analog
to digital conversion of radio voice by 4,800 bit/second code
excited linear prediction (celp)," Federal Standard FS-1016, GSA,
Room 6654; 7th & D Street SW; Washington, DC 20407 (+1-202-708-
9205), 1990.
[2] 技術と規格のオフィス、「テレコミュニケーション:」 「4,800ビット/秒のコードによるラジオ声のA/D変換は直線的な予測(celp)を起こさせました」、連邦規格FS-1016、GSA、Room6654。 7番目とD通りSW。 ワシントン、DC (+1-202-708 9205)の20407、1990。
[3] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The
proposed Federal Standard 1016 4800 bps voice coder: CELP,"
Speech Technology , vol. 5, pp. 58--64, April/May 1990.
[3] J.P.キャンベル、Jr.、T.E.トレメイン、およびV.C.ウェルチ、「提案された連邦規格1016 4800ビーピーエスは符号化器を声に出します」。 "CELP"、Speech Technology、vol.5、ページ 58--64と、1990年4月/5月。
[4] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The federal
standard 1016 4800 bps CELP voice coder," Digital Signal
Processing, vol. 1, no. 3, pp. 145--155, 1991.
[4] J.P.キャンベル、Jr.、T.E.トレメイン、およびV.C.ウェルチ、「連邦の標準の1016 4800ビーピーエスCELP音声符号器」、Digital Signal Processing、vol.1、No.3、ページ 145--155, 1991.
[5] J. P. Campbell, Jr., T. E. Tremain, and V. C. Welch, "The dod 4.8
kbps standard (proposed federal standard 1016)," in Advances in
Speech Coding (B. Atal, V. Cuperman, and A. Gersho, eds.), ch.
12, pp. 121--133, Kluwer Academic Publishers, 1991.
[5] J.P.キャンベル、Jr.、T.E.トレメイン、およびV.C.ウェルチ、Speech Coding(B.Atal、V.CupermanとA.Gersho、eds)(ch)のAdvancesの「dod4.8キロビット毎秒規格(連邦の標準の1016を提案します)。」 12、ページ 121--133 Kluwerのアカデミックな出版社、1991。
[6] IMA Digital Audio Focus and Technical Working Groups,
"Recommended practices for enhancing digital audio compatibility
in multimedia systems (version 3.00)," tech. rep., Interactive
Multimedia Association, Annapolis, Maryland, Oct. 1992.
[6] 技術者IMAデジタル・オーディオFocusとTechnical Working Groups、「マルチメディア・システム(バージョン3.00)のデジタル・オーディオの互換性を高めるための推奨案」、レップ、インタラクティブ・マルチメディア協会(アナポリス(メリーランド)1992年10月)
[7] M. Mouly and M.-B. Pautet, The GSM system for mobile
communications Lassay-les-Chateaux, France: Europe Media
Duplication, 1993.
[7] M.ムリーとM.B。 Pautet、移動通信Lassay-les-Chateaux、フランスのGSMシステム: ヨーロッパメディア複製、1993。
[8] J. Degener, "Digital speech compression," Dr. Dobb's Journal,
Dec. 1994.
[8]J.Degener、「デジタルスピーチ圧縮」、ドッブ博士のJournal、1994年12月。
[9] S. M. Redl, M. K. Weber, and M. W. Oliphant, An Introduction to
GSM Boston: Artech House, 1995.
[9] S.M.Redl、M.K.ウェーバー、およびM.W.オリファント、GSMボストンへの序論: Artech家、1995。
[10] D. Hoffman and V. Goyal, "RTP payload format for MPEG1/MPEG2
video," Work in Progress, Internet Engineering Task Force, June
1995.
[10] D.ホフマンとV.Goyal、「MPEG1/MPEG2ビデオのためのRTPペイロード形式」、Progress、インターネット・エンジニアリング・タスク・フォース(1995年6月)におけるWork。
[11] N. S. Jayant and P. Noll, Digital Coding of Waveforms--
Principles and Applications to Speech and Video Englewood Cliffs,
New Jersey: Prentice-Hall, 1984.
[11]N.S.JayantとP.ノル、波形のデジタルコード化--スピーチへの原則とアプリケーションとビデオイングルウッドがけ、ニュージャージー: 新米のホール、1984。
Schulzrinne Standards Track [Page 16] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[16ページ]
[12] M. F. Speer and D. Hoffman, "RTP payload format of CellB video
encoding," Work in Progress, Internet Engineering Task Force,
Aug. 1995.
[12] M.F.シュペーアとD.ホフマン、「CellBビデオのコード化のRTPペイロード形式」、Progress、インターネット・エンジニアリング・タスク・フォース(1995年8月)におけるWork。
[13] W. Fenner, L. Berc, R. Frederick, and S. McCanne, "RTP
encapsulation of JPEG-compressed video," Work in Progress,
Internet Engineering Task Force, Mar. 1995.
[13] W.フェナー、L.Berc、R.フレディリック、およびS.McCanne、「JPEGによって圧縮されたビデオのRTPカプセル化」、Progress、インターネット・エンジニアリング・タスク・フォース(1995年3月)におけるWork。
[14] T. Turletti and C. Huitema, "RTP payload format for H.261 video
streams," Work in Progress, Internet Engineering Task Force, July
1995.
[14] T.TurlettiとC.Huitema、「H.261ビデオのためのRTPペイロード形式は流れます」、ProgressのWork、インターネット・エンジニアリング・タスク・フォース、1995年7月。
[15] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
transport protocol for real-time applications." Work in Progress,
Mar. 1995.
[15] H.Schulzrinne、S.Casner、R.フレディリック、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル。」 進歩、1995年3月に、働いてください。
9. Security Considerations
9. セキュリティ問題
Security issues are discussed in section 2.
セクション2で安全保障問題について議論します。
10. Acknowledgements
10. 承認
The comments and careful review of Steve Casner are gratefully acknowledged.
スティーブCasnerのコメントと慎重なレビューは感謝して承諾されます。
11. Author's Address
11. 作者のアドレス
Henning Schulzrinne GMD Fokus Hardenbergplatz 2 D-10623 Berlin Germany
ヘニングSchulzrinne GMD Fokus Hardenbergplatz2D-10623ベルリンドイツ
EMail: schulzrinne@fokus.gmd.de
メール: schulzrinne@fokus.gmd.de
Schulzrinne Standards Track [Page 17] RFC 1890 AV Profile January 1996
RFC1890AVが1996年1月に輪郭を描くSchulzrinne標準化過程[17ページ]
Current Locations of Related Resources
関連リソースの現在の位置
UTF-8
UTF-8
Information on the UCS Transformation Format 8 (UTF-8) is available at
(UTF-8)が利用可能であるUCS Transformation Format8に関する情報
http://www.stonehand.com/unicode/standard/utf8.html
http://www.stonehand.com/unicode/standard/utf8.html
1016
1016
An implementation is available at
実装は利用可能です。
ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z
ftp://ftp.super.org/pub/speech/celp_3.2a.tar.Z
DVI4
DVI4
An implementation is available from Jack Jansen at
実装はジャック・ヤンセンから利用可能です。
ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar
ftp://ftp.cwi.nl/local/pub/audio/adpcm.shar
G721
G721
An implementation is available at
実装は利用可能です。
ftp://gaia.cs.umass.edu/pub/hgschulz/ccitt/ccitt_tools.tar.Z
ftp://gaia.cs.umass.edu/pub/hgschulz/ccitt/ccitt_tools.tar.Z
GSM
GSM
A reference implementation was written by Carsten Borman and Jutta Degener (TU Berlin, Germany). It is available at
参照実装はカルステン・ボーマンとユッタDegener(TUベルリン(ドイツ))によって書かれました。 それは利用可能です。
ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/
ftp://ftp.cs.tu-berlin.de/pub/local/kbs/tubmik/gsm/
LPC
LPC
An implementation is available at
実装は利用可能です。
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z
ftp://parcftp.xerox.com/pub/net-research/lpc.tar.Z
Schulzrinne Standards Track [Page 18]
Schulzrinne標準化過程[18ページ]
一覧
スポンサーリンク
