RFC2038 日本語訳
2038 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G.Fernando, V. Goyal. October 1996. (Format: TXT=23266 bytes) (Obsoleted by RFC2250) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Hoffman
Request for Comments: 2038 G. Fernando
Category: Standards Track Sun Microsystems, Inc.
V. Goyal
Precept Software, Inc.
October 1996
コメントを求めるワーキンググループD.ホフマン要求をネットワークでつないでください: 2038年のG.フェルナンドカテゴリ: 標準化過程サン・マイクロシステムズ・インクV.Goyal教訓ソフトウェアInc.1996年10月
RTP Payload Format for MPEG1/MPEG2 Video
MPEG1/MPEG2ビデオのための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 packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF.
このメモはMPEGビデオとオーディオストリームのpacketization計画について説明します。RTPによってサポートされたトランスポート・プロトコルの上でそのようなビデオかオーディオ流動を輸送するのに提案された計画は使用できます。 2つのアプローチが説明されます。 1番目は、MPEG System環境で最大限のインターオペラビリティを支持するように設計されています。 2番目は、IETFの他のRTPによって要約されたメディアの流れと今後の会議コントロール仕事を最大の互換性に提供するように設計されています。
1. Introduction
1. 序論
ISO/IEC JTC1/SC29 WG11 (also referred to as the MPEG committee) has defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard (ISO/IEC 13818)[2]. This memo describes a packetization scheme to transport MPEG video and audio streams using the Real-time Transport Protocol (RTP), version 2 [3, 4].
ISO/IEC JTC1/SC29 WG11(また、MPEG委員会と呼ばれる)はMPEG1規格(ISO/IEC11172)[1]とMPEG2規格(ISO/IEC13818)[2]を定義しました。 このメモはレアル-時間Transportプロトコル(RTP)を使用することでMPEGビデオとオーディオストリームを輸送するためにpacketization計画について説明します、バージョン2[3、4]。
The MPEG1 specification is defined in three parts: System, Video and Audio. It is designed primarily for CD-ROM-based applications, and is optimized for approximately 1.5 Mbits/sec combined data rates. The video and audio portions of the specification describe the basic format of the video or audio stream. These formats define the Elementary Streams (ES). The MPEG1 System specification defines an encapsulation of the ES that contains Presentation Time Stamps (PTS), Decoding Time Stamps and System Clock references, and performs multiplexing of MPEG1 compressed video and audio ES's with user data.
MPEG1仕様は3つの部品で定義されます: システム、ビデオ、およびオーディオ。 それは、主としてCD-ROMベースのアプリケーションのために設計されていて、およそ1.5メガビット/秒結合したデータ信号速度のために最適化されます。 仕様のビデオとオーディオ部分はビデオかオーディオストリームの基本形式について説明します。 これらの形式はElementary Streams(ES)を定義します。 MPEG1 System仕様はそれがPresentation Timeスタンプス(PTS)、Decoding Timeスタンプス、およびSystem Clock参照を含んでいて、マルチプレクシングを実行するESのカプセル化を定義します。MPEG1は利用者データでビデオとオーディオESのものを圧縮しました。
Hoffman, et. al. Standards Track [Page 1] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[1ページ]。
The MPEG2 specification is structured in a similar way. However, it hasn't been restricted only to CD-ROM applications. The MPEG2 System specification defines two system stream formats: the MPEG2 Transport Stream (MTS) and the MPEG2 Program Stream (MPS). The MTS is tailored for communicating or storing one or more programs of MPEG2 compressed data and also other data in relatively error-prone environments. The MPS is tailored for relatively error-free environments.
MPEG2仕様は同様の方法で構造化されます。 しかしながら、それはCD-ROMアプリケーションだけに制限されていません。 MPEG2 System仕様は2つのシステム流れの書式を定義します: MPEG2は流れ(MTS)とMPEG2プログラムストリーム(MPS)を輸送します。 MTSは誤り比較的傾向がある環境で、圧縮されたデータがMPEG2に関する1つ以上のプログラムを伝えるか、または格納するために合わせて、また、他のデータを合わせます。 MPSは比較的エラーのない環境のために仕立てられます。
We seek to achieve interoperability among 4 types of end-systems in the following specification. The 4 types are:
私たちは以下の仕様による4つのタイプのエンドシステムの中で相互運用性を達成しようとします。 4つのタイプは以下の通りです。
1. Transmitting Interworking Unit (TIU)
1. ユニットを織り込みながら、伝わります。(TIU)
Receives MPEG information from a native MTS system for
distribution over packet networks using a native RTP-based
system layer (such as an IP-based internetwork). Examples:
real-time encoder, MTS satellite link to Internet, video
server with MTS-encoded source material.
分配の固有のMTSシステムからMPEG情報をパケット網の上に自然なRTPベースのシステム層(IPベースのインターネットワークなどの)を使用することで受け取ります。 例: リアルタイムのエンコーダ、インターネットへのMTS衛星中継、MTSによってコード化された資料があるビデオ・サーバ。
2. Receiving Interworking Unit (RIU)
2. ユニットを織り込みながら、受信します。(RIU)
Receives MPEG information in real time from an RTP-based
network for forwarding to a native MTS environment.
Examples: Internet-based video server to MTS-based cable
distribution plant.
リアルタイムで、推進のためのRTPを拠点とするネットワークからネイティブのMTS環境までMPEG情報を受け取ります。 例: MTSベースのケーブル配電設備へのインターネットを利用するビデオ・サーバ。
3. Transmitting Internet End-System (TAES)
3. インターネットエンドシステムを送ります。(TAES)
Transmits MPEG information generated or stored within the
internet end-system itself, or received from internet-based
computer networks. Example: video server.
インターネットエンドシステム自体の中に発生するか、格納される、またはインターネットベースのコンピュータネットワークから受け取られたMPEG情報を伝えます。 例: ビデオ・サーバ。
4. Receiving Internet End-System (RAES)
4. インターネットエンドシステムを受け止めます。(RAES)
Receives MPEG information over an RTP-based internet for
consumption at the internet end-system or forwarding to
traditional computer network. Example: desktop PC or
workstation viewing training video.
伝統的なコンピュータネットワークへのインターネットエンドシステムか推進のときに消費でRTPベースのインターネットの上にMPEG情報を受け取ります。 例: トレーニングビデオを見るデスクトップパソコンかワークステーション。
Each of the 2 types of transmitters must work with each of the 2 types of receivers. Because it is probable that the TAES, and certain that the RAES, will be based on existing and planned internet-connected computers, it is highly desirable for the interoperable protocol to be based on RTP.
それぞれの2つのタイプの送信機はそれぞれの2つのタイプの受信機で動作しなければなりません。 それがありえそうである、それ、TAESであって、共同利用できるプロトコルがRTPに基づくのは、RAESが存在するのに基づいて計画するようになるのがコンピュータをインターネットで接続して、それが非常に望ましいのを確信しています。
Because of the range of applications that might employ MPEG streams, we propose to define two payload formats.
MPEGの流れを使うかもしれないアプリケーションの範囲のために、私たちは、2つのペイロード書式を定義するよう提案します。
Hoffman, et. al. Standards Track [Page 2] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[2ページ]。
Much interest in the MPEG community is in the use of one of the MPEG System encodings, and hence, in Section 2 we propose encapsulations of MPEG1 System streams and MPEG2 Transport and Program Streams with RTP. This profile supports the full semantics of MPEG System and offers basic interoperability among all four end-system types.
MPEG共同体への大きな関心がMPEG System encodingsの1つの使用であります、そして、したがって、セクション2では、私たちはRTPと共にMPEG1 Systemの流れ、MPEG2 Transport、およびProgram Streamsのカプセル化を提案します。 このプロフィールは、MPEG Systemの完全な意味論を支持して、すべての4つのエンドシステムタイプに基本的な相互運用性を提供します。
When operating only among internet-based end-systems (i.e., TAES and RAES) a payload format that provides greater compatibility with the Internet architecture is desired, deferring some of the system issues to other protocols being defined in the Internet community (such as the MMUSIC WG). In Section 3 we propose an encapsulation of compressed video and audio data (referred to in MPEG documentation as "Elementary Streams" (ES)) complying with either MPEG1 or MPEG2. Here, neither of the System standards of MPEG1 or MPEG2 are utilized. The ES's are directly encapsulated with RTP.
インターネットベースのエンドシステム(すなわち、TAESとRAES)だけの中で作動するとき、インターネット構造をより大きい互換性に提供するペイロード形式は望まれています、インターネットコミュニティ(MMUSIC WGなどの)で定義される他のプロトコルにシステム銘柄のいくつかを延期して。 セクション3では、私たちはMPEG1かMPEG2のどちらかがある圧縮されたビデオとオーディオのデータ(MPEGドキュメンテーションでは、「基本の流れ」(ES)に言及される)の応じることのカプセル化を提案します。 ここで、MPEG1かMPEG2のSystem規格のどちらも利用されていません。 ESのものはRTPと共に直接要約されます。
Throughout this specification, we make extensive use of MPEG terminology. The reader should consult the primary MPEG references for definitive descriptions of this terminology.
この仕様中では、私たちはMPEG用語の大規模な使用をします。 読者はこの用語の決定的な記述の第一のMPEG参照に相談するべきです。
2. Encapsulation of MPEG System and Transport Streams
2. MPEGシステムと輸送の流れのカプセル化
Each RTP packet will contain a timestamp derived from the sender's 90KHz clock reference. This clock is synchronized to the system stream Program Clock Reference (PCR) or System Clock Reference (SCR) and represents the target transmission time of the first byte of the packet payload. The RTP timestamp will not be passed to the MPEG decoder. This use of the timestamp is somewhat different than normally is the case in RTP, in that it is not considered to be the media display or presentation timestamp. The primary purposes of the RTP timestamp will be to estimate and reduce any network-induced jitter and to synchronize relative time drift between the transmitter and receiver.
それぞれのRTPパケットは送付者の90KHz時計参照から得られたタイムスタンプを含むでしょう。 この時計は、システムの流れのProgram Clock Reference(PCR)かSystem Clock Reference(SCR)と同期して、パケットペイロードの最初のバイトの目標トランスミッション時間を表します。 RTPタイムスタンプはMPEGデコーダに通過されないでしょう。 タイムスタンプのこの使用は通常RTPのケースであるよりいくらか異なっています、それがメディア表示かプレゼンテーションタイムスタンプであることは考えられないので。 RTPタイムスタンプの第一の目的は、どんなネットワークによって誘発されたジターも見積もって、減少させて、送信機と受信機の間で相対的な時間ドリフトを連動させることでしょう。
For MPEG2 Transport Streams the RTP payload will contain an integral number of MPEG transport packets. To avoid end system inefficiencies, data from multiple small MTS packets (normally fixed in size at 188 bytes) are aggregated into a single RTP packet. The number of transport packets contained is computed by dividing RTP payload length by the length of an MTS packet (188).
MPEG2 Transport Streamsに関しては、RTPペイロードは整数のMPEG輸送パケットを含むでしょう。 終わりのシステム非能率を避けるために、複数の小さいMTSパケット(通常、188バイトでサイズで修理されている)からのデータは単一のRTPパケットに集められます。 パケットが含んだ輸送の数は、MTSパケット(188)の長さにRTPペイロード長を割ることによって、計算されます。
For MPEG2 Program streams and MPEG1 system streams there are no packetization restrictions; these streams are treated as a packetized stream of bytes.
MPEG2 Programの流れとMPEG1システムストリームのために、packetization制限は全くありません。 これらの流れはバイトのpacketized流れとして扱われます。
Hoffman, et. al. Standards Track [Page 3] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[3ページ]。
2.1 RTP header usage
2.1 RTPヘッダー用法
The RTP header fields are used as follows:
RTPヘッダーフィールドは以下の通り使用されます:
Payload Type: Distinct payload types should be assigned for
of MPEG1 System Streams, MPEG2 Program Streams and MPEG2
Transport Streams. See [4] for payload type assignments.
有効搭載量タイプ: タイプがMPEG1 System Streams、MPEG2 Program Streams、およびMPEG2 Transport Streamsについて選任されるべきである異なったペイロード、ペイロードタイプ課題のための[4]を見てください。
M bit: Set to 1 whenever the timestamp is discontinuous
(such as might happen when a sender switches from one data
source to another). This allows the receiver and any
intervening RTP mixers or translators that are synchronizing
to the flow to ignore the difference between this timestamp
and any previous timestamp in their clock phase detectors.
Mは噛み付きました: タイムスタンプが不連続である(送付者が1個のデータ送信端末から別のものに切り替わると、起こるかもしれません)ときはいつも、1にセットしてください。 これで、流れに連動しているどんな受信機と介入しているRTPミキサーや翻訳者も彼らの時計位相検出器のこのタイムスタンプとどんな前のタイムスタンプの違いも無視できます。
timestamp: 32 bit 90K Hz timestamp representing the target
transmission time for the first byte of the packet.
タイムスタンプ: 32はパケットの最初のバイト単位で目標トランスミッション時間を表すタイムスタンプに90K Hz噛み付きました。
3. Encapsulation of MPEG Elementary Streams
3. MPEGの基本の流れのカプセル化
The following ES types may be encapsulated directly in RTP:
以下のESタイプは直接RTPで要約されるかもしれません:
(a) MPEG1 Video (ISO/IEC 11172-2)
(b) MPEG2 Video (ISO/IEC 13818-2)
(c) MPEG1 Audio (ISO/IEC 11172-3)
(d) MPEG2 Audio (ISO/IEC 13818-3)
(a) MPEG1ビデオ(ISO/IEC11172-2)(b)MPEG2ビデオ(ISO/IEC13818-2)(c)MPEG1オーディオ(ISO/IEC11172-3)(d)MPEG2オーディオ(ISO/IEC13818-3)
A distinct RTP payload type is assigned to MPEG1/MPEG2 Video and MPEG1/MPEG2 Audio, respectively. Further indication as to whether the data is MPEG1 or MPEG2 need not be provided in the RTP or MPEG- specific headers of this encapsulation, as this information is available in the ES headers.
異なったRTPペイロードタイプはそれぞれMPEG1/MPEG2 VideoとMPEG1/MPEG2 Audioに選任されます。 さらに、このカプセル化のRTPかMPEGの特定のヘッダーにデータがMPEG1であるかどうかに関する指示かMPEG2を提供する必要はありません、この情報がESヘッダーで利用可能であるときに。
Presentation Time Stamps (PTS) of 32 bits with an accuracy of 90 kHz shall be carried in the fixed RTP header. All packets that make up a audio or video frame shall have the same time stamp.
90kHzの精度に従った32ビットのプレゼンテーションTimeスタンプス(PTS)は固定RTPヘッダーで運ばれるものとします。 オーディオかビデオフレームを作るすべてのパケットが同じタイムスタンプを持っているものとします。
3.1 MPEG Video elementary streams
3.1 MPEGのVideoの基本の流れ
MPEG1 Video can be distinguished from MPEG2 Video at the video sequence header, i.e. for MPEG2 Video a sequence_header() is followed by sequence_extension(). The particular profile and level of MPEG2 Video (MAIN_Profile@MAIN_Level, HIGH_Profile@HIGH_Level, etc) are determined by the profile_and_level_indicator field of the sequence_extension header of MPEG2 Video.
ビデオ系列ヘッダーでMPEG2 VideoとMPEG1 Videoを区別できて、すなわち、MPEG2 Videoに関して、系列_拡大()は系列_ヘッダー()のあとに続いています。 MPEG2 Video( MAIN_Profile@MAIN_Level 、HIGH_Profile@HIGH_Levelなど)の特定のプロフィールとレベルはMPEG2 Videoの系列_拡張ヘッダーのプロフィール_と_レベル_インディケータ分野のそばで決定しています。
The MPEG bit-stream semantics were designed for relatively error-free environments, and there is significant amount of dependency (both
MPEGビットストリーム意味論が比較的エラーのない環境のために設計されて、かなりの量の依存がある、(両方
Hoffman, et. al. Standards Track [Page 4] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[4ページ]。
temporal and spatial) within the stream such that loss of some data make other uncorrupted data useless. The format as defined in this encapsulation uses application layer framing information plus additional information in the RTP stream-specific header to allow for certain recovery mechanisms. Appendix 1 suggests several recovery strategies based on the properties of this encapsulation.
時、空間的である、)、中、いくつかのデータの損失で他の腐敗していないデータが役に立たなくなるようなものを流してください。 このカプセル化で定義される書式は、ある回収機構を考慮するのにRTPの流れの特有のヘッダーで応用層縁どり情報と追加情報を使用します。付録1はこのカプセル化の特性に基づくいくつかの回復戦略を示します。
Since MPEG pictures can be large, they will normally be fragmented into packets of size less than a typical LAN/WAN MTU. The following fragmentation rules apply:
MPEGの絵が大きい場合があるので、通常、それらは1未満のサイズの典型的なLAN/WAN MTUのパケットに断片化されるでしょう。 以下の断片化規則は適用されます:
1. The MPEG Video_Sequence_Header, when present, will always
be at the beginning of an RTP payload.
2. An MPEG GOP_header, when present, will always be at the
beginning of the RTP payload, or will follow a
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.
1. RTPペイロードの始めに存在しているとき、いつもMPEG Video_Sequence_Headerはそうでしょう。 2. 存在しているとき、MPEG共和党_ヘッダーは、RTPペイロードの始めに、いつもあるか、またはVideo_Sequence_Headerの後をつけるでしょう。 3. 存在しているとき、MPEG Picture_HeaderはRTPペイロードの始めに、いつもあるか、または共和党_ヘッダーに続くでしょう。
Each ES header must be completely contained within the packet. Consequently, a minimum RTP payload size of 261 bytes must be supported to contain the largest single header defined in the ES (that is, the extension_data() header containing the quant_matrix_extension()). Otherwise, there are no restrictions on where headers may appear within packet payloads.
パケットの中にそれぞれのESヘッダーを完全に含まなければなりません。 その結果、ESで定義される中で最も大きい独身のヘッダーを含むように最低261バイトのRTPペイロードサイズを支持しなければなりません。(すなわち、舟棹_マトリクス_拡張子())を含む拡大_データ()ヘッダー。 さもなければ、ヘッダーがパケットペイロードの中に見えるかもしれないところに関する制限が全くありません。
In MPEG, each picture is made up of one or more "slices," and a slice is intended to be the unit of recovery from data loss or corruption. An MPEG-compliant decoder will normally advance to the beginning of next slice whenever an error is encountered in the stream. MPEG slice begin and end bits are provided in the encapsulation header to facilitate this.
MPEGでは、各絵は1「部分」で作られます、そして、部分はデータの損失か不正からの回復のユニットであることを意図します。 誤りが流れで遭遇するときはいつも、通常、MPEG対応することのデコーダは次の部分の始まりまで進むでしょう。 MPEG部分は始まります、そして、これを容易にするために終わりのビットをカプセル化ヘッダーに提供します。
The beginning of a slice must either be the first data in a packet (after any MPEG ES headers) or must follow after some integral number of slices in a packet. This requirement insures that the beginning of the next slice after one with a missing packet can be found without requiring that the receiver scan the packet contents. Slices may be fragmented across packets as long as all the above rules are met.
1つの部分の始まりにパケット(どんなMPEG ESヘッダーの後のも)における最初のデータでなければならないかパケットの何らかの整数の部分のあとについて行かなければなりません。 この要件は受信機がパケットコンテンツをスキャンする必要でないなくなったパケットがある1つを見つけられたことができた後に次の部分の始まりにそれを保障します。 すべての上の規則が満たされる限り、部分はパケットの向こう側に断片化されるかもしれません。
An implementation based on this encapsulation assumes that the Video_Sequence_Header is repeated periodically in the MPEG bit- stream. In practice (though not required by MPEG standard) this is used to allow channel switching and to receive and start decoding a continuously relayed MPEG bit-stream at arbitrary points in the media stream. It is suggested that when playing back from an MPEG stream from a file format (where the Video_Sequence_Header may only be
このカプセル化に基づく実現は、Video_Sequence_Headerが繰り返されたMPEGで定期的に噛み付いている流れであると仮定します。 習慣(MPEG規格は必要ではありませんが)では、これは、チャンネルの切り換えを許して、受信して、任意点でメディアの流れで絶え間なくリレーされたMPEGビットストリームを解読し始めるために使用されます。 MPEGの流れからaから再生するとき、それが形式をファイルすることが提案される、(Video_Sequence_Headerがあるだけであるかもしれません。
Hoffman, et. al. Standards Track [Page 5] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[5ページ]。
represented at the beginning of the stream) that the first Video_Sequence_Header (preceded by an end-of-stream indicator) be saved by the packetizer for periodic injection in to the network stream.
表される、流れの始まり) 最初の_Video_Sequence Header(流れのエンドインディケータは先行する)は周期的な注射のために中にpacketizerによってネットワークの流れへ取っておかれます。
3.2 MPEG Audio elementary streams
3.2 MPEGのAudioの基本の流れ
MPEG1 Audio can be distinguished from MPEG2 Audio from the MPEG ancillary_data() header. For either MPEG1 or MPEG2 Audio, distinct Presentation Time Stamps may be present for frames which correspond to either 384 samples for Layer-I, or 1152 samples for Layer-II or Layer-III. The actual number of bytes required to represent this number of samples will vary depending on the encoder parameters.
MPEG2 AudioとMPEGの付属の_データ()ヘッダーとMPEG1 Audioを区別できます。 MPEG1かMPEG2 Audioのどちらかに関しては、異なったPresentation TimeスタンプスはLayer-Iのための384個のサンプルかLayer-IIかLayer-IIIのための1152個のサンプルのどちらかに対応するフレームに出席しているかもしれません。 エンコーダパラメタによって、この数のサンプルを表すのに必要である実際のバイト数は異なるでしょう。
Multiple audio frames may be encapsulated within one RTP packet. In this case, an integral number of audio frames must be contained within the packet and the fragmentation header defined in Section 3.5 shall be set to 0.
複数のオーディオフレームが1つのRTPパケットの中で要約されるかもしれません。 この場合、パケットの中に整数のオーディオフレームを含まなければなりません、そして、セクション3.5で定義された断片化ヘッダーは0に用意ができているものとします。
Also, if relatively short packets are to be used, one frame may be so large that it may straddle multiple RTP packets. For example, for Layer-II MPEG audio sampled at a rate of 44.1 KHz each frame would represent a time slot of 26.1 msec. At this sampling rate if the compressed bit-rate is 384 kbits/sec (i.e. 48 kBytes/sec) then the average audio frame size would be 1.25 KBytes. If packets were to be 500 Bytes long, then each audio frame would straddle 3 RTP packets. The audio fragmentation indicator header (See Section 3.5) shall be present for an MPEG1/2 Audio payload type to provide for this fragmentation.
また、比較的脆いパケットが使用されているつもりであるなら、複数のRTPパケットにまたがることができるくらい1個のフレームも大きいかもしれません。 例えば、Layer-IIに関して、KHzがそれぞれ縁どる44.1の速度で抽出されたMPEGオーディオは26.1msecの時間帯を表すでしょう。 この標本抽出率では、平均したオーディオフレーム・サイズは圧縮されたビット伝送速度が384kbits/秒(すなわち、48kBytes/秒)であるなら1.25KBytesでしょう。 パケットによる長い間の500Bytesであるなら、それぞれのオーディオフレームは3つのRTPパケットにまたがっているでしょうに。 MPEG1/2 Audioペイロードタイプがこの断片化に備えるように、オーディオ断片化インディケータヘッダー(セクション3.5を見る)は出席するでしょう。
3.3 RTP Fixed Header for MPEG ES encapsulation
3.3 MPEG ESカプセル化のためのRTP Fixed Header
The RTP header fields are used as follows:
RTPヘッダーフィールドは以下の通り使用されます:
Payload Type: Distinct payload types should be assigned
for video elementary streams and audio elementary streams.
See [4] for payload type assignments.
有効搭載量タイプ: 異なったペイロードタイプはビデオの基本のストリームとオーディオの基本のストリームのために選任されるべきです。ペイロードタイプ課題のための[4]を見てください。
M bit: For video, set to 1 on packet containing MPEG frame
end code, 0 otherwise. For audio, set to 1 on first packet
of a "talk-spurt," 0 otherwise.
Mは噛み付きました: ビデオに関しては、そうでなければ、MPEGフレームエンド・コード、0を含んで、パケットの上に1にセットしてください。 そうでなければ、オーディオには、「話スパート」、0の最初のパケットの上に1にセットしてください。
PT: MPEG video or audio stream ID.
太平洋標準時: MPEGビデオかオーディオ流れのID。
timestamp: 32-bit 90K Hz timestamp representing presentation
time of MPEG picture or audio frame. Same for all packets
that make up a picture or audio frame. May not be
monotonically increasing in video stream if B pictures
タイムスタンプ: MPEGの絵かオーディオフレームのプレゼンテーション時間を表す90K Hzの32ビットのタイムスタンプ。 絵かオーディオフレームを作るすべてのパケットにおいて、同じです。 Bの絵であるならビデオストリームを単調に増やさないで、そうするかもしれません。
Hoffman, et. al. Standards Track [Page 6] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[6ページ]。
present in stream. For packets that contain only a video
sequence and/or GOP header, the timestamp is that of the
subsequent picture.
流れでは、存在しています。 ビデオ系列、そして/または、共和党ヘッダーだけを含むパケットに関しては、タイムスタンプはその後の絵のものです。
3.4 MPEG Video-specific header
3.4 MPEGのVideo特有のヘッダー
This header shall be attached to each RTP packet after the RTP fixed header.
RTPがヘッダーを修理した後にこのヘッダーはそれぞれのRTPパケットに取り付けられるものとします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | TR |MBZ|S|B|E| P | | BFC | | FFC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FBV FFV
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ| TR|MBZ|S|B|E| P| | BFC| | FFC| +++++++++++++++++++++++++++++++++FBV FFV
MBZ: Unused. Must be set to zero in current
specification. This space is reserved for future use.
MBZ: 未使用。 現在の仕様によるゼロに設定しなければなりません。 このスペースは今後の使用のために予約されます。
TR: Temporal-Reference (10 bits). The temporal reference of
the current picture within the current GOP. This value
ranges from 0-1023 and is constant for all RTP packets of a
given picture.
TR: 時の参照(10ビット)。 現在の共和党の中の現在の絵の時の参照。 この値は、0-1023から変化して、与えられた絵のすべてのRTPパケットに、一定です。
MBZ: Unused. Must be set to zero in current
specification. This space is reserved for future use.
MBZ: 未使用。 現在の仕様によるゼロに設定しなければなりません。 このスペースは今後の使用のために予約されます。
S: Sequence-header-present (1 bit). Normally 0 and set to 1 at
the occurrence of each MPEG sequence header. Used to
detect presence of sequence header in RTP packet.
S: 出席している系列ヘッダー(1ビット)。 それぞれのMPEG系列ヘッダーの発生の1への通常0とセット。 RTPパケットでの系列ヘッダーの存在を検出するのにおいて、使用されています。
B: Beginning-of-slice (BS) (1 bit). Set when the start of the
packet payload is a slice start code, or when a slice start
code is preceded only by one or more of a
Video_Sequence_Header, GOP_header and/or Picture_Header.
B: 部分の始まりの(BS。)(1ビット) パケットペイロードの始まりが部分スタートコードである、または部分スタートコードが単に_共和党のVideo_Sequence_Header、ヘッダー、そして/または、Picture_Headerの1つ以上によって先行されたら、セットしてください。
E: End-of-slice (ES) (1 bit). Set when the last byte of the
payload is the end of an MPEG slice.
E: 部分の端の(ES。)(1ビット) ペイロードの最後のバイトが1つのMPEG部分の端であるときには、セットしてください。
P: Picture-Type (3 bits). I (1), P (2), B (3) or D (4). This
value is constant for each RTP packet of a given picture.
Value 000B is forbidden and 101B - 111B are reserved to
support future extensions to the MPEG ES specification.
P: (3ビット)を絵でタイプしてください。 I(1)、P(2)、B(3)またはD(4)。 与えられた絵のそれぞれのRTPパケットに、この値は一定です。 000Bが禁じられる値と101B--111Bは、MPEG ES仕様に今後の拡大を支持するために予約されます。
FBV: full_pel_backward_vector
BFC: backward_f_code
FFV: full_pel_forward_vector
FFC: forward_f_code
FBV: 完全な_ペル_後方の_ベクトルBFC: 後方の_f_コードFFV: 完全な_ペル_前進の_ベクトルFFC: 前進の_f_コード
Hoffman, et. al. Standards Track [Page 7] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[7ページ]。
Obtained from the most recent picture header, and are
constant for each RTP packet of a given picture. None of
these values are used for I frames and must be set to zero
in the RTP header. For P frames only the last two values
are present and FBV and BFC must be set to zero in the RTP
header. For B frames all the four values are present.
得て、与えられた絵のそれぞれのRTPパケットのための定数は、最新であるのから、ヘッダーについて描写して、来ています。 これらの値のいずれも、Iフレームに使用して、RTPヘッダーにゼロに設定してはいけません。 Pフレームだけに関しては、最後の2つの値が存在しています、そして、FBVとBFCはRTPヘッダーでゼロに用意ができなければなりません。 Bフレームに関しては、すべての4つの値が存在しています。
3.5 MPEG Audio-specific header
3.5 MPEGのAudio特有のヘッダー
This header shall be attached to each RTP packet at the start of the payload and after any RTP headers for an MPEG1/2 Audio payload type.
このヘッダーはMPEG1/2 Audioペイロードタイプのためにペイロードの始めにおけるどんなRTPヘッダーの後のそれぞれのRTPパケットにも取り付けられるものとします。
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ | Frag_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ| _オフセットを破片手榴弾で殺傷してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frag_offset: Byte offset into the audio frame for the data
in this packet.
_オフセットを破片手榴弾で殺傷してください: バイトはこのパケットのデータのためのオーディオフレームに相殺されました。
Hoffman, et. al. Standards Track [Page 8] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[8ページ]。
Appendix 1. Error Recovery and Resynchronization Strategies.
付録1。 エラー回復とResynchronization戦略。
The following error recovery and resynchronization strategies are intended to be guidelines only. A compliant receiver is free to employ alternative (or no) strategies.
以下のエラー回復と再同期戦略はガイドライン専用であることを意図します。 言いなりになっている受信機は無料で代替(または、いいえ)の戦略を使うことができます。
When initially decoding an RTP-encapsulated MPEG Elementary Stream, the receiver may discard all packets until the Sequence-header- present bit is set to 1. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder.
初めはRTPによって要約されたMPEG Elementary Streamを解読するとき、Sequence-ヘッダー現在のビットが1に設定されるまで、受信機はすべてのパケットを捨てるかもしれません。 ここに、十分な州の情報は、MPEGデコーダで処理するのを許容するために流れに含まれています。
Loss of packets containing the GOP_header and/or Picture_Header are detected by an unexpected change in the Temporal-Reference and Picture-Type values. Consider the following example GOP sequence:
共和党_ヘッダー、そして/または、Picture_Headerを含むパケットの損失はTemporal-参照とPicture-タイプ値における意外な変化によって検出されます。 以下の例が共和党系列であると考えてください:
In display order: 0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ...
In stream order: 2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...
表示では、注文してください: 0B 1B 2I 3B 4B 5P 6B 7B 8P共和党_HDR 0B… 流れでは、注文してください: 2I 0B 1B 5P 3B 4B 8P 6B 7B共和党_HDR 2I…
Consider also two counters:
また、2台のカウンタを考えてください:
ref_pic_temp (Reference Picture (I,P) Temporal Reference)
dep_pic_temp (Dependent Picture (B) Temporal Reference)
審判_映画_臨時(参照Picture(I、P)の時のReference)dep_映画_臨時(依存する絵の(B)時の参照)
At each GOP beginning, set these counters to the temporal reference value of the corresponding picture type. For our example GOP sequence, ref_pic_temp = 2 and dep_pic_temp = 0. Keep incrementing BOTH counters by unity with each following picture. Ref_pic_temp should match the temporal references of the I and P frames, and dep_pic_temp should match the temporal references of the B frames.
それぞれの共和党始めに、対応する絵のタイプの時の基準値にこれらのカウンタを設定してください。 私たちの例の共和党系列のために、審判_映画_臨時は2とdep_映画_臨時=0と等しいです。 それぞれの次の絵で統一でBOTHカウンタを増加し続けてください。 審判_映画_臨時はIとPフレームの時の参照に合うべきです、そして、dep_映画_臨時はBフレームの時の参照に合うべきです。
dep_pic_temp: - 0 1 2 3 4 5 6 7 8 9
In stream order: 2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
ref_pic_temp: 2 3 4 5 6 7 8 9 10 ^ 11
-------------------------- | ^
Match Drop |
Mismatch
in ref_pic_temp
dep_映画_臨時: - 流れにおける0 1 2 3 4 5 6 7 8 9は注文されます: 2I 0B 1B 5P 3B 4B 8P 6B 7B共和党_H2I 0B 1B…審判_映画_は派遣社員として働きます: 2 3 4 5 6 7 8 9 10 ^ 11 -------------------------- | ^マッチ低下| 審判_映画_臨時でのミスマッチ
The loss of a GOP header can be detected by matching the appropriate counter (based on picture type) to the temporal reference value. A mismatch indicates a lost GOP header. If desired, a GOP header can be re-constructed using a "null" time_code, repeating the closed_gop flag from previous GOP headers, and setting the broken_link flag to 1.
適切なカウンタ(絵のタイプに基づいている)を時の基準値に合わせることによって、共和党ヘッダーの損失を検出できます。 ミスマッチは迷子になった共和党ヘッダーを示します。 望まれているなら、「ヌル」の時間_コードを使用することで共和党ヘッダーを再建できます、前の共和党ヘッダーから閉じている_gop旗を繰り返して、壊れている_リンク旗を1に設定して。
The loss of a Picture_Header can also be detected by a mismatch in the Temporal Reference contained in the RTP packet from the appropriate dep_pic_temp or ref_pic_temp counters at the receiver.
また、RTPパケットに含まれたTemporal Referenceでのミスマッチは受信機の適切なdep_映画_臨時か審判_映画_臨時カウンタからPicture_Headerの損失を検出できます。
Hoffman, et. al. Standards Track [Page 9] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[9ページ]。
After scanning to the next Beginning-of-slice the Picture_Header is reconstructed from the P, TR, FBV, BFC, FFV and FFC contained in that packet, and from stream-dependent default values.
部分の次のBeginningにスキャンした後に、Picture_Headerはそのパケットに含まれたPと、TRと、FBVと、BFCと、FFVとFFCと、流れの依存するデフォルト値から再建されます。
Any time an RTP packet is lost (as indicated by a gap in the RTP sequence number), the receiver may discard all packets until the Beginning-of-slice bit is set. At this point, sufficient state information is contained in the stream to allow processing by an MPEG decoder starting at the next slice boundary (possibly after reconstruction of the GOP_header and/or Picture_Header as described above).
いつでも、RTPパケットが無くなる(RTP一連番号におけるギャップによって示されるように)、部分のBeginningビットが設定されるまで、受信機はすべてのパケットを捨てるかもしれません。 ここに、十分な州の情報は、次の部分境界(ことによると上で説明されるとしての共和党_ヘッダー、そして/または、Picture_Headerの再建の後の)で始動するMPEGデコーダで処理するのを許容するために流れに含まれています。
References
参照
[1] ISO/IEC International Standard 11172; "Coding of moving pictures
and associated audio for digital storage media up to about 1,5
Mbits/s", November 1993.
[1] ISO/IEC国際規格11172。 1993年11月の「デジタル蓄積メディア最大およそ1、5メガビット/sのための映画と関連オーディオのコード化」。
[2] ISO/IEC International Standard 13818; "Generic coding of moving
pictures and associated audio information", November 1994.
[2] ISO/IEC国際規格13818。 1994年11月の「映画と関連オーディオ情報の一般的なコード化」。
[3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
[3] H.Schulzrinne、S.Casner、ジェーコブソンに対するR.フレディリック、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[4]H.Schulzrinne、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
Hoffman, et. al. Standards Track [Page 10] RFC 2038 RTP Payload Format for MPEG1/MPEG2 Video October 1996
etホフマン、アル。 規格はビデオ1996年10月にMPEG1/MPEG2のためにRFC2038RTP有効搭載量形式を追跡します[10ページ]。
Authors' Addresses
作者のアドレス
Gerard Fernando Sun Microsystems, Inc. Mail-stop UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA
ジェラードフェルナンドサン・マイクロシステムズ・インクメール停止UMPK14-305 2550ガルシア・Avenueカリフォルニア94043-1100マウンテンビュー(米国)
Phone: +1 415-786-6373 EMail: gerard.fernando@eng.sun.com
以下に電話をしてください。 +1 415-786-6373 メールしてください: gerard.fernando@eng.sun.com
Vivek Goyal Precept Software, Inc. 1072 Arastradero Rd, Palo Alto, CA 94304 USA
Vivek Goyal教訓ソフトウェアInc.1072Arastradero、パロアルト、カリフォルニア94304第米国
Phone: +1 415-845-5200 EMail: goyal@precept.com
以下に電話をしてください。 +1 415-845-5200 メールしてください: goyal@precept.com
Don Hoffman Sun Microsystems, Inc. Mail-stop UMPK14-305 2550 Garcia Avenue Mountain View, California 94043-1100 USA
ドンホフマンサン・マイクロシステムズ・インクメール停止UMPK14-305 2550ガルシア・Avenueマウンテンビュー、カリフォルニア94043-1100米国
Phone: +1 503-297-1580 EMail: don.hoffman@eng.sun.com
以下に電話をしてください。 +1 503-297-1580 メールしてください: don.hoffman@eng.sun.com
Hoffman, et. al. Standards Track [Page 11]
etホフマン、アル。 標準化過程[11ページ]
一覧
スポンサーリンク
