RFC2343 日本語訳

Network Working Group                                          M. Civanlar
Request for Comments: 2343                                         G. Cash
Category: Experimental                                          B. Haskell
                                                        AT&T Labs-Research
                                                                  May 1998

Civanlarがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2343年のG.現金カテゴリ: 実験的なB.ハスケルAT&T研究室研究1998年5月

                  RTP Payload Format for Bundled MPEG

束ねられたMPEGのためのRTP有効搭載量形式

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

Abstract

要約

   This document describes a payload type for bundled, MPEG-2 encoded
   video and audio data that may be used with RTP, version 2. Bundling
   has some advantages for this payload type particularly when it is
   used for video-on-demand applications. This payload type may be used
   when its advantages are important enough to sacrifice the modularity
   of having separate audio and video streams.

このドキュメントがペイロードタイプについて説明する、束ねられます、MPEG-2はRTP(バージョン2)と共に使用されるかもしれないビデオとオーディオデータをコード化しました。 特にそれがビデオ・オン・デマンドアプリケーションに使用されるとき、バンドリングには、このペイロードタイプのためのいくつかの利点があります。 利点が別々のオーディオとビデオストリームを持つモジュール方式を犠牲にすることができるくらい重要であるときに、このペイロードタイプは使用されるかもしれません。

1. Introduction

1. 序論

   This document describes a bundled packetization scheme for MPEG-2
   encoded audio and video streams using the Real-time Transport
   Protocol (RTP), version 2 [1].

このドキュメントはレアル-時間Transportプロトコル(RTP)を使用することでMPEG-2つのコード化されたオーディオとビデオストリームの束ねられたpacketization計画について説明します、バージョン2[1]。

   The MPEG-2 International standard consists of three layers: audio,
   video and systems [2]. The audio and the video layers define the
   syntax and semantics of the corresponding "elementary streams." The
   systems layer supports synchronization and interleaving of multiple
   compressed streams, buffer initialization and management, and time
   identification.  RFC 2250 [3] describes packetization techniques to
   transport individual audio and video elementary streams as well as
   the transport stream, which is defined at the system layer, using the
   RTP.

MPEG-2の国際規格は3つの層から成ります: オーディオ、ビデオ、およびシステム[2]。 オーディオとビデオ層は対応する「基本の流れ」の構文と意味論を定義します。システム層は複数の圧縮された流れ、バッファ初期化、管理、および時間識別の同期とインターリービングを支持します。 RFC2250[3]はシステム層で定義される輸送の流れと同様に個々のオーディオとビデオの基本のストリームを輸送するためにpacketizationのテクニックについて説明します、RTPを使用して。

Civanlar, et. al.             Experimental                      [Page 1]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998

et Civanlar、アル。 束ねられたMPEG1998年5月のための実験的な[1ページ]RFC2343RTP有効搭載量形式

   The bundled packetization scheme is needed because it has several
   advantages over other schemes for some important applications
   including video-on-demand (VOD) where, audio and video are always
   used together.  Its advantages over independent packetization of
   audio and video are:

束ねられたpacketization計画はそれにはいくつかの利点があるので必要であることで、他上に、(VOD)どこがビデオ・オン・デマンドを含むいくつかの重要なアプリケーションを計画しているか、そして、オーディオとビデオがいつも一緒に使用されるということです。 オーディオとビデオの独立しているpacketizationより利点は以下の通りです。

     1. Uses a single port per "program" (i.e. bundled A/V).  This may
     increase the number of streams that can be served e.g., from a VOD
     server. Also, it eliminates the performance hit when two ports are
     used for the separate audio and video streams on the client side.

1. 「プログラム」(すなわち、A/Vを束ねる)あたり1つの単一のポートを使用します。 これは例えば、VODサーバから役立つことができる流れの数を増加させるかもしれません。また、それは2つのポートがクライアント側における別々のオーディオとビデオストリームに使用されるとき打たれた性能を排除します。

     2. Provides implicit synchronization of audio and video.  This is
     particularly convenient when the A/V data is stored in an
     interleaved format at the server.

2. オーディオとビデオの暗黙の同期を提供します。 A/Vデータがサーバにおけるはさみ込まれた形式で格納されるとき、これは特に便利です。

     3. Reduces the header overhead. Since using large packets increases
     the effects of losses and delay, audio only packets need to be
     smaller increasing the overhead. An A/V bundled format can provide
     about 1% overall overhead reduction. Considering the high bitrates
     used for MPEG-2 encoded material, e.g. 4 Mbps, the number of bits
     saved, e.g. 40 Kbps, may provide noticeable audio or video quality
     improvement.

3. ヘッダーオーバーヘッドを下げます。 以来大きいパケットを使用すると、損失と遅れの効果は増加して、唯一のオーディオは小さくよりなるオーバーヘッドを上げるパケットの必要性です。 A/V束ねられた形式はおよそ1%の総合的な頭上の減少を供給できます。 MPEG-2に使用される高いbitratesを考えると、材料はコード化されました、例えば、4Mbps(節約されたビット、例えば、40Kbpsの数)がめぼしいオーディオかビデオ品質改良を提供するかもしれません。

     4. May reduce overall receiver buffer size. Audio and video streams
     may experience different delays when transmitted separately. The
     receiver buffers need to be designed for the longest of these
     delays. For example, let's assume that using two buffers, each with
     a size B, is sufficient with probability P when each stream is
     transmitted individually. The probability that the same buffer size
     will be sufficient when both streams need to be received is P times
     the conditional probability of B being sufficient for the second
     stream given that it was sufficient for the first one. This
     conditional probability is, generally, less than one requiring use
     of a larger buffer size to achieve the same probability level.

4. 総合的な受信機バッファサイズを減少させるかもしれません。 別々に伝えられると、オーディオとビデオストリームは異なった遅れになるかもしれません。 バッファが最も長いこれらのために設計されるために必要とする受信機は延着します。 例えば、各小川が個別に伝えられるとき、2つのバッファを使用するのがそれぞれサイズBに確率Pに十分であると仮定しましょう。 同じバッファサイズがそれが与えられた2番目の流れに十分なBの条件付き確率の倍でしたが、両方の流れが、受け取っているのが、Pであることである必要があるとき、十分であるために最初のものに十分な状態で望んでいるという確率。 一般に、この条件付き確率は同じ確率水準を達成するために大きめのバッファサイズの使用を必要とするものです。

     5. May help with the control of the overall bandwidth used by an
     A/V program.

5. 総合的な帯域幅のコントロールがA/Vプログラムで使用されている状態で、助けるかもしれません。

   And, the advantages over packetization of the transport layer streams
   are:

そして、トランスポート層の流れのpacketizationより利点は以下の通りです。

     1. Reduced overhead. It does not contain systems layer information
     which is redundant for the RTP (essentially they address similar
     issues).

1. 経費を削減しました。 それはRTPに、余分なシステム層の情報を含んでいません(本質的にはそれらは同様の問題を記述します)。

Civanlar, et. al.             Experimental                      [Page 2]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998

et Civanlar、アル。 束ねられたMPEG1998年5月のための実験的な[2ページ]RFC2343RTP有効搭載量形式

     2. Easier error recovery. Because of the structured packetization
     consistent with the application layer framing (ALF) principle, loss
     concealment and error recovery can be made simpler and more
     effective.

2. より簡単なエラー回復。 応用層縁どり(ALF)原則と一致した構造化されたpacketizationのために、損失隠すこととエラー回復をより簡単でより効果的にすることができます。

2. Encapsulation of Bundled MPEG Video and Audio

2. 束ねられたMPEGビデオとオーディオのカプセル化

   Video encapsulation follows rules similar to the ones described in
   [3] for encapsulation of MPEG elementary streams. Specifically,

ビデオカプセル化がMPEGの基本の流れのカプセル化のための[3]で説明されたものと同様の規則に従う、明確に。

     1. The MPEG Video_Sequence_Header, when present, will always be at
     the beginning of an RTP payload.

1. RTPペイロードの始めに存在しているとき、いつもMPEG Video_Sequence_Headerはそうでしょう。

     2. An MPEG GOP_header, when present, will always be at the
     beginning of the RTP payload, or will follow a
     Video_Sequence_Header.

2. 存在しているとき、MPEG共和党_ヘッダーは、RTPペイロードの始めに、いつもあるか、またはVideo_Sequence_Headerの後をつけるでしょう。

     3. An MPEG Picture_Header, when present, will always be at the
     beginning of a RTP payload, or will follow a GOP_header.

3. 存在しているとき、MPEG Picture_HeaderはRTPペイロードの始めに、いつもあるか、または共和党_ヘッダーに続くでしょう。

   In addition to these, it is required that:

これらに加えて、以下のことが必要です。

     4. Each packet must contain an integral number of video slices.

4. 各パケットは整数のビデオ部分を含まなければなりません。

   It is the application's responsibility to adjust the slice sizes and
   the number of slices put in each RTP packet so that lower level
   fragmentation does not occur. This approach simplifies the receivers
   while somewhat increasing the complexity of the transmitter's
   packetizer. Considering that a slice can be as small as a single
   macroblock, it is possible to prevent fragmentation for most of the
   cases.  If a packet size exceeds the path maximum transmission unit
   (path-MTU) [4], this payload type depends on the lower protocol
   layers for fragmentation although, this may cause problems with
   packet classification for integrated services (e.g. with RSVP).

下のレベル断片化が起こらないようにそれぞれのRTPパケットに入れられた部分の部分サイズと数を調整するのは、アプリケーションの責任です。 このアプローチは送信機のpacketizerの複雑さをいくらか増加させている間、受信機を簡素化します。 部分が単一のmacroblockと同じくらいわずかであることができると考える場合、ケースの大部分の断片化を防ぐのは可能です。 パケットサイズが経路マキシマム・トランスミッション・ユニット(経路-MTU)[4]を超えているなら、このペイロードタイプが断片化のために低級プロトコル層を当てにする、これは統合サービス(例えば、RSVPと)のためのパケット分類に関する原因問題がそうするかもしれません。

   The video data is followed by a sufficient number of integral audio
   frames to cover the duration of the video segment included in a
   packet.  For example, if the first packet contains three 1/900
   seconds long slices of video, and Layer I audio coding is used at a
   44.1kHz sampling rate, only one audio frame covering 384/44100
   seconds of audio need be included in this packet. Since the length of
   this audio frame (8.71 msec.) is longer than that of the video
   segment contained in this packet (3.33 msec), the next few packets
   may not contain any audio frames until the packet in which the
   covered video time extends outside the length of the previously
   transmitted audio frames. Alternatively, it is possible, in this
   proposal, to repeat the latest audio frame in "no-audio" packets for

パケットにビデオセグメントの持続時間を含んでいて、覆う十分な数の不可欠のオーディオフレームがビデオ・データを支えています。 例えば、最初のパケットがビデオの長い部分をthree 1/900秒含んでいて、Layer Iオーディオ符号化が44.1kHzの標本抽出率で使用されるなら、384/44100秒のオーディオをカバーするあるオーディオフレームだけがこのパケットに含まれなければなりません。 このオーディオフレーム(8.71msec)の長さがビデオセグメントのものがこのパケットに(3.33msec)を含んだより長いので、次のわずかなパケットは覆われたビデオ時間が以前に伝えられたオーディオフレームの長さの外で広がるパケットまでどんなオーディオフレームも含まないかもしれません。 あるいはまた、それは、「オーディオがありません」パケットで最新のオーディオフレームを繰り返すためにこの提案で可能です。

Civanlar, et. al.             Experimental                      [Page 3]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998

et Civanlar、アル。 束ねられたMPEG1998年5月のための実験的な[3ページ]RFC2343RTP有効搭載量形式

   packet loss resilience. Again, it is the application's responsibility
   to adjust the bundled packet size according to the minimum MTU size
   to prevent fragmentation.

パケット損失弾力。 一方、最小のMTUサイズに応じて断片化を防ぐように束ねられたパケットサイズを調整するのは、アプリケーションの責任です。

2.1. RTP Fixed Header for BMPEG Encapsulation

2.1. BMPEGカプセル化のためのヘッダーに固定されたRTP

   The following RTP header fields are used:

以下のRTPヘッダーフィールドは使用されています:

     Payload Type: A distinct payload type number, which may be dynamic,
     should be assigned to BMPEG.

有効搭載量タイプ: 異なったペイロード形式数(ダイナミックであるかもしれない)はBMPEGに割り当てられるべきです。

     M Bit: Set for packets containing end of a picture.

Mは噛み付きました: 絵の端を含むパケットには、セットしてください。

     timestamp: 32-bit 90 kHz timestamp representing sampling time of
     the MPEG picture. May not be monotonically increasing if B pictures
     are present. Same for all packets belonging to the same picture.
     For packets that contain only a sequence, extension and/or GOP
     header, the timestamp is that of the subsequent picture.

タイムスタンプ: MPEGの絵の標本抽出時間を表す90kHzの32ビットのタイムスタンプ。 Bの絵が存在しているなら、単調に増加していないかもしれません。 同じ絵に属すすべてのパケットにおいて、同じです。 系列だけを含むパケット、拡大、そして/または、共和党ヘッダーにおいて、タイムスタンプはその後の絵のものです。

2.2. BMPEG Specific Header:

2.2. BMPEGの特定のヘッダー:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | P |N|MBZ|    Audio Length   | |         Audio Offset          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 MBZ

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P|N|MBZ| オーディオの長さ| | オーディオは相殺されました。| +++++++++++++++++++++++++++++++++MBZ

    P: Picture type (2 bits). I (0), P (1), B (2).

P: タイプ(2ビット)について描写してください。 I(0)、P(1)、B(2)。

    N: Header data changed (1 bit). Set if any part of the video
    sequence, extension, GOP and picture header data is different than
    that of the previously sent headers. It gets reset when all the
    header data gets repeated (see Appendix 1).

N: ヘッダー・データは変化しました(1ビット)。 ビデオ系列、拡大、共和党、および絵のヘッダー・データのどれか部分が以前に送られたヘッダーのものと異なるなら、セットしてください。 すべてのヘッダー・データが繰り返されるとき(Appendix1を見てください)、それはリセットされます。

    MBZ: Must be zero. Reserved for future use.

MBZ: ゼロにならなければならなくなってください。 今後の使用のために、予約されます。

    Audio Length: (10 bits) Length of the audio data in this packet in
    bytes. Start of the audio data is found by subtracting "Audio
    Length" from the total length of the received packet.

オーディオの長さ: (10ビット) バイトで表現されるこのパケットのオーディオデータの長さ。 オーディオデータの始まりは、容認されたパケットの全長から「オーディオの長さ」を引き算することによって、見つけられます。

    Audio Offset: (16 bits) The offset between the start of the audio
    frame and the RTP timestamp for this packet in number of audio
    samples (for multi-channel sources, a set of samples covering all
    channels is counted as one sample for this purpose.)

オーディオは相殺されました: (16ビット) オーディオフレームの始まりとこのパケットのためのRTPタイムスタンプの間のオーディオのサンプルの数におけるオフセット(マルチチャンネルソースにおいて、オール・チャンネルに関する1セットのサンプルが1個のサンプルにこのためにみなされます。)

Civanlar, et. al.             Experimental                      [Page 4]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998

et Civanlar、アル。 束ねられたMPEG1998年5月のための実験的な[4ページ]RFC2343RTP有効搭載量形式

    Audio offset is a signed integer in two's complement form. It allows
    a ~ +/- 750 msec offset at 44.1 KHz audio sampling rate. For a very
    low video frame rate (e.g., a frame per second), this offset may not
    be sufficient and this payload format may not be usable.

オーディオオフセットは2の補数フォームのサインされた整数です。 それは44.1KHzオーディオ標本抽出率で750msecオフセットを~、に+/-許します。 非常に低いビデオフレームレート(例えば、1秒あたり1個のフレーム)では、このオフセットは十分でないかもしれません、そして、このペイロード形式は使用可能でないかもしれません。

    If  B frames are present, audio frames are not re-ordered along with
    video.  Instead, they are packetized along with video frames in
    their transmission order  (e.g., an audio segment packetized with a
    video segment corresponding to a P picture may belong to a B
    picture, which will be transmitted later and should be rendered at
    the same time with this audio segment.) Even though the video
    segments are reordered, the audio offset for a particular audio
    segment is still relative to the RTP timestamp in the packet
    containing that audio segment.

Bフレームが存在しているなら、オーディオフレームはビデオと共に再注文されません。 代わりに、それらは彼らのトランスミッション命令におけるビデオフレームと共にpacketizedされます(例えばPの絵に対応するビデオセグメントでpacketizedされたオーディオセグメントはこのオーディオセグメントで後で送られて、同時に表されるべきであるBの絵に属すかもしれません。)。 ビデオセグメントは再命令されますが、そのオーディオセグメントを含んでいて、特定のオーディオセグメントのために相殺されたオーディオはパケットにまだRTPタイムスタンプに比例しています。

    Since a special picture counter, such as  the "temporal reference
    (TR)" field of [3], is not included in this payload format, lost GOP
    headers may not be detected.  The only effect of this may be
    incorrect decoding of the B pictures immediately following the lost
    GOP header for some edited video material.

[3]の「時の参照(TR)」分野などの特別な絵のカウンタがこのペイロード形式で含まれていないので、迷子になった共和党ヘッダーは検出されないかもしれません。 何らかの編集されたビデオ資料のための迷子になった共和党ヘッダーに続いて、この唯一の効果が、すぐにBの絵を解読しながら、不正確であるかもしれません。

3. Security Considerations

3. セキュリティ問題

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [1]. 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仕様[1]で議論したセキュリティ問題を受けることがあります。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 このペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化が圧縮の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。

   This payload type does not exhibit any significant non-uniformity in
   the receiver side computational complexity for packet processing  to
   cause a potential denial-of-service threat.

パケット処理が潜在的サービスの否定の脅威を引き起こすように、このペイロードタイプは受信機サイド計算量における少しの重要な非の一様性も示しません。

   A security review of this payload format found no additional
   considerations beyond those in the RTP specification.

このペイロード形式の安全レビューはRTP仕様によるそれらを超えてどんな追加問題も見つけませんでした。

Civanlar, et. al.             Experimental                      [Page 5]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998

et Civanlar、アル。 束ねられたMPEG1998年5月のための実験的な[5ページ]RFC2343RTP有効搭載量形式

Appendix 1. Error Recovery

付録1。 エラー回復

   Packet losses can be detected from a combination of the sequence
   number and the timestamp fields of the RTP fixed header. The extent
   of the loss can be determined from the timestamp, the slice number
   and the horizontal location of the first slice in the packet. The
   slice number and the horizontal location can be determined from the
   slice header and the first macroblock address increment, which are
   located at fixed bit positions.

ヘッダーに固定されたRTPの一連番号とタイムスタンプ分野の組み合わせからパケット損失を検出できます。 パケットにおける最初の部分のタイムスタンプ、部分番号、および水平な位置から損失の範囲を測定できます。 部分番号と水平な位置は部分ヘッダーと最初のmacroblockアドレス増分から決定できます。(それは、固定ビット位置に位置しています)。

   If lost data consists of slices all from the same picture, new data
   following the loss may simply be given to the video decoder which
   will normally repeat missing pixels from a previous picture. The next
   audio frame must be played at the appropriate time determined by the
   timestamp and the audio offset contained in the received packet.
   Appropriate audio frames (e.g., representing background noise) may
   need to be fed to the audio decoder in place of the lost audio frames
   to keep the lip-synch and/or to conceal the effects of the losses.

ロストデータがすべて同じ絵からの部分から成るなら、単に通常、前の絵からのなくなった画素を繰り返すビデオデコーダに損失に続く新しいデータを与えるかもしれません。 タイムスタンプで決定している適切な時期と容認されたパケットに含まれたオーディオのオフセットで隣のオーディオフレームに上演されなければなりません。 適切なオーディオフレーム(例えば、バックグラウンドノイズを表す)は、口パクを保って、損失の影響を隠すために無くなっているオーディオフレームに代わってオーディオデコーダへ供給される必要があるかもしれません。

   If the received new data after a loss is from the next picture (i.e.
   no complete picture loss) and the N bit is not set, previously
   received headers for the particular picture type (determined from the
   P bits) can be given to the video decoder followed by the new data.
   If N is set, data deletion until a new picture start code is
   advisable unless headers are made available to the receiver through
   some other channel.

損失が次の絵(すなわち、完全な絵の損失がない)とNビットから来ていた後に受信された新しいデータを設定しないなら、特定の絵のタイプ(Pビットから断固とした)のための以前に容認されたヘッダーを新しいデータがあとに続いたビデオデコーダに与えることができます。 Nを設定して、ヘッダーをある他のチャンネルで受信機に利用可能にしない場合、新しい絵のスタートコードまでのデータ削除は賢明です。

   If data for more than one picture is lost and headers are not
   available, unless N is zero and at least one packet has been received
   for every intervening picture of the same type and that the N bit was
   0 for each of those pictures, resynchronization to a new video
   sequence header is advisable.

1枚以上の絵のためのデータが無くなって、Nがゼロであり、同じタイプとそのあらゆる介入している絵のために少なくとも1つのパケットを受け取るというわけではなくて、ヘッダーが手があかないなら、Nビットがそれぞれのそれらの絵のための0であった、新しいビデオ系列ヘッダーとの再同期は賢明です。

   In all cases of heavy packet losses, if the correct headers for the
   missing Pictures are available, they can be given to the video
   decoder and the received data can be used irrespective of the N bit
   value or the number of lost pictures.

重いパケット損失のすべての場合では、なくなったPicturesのための正しいヘッダーが手があくなら、ビデオデコーダに彼らを与えることができます、そして、Nビットの値か無くなっている絵の数の如何にかかわらず受信データを使用できます。

Appendix 2. Resynchronization

付録2。 Resynchronization

   As described in [3], use of frequent video sequence headers makes it
   possible to join in a program at arbitrary times. Also, it reduces
   the resynchronization time after severe losses.

[3]で説明されるように、頻繁なビデオ系列ヘッダーの使用で任意の時にプログラムに参加するのは可能になります。 また、それは著しい損失の後の再同期時に減少します。

Civanlar, et. al.             Experimental                      [Page 6]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998

et Civanlar、アル。 束ねられたMPEG1998年5月のための実験的な[6ページ]RFC2343RTP有効搭載量形式

References

参照

   [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
       "RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
       January 1996.

[1]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。

   [2] ISO/IEC International Standard 13818; "Generic coding of moving
       pictures and associated audio information," November 1994.

[2] ISO/IEC国際規格13818。 1994年11月の「映画と関連オーディオ情報の一般的なコード化」。

   [3] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP
       Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.

1998年1月の[3] ホフマンとD.とフェルナンドとG.とGoyal、V.とM.Civanlar、「MPEG1/MPEG2ビデオのためのRTP有効搭載量形式」RFC2250。

   [4] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.

[4] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。

Authors'  Addresses

作者のアドレス

   M. Reha Civanlar
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

M.の研究室研究の100のシュルツのドライブの赤いReha Civanlar AT&T銀行、ニュージャージー07701米国

   EMail: civanlar@research.att.com

メール: civanlar@research.att.com

   Glenn L. Cash
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

グレンL.現金AT&T研究室研究100のシュルツのドライブの赤い銀行、ニュージャージー07701米国

   EMail: glenn@research.att.com

メール: glenn@research.att.com

   Barry G. Haskell
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

バリーG.ハスケルAT&T研究室研究100のシュルツのドライブの赤い銀行、ニュージャージー07701米国

   EMail: bgh@research.att.com

メール: bgh@research.att.com

Civanlar, et. al.             Experimental                      [Page 7]

RFC 2343          RTP Payload Format for Bundled MPEG           May 1998

et Civanlar、アル。 束ねられたMPEG1998年5月のための実験的な[7ページ]RFC2343RTP有効搭載量形式

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Civanlar, et. al.             Experimental                      [Page 8]

et Civanlar、アル。 実験的[8ページ]