RFC2250 日本語訳
2250 RTP Payload Format for MPEG1/MPEG2 Video. D. Hoffman, G.Fernando, V. Goyal, M. Civanlar. January 1998. (Format: TXT=34293 bytes) (Obsoletes RFC2038) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Hoffman
Request for Comments: 2250 G. Fernando
Obsoletes: 2038 Sun Microsystems, Inc.
Category: Standards Track V. Goyal
Precept Software, Inc.
M. Civanlar
AT&T Labs - Research
January 1998
コメントを求めるワーキンググループD.ホフマン要求をネットワークでつないでください: 2250 G.フェルナンドは以下を時代遅れにします。 2038年のサン・マイクロシステムズ・インクカテゴリ: 標準化過程V.Goyal教訓ソフトウェアInc.M.Civanlar AT&T研究室--研究1998年1月
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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によって要約されたメディアの流れと今後の会議コントロール仕事を最大の互換性に提供するように設計されています。
This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms in Section 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added.
このメモはRFC2038の改正、インターネット標準化過程プロトコルです。 この改正では、セクション3.4のパケット損失弾力メカニズムは、MPEG2に必要である追加の絵ヘッダー情報を含むように広げられました。 このペイロードタイプのためのセキュリティ問題の新しいセクションは加えられます。
Hoffman, et. al. Standards Track [Page 1] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[1ページ]。
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のものを圧縮しました。
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ベースのケーブル配電設備へのインターネットを利用するビデオ・サーバ。
Hoffman, et. al. Standards Track [Page 2] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[2ページ]。
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つのペイロード書式を定義するよう提案します。
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
それぞれのRTPパケットは送付者の90KHz時計参照から得られたタイムスタンプを含むでしょう。 この時計は、システムの流れのProgram Clock Reference(PCR)かSystem Clock Reference(SCR)と同期して、最初のバイトの目標トランスミッション時間を表します。
Hoffman, et. al. Standards Track [Page 3] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[3ページ]。
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タイムスタンプは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流れとして扱われます。
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
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)
Hoffman, et. al. Standards Track [Page 4] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[4ページ]。
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 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.
MPEGビットストリーム意味論は比較的エラーのない環境のために設計されました、そして、そこでは、流れの中のかなりの量の依存(時のものと同様に空間的な)がそのようなものであるので、いくつかのデータの損失で他の腐敗していないデータが役に立たなくなります。 このカプセル化で定義される書式は、ある回収機構を考慮するのに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ペイロードサイズを支持しなければなりません。(すなわち、舟棹_マトリクス_拡張子())を含む拡大_データ()ヘッダー。 さもなければ、ヘッダーがパケットペイロードの中に見えるかもしれないところに関する制限が全くありません。
Hoffman, et. al. Standards Track [Page 5] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[5ページ]。
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 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が繰り返されたMPEGで定期的に噛み付いている流れであると仮定します。 習慣(MPEG規格は必要ではありませんが)では、これは、チャンネルの切り換えを許して、受信して、任意点でメディアの流れで絶え間なくリレーされたMPEGビットストリームを解読し始めるために使用されます。 MPEGの流れからaから再生するとき、それがネットワークの流れへの中の周期的な注射のためにより多くのpacketizerに救われた状態で最初の_Video_Sequence Header(流れのエンドインディケータは先行する)がある形式(Video_Sequence_Headerが流れの始めに表されるだけであるかもしれないところ)をファイルすることが提案されます。
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.
また、比較的脆いパケットが使用されているつもりであるなら、複数のRTPパケットにまたがることができるくらい1個のフレームも大きいかもしれません。 例えば、Layer-IIに関して、KHzがそれぞれ縁どる44.1の速度で抽出されたMPEGオーディオは26.1msecの時間帯を表すでしょう。 この標本抽出率では、平均したオーディオフレーム・サイズは圧縮されたビット伝送速度が384kbits/秒(すなわち、48kBytes/秒)であるなら1.25KBytesでしょう。 パケットによる長い間の500Bytesであるなら、それぞれのオーディオフレームは3つのRTPパケットにまたがっているでしょうに。
Hoffman, et. al. Standards Track [Page 6] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[6ページ]。
The audio fragmentation indicator header (See Section 3.5) shall be present for an MPEG1/2 Audio payload type to provide for this fragmentation.
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 present
in stream. For packets that contain only a video sequence
and/or GOP header, the timestamp is that of the subsequent
picture.
タイムスタンプ: MPEGの絵かオーディオフレームのプレゼンテーション時間を表す90K Hzの32ビットのタイムスタンプ。 絵かオーディオフレームを作るすべてのパケットにおいて、同じです。 Bが流れでプレゼントについて描写するなら、ビデオストリームを単調に増やしていないかもしれません。 ビデオ系列、そして/または、共和党ヘッダーだけを含むパケットに関しては、タイムスタンプはその後の絵のものです。
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 |T| TR | |N|S|B|E| P | | BFC | | FFC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AN 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|T| TR| |N|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: 未使用。 現在の仕様によるゼロに設定しなければなりません。 このスペースは今後の使用のために予約されます。
T: MPEG-2 (Two) specific header extension present (1 bit).
Set to 1 when the MPEG-2 video-specific header extension (see
Section 3.4.1) follows this header. This extension may be
needed for improved error resilience; however, its inclusion
in an RTP packet is optional. (See Appendix 1.)
T: 現在のMPEG-2(2)特定のヘッダー拡大(1ビット)。 MPEG-2のビデオ特有のヘッダー拡大(セクション3.4.1を見る)がこのヘッダーに続いたら、1にセットしてください。 この拡大が改良された誤り弾力に必要であるかもしれません。 しかしながら、RTPパケットでの包含は任意です。 (付録1を見てください。)
Hoffman, et. al. Standards Track [Page 7] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[7ページ]。
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パケットに、一定です。
AN: Active N bit for error resilience (1 bit). Set to 1 when
the following bit (N) is used to signal changes in the
picture header information for MPEG-2 payloads. It must be
set to 0 for MPEG-1 payloads or when N bit is not used.
: アクティブなNに誤り弾力(1ビット)のために噛み付きました。 以下のビット(N)がMPEG-2個のペイロードのための絵のヘッダー情報における変化に合図するのに使用されたら1にセットしてください。 MPEG-1ペイロードかそれともNビットがいつ使用されていないか間、0にそれを設定しなければなりません。
N: New picture header (1 bit). Used for MPEG-2 payloads when
the previous bit (AN) is set to 1. Otherwise, it must be set
to zero. Set to 1 when the information contained in the
previously transmitted Picture Headers can't be used to
reconstruct a header for the current picture. This happens
when the current picture is encoded using a different set of
parameters than the previous pictures of the same type. The N
bit must be constant for all RTP packets that belong to the
same picture so that receipt of any packet from a picture
allows detecting whether information necessary for
reconstruction was contained in that picture (N = 1) or a
previous one (N = 0).
N: 新しい絵のヘッダー(1ビット)。 前のビット(AN)が1に設定されるときのMPEG-2ペイロードにおいて、使用されています。 さもなければ、ゼロにそれを設定しなければなりません。 現在の絵のためにヘッダーを再建するのに以前に伝えられたPicture Headersに含まれた情報を使用できないとき、1にセットしてください。 現在の絵が同じタイプの前の絵より異なったセットのパラメタを使用することでコード化されるとき、これは起こります。 同じ絵に属すすべてのRTPパケットに、Nビットが一定であるに違いないので、絵からのどんなパケットの領収書も、再建に必要な情報がその絵(N=1)か前の1つ(N=0)に含まれたかどうか検出するのを許容します。
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
Obtained from the most recent picture header, and are
constant for each RTP packet of a given picture. For I frames
none of these values are present in the picture header and
FBV: 完全な_ペル_後方の_ベクトルBFC: 後方の_f_コードFFV: 完全な_ペル_前進の_ベクトルFFC: フォワード_f_は最新の絵のヘッダーからObtainedをコード化して、与えられた絵のそれぞれのRTPパケットに、一定です。 そしてこれらのいずれも評価しないIフレームが絵のヘッダーに存在している。
Hoffman, et. al. Standards Track [Page 8] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[8ページ]。
they 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ヘッダーにゼロにそれらを設定しなければなりません。 Pフレームだけに関しては、最後の2つの値が存在しています、そして、FBVとBFCはRTPヘッダーでゼロに用意ができなければなりません。 Bフレームに関しては、すべての4つの値が存在しています。
3.4.1 MPEG-2 Video-specific header extension
3.4.1 MPEG-2のVideo特有のヘッダー拡大
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|E|f_[0,0]|f_[0,1]|f_[1,0]|f_[1,1]| DC| PS|T|P|C|Q|V|A|R|H|G|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|E|f_[0、0]|f_[0、1]|f_[1、0]|f_[1、1]| DC| PS|T|P|C|Q|V|A|R|H|G|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X: Unused (1 bit). Must be set to zero in current
specification. This space is reserved for future use.
X: 未使用です(1ビット)。 現在の仕様によるゼロに設定しなければなりません。 このスペースは今後の使用のために予約されます。
E: Extensions present (1 bit). If set to 1, this header
extension, including the composite display extension when D =
1, will be followed by one or more of the following
extensions: quant matrix extension, picture display
extension, picture temporal scalable extension, picture
spatial scalable extension and copyright extension.
E: 拡大は(1ビット)を提示します。 1に設定されると、以下の拡大の1つ以上はD=1であることの合成表示拡大を含むこのヘッダー拡大のあとに続くでしょう: 舟棹マトリクス拡大、絵の表示拡大が時のスケーラブルな拡大について描写して、絵は、空間的なスケーラブルな拡大と著作権拡大です。
The first byte of these extensions data gives the length of
the extensions in 32 bit words including the length field
itself. Zero padding bytes are used at the end if required to
align the extensions to 32 bit boundary.
これらの拡大データの最初のバイトは長さの分野自体を含む単語を32ビットの拡大の長さに与えます。 詰め物バイトは、全く終わりに必要なら、32ビット境界に拡大を並べるのに使用されません。
Since they may not be vital in decoding of a picture, the
inclusion of any one of these extensions in an RTP packet is
optional even when the MPEG-2 video-specific header extension
is included in the packet (T = 1). (See Appendix 1.) If
present, they should be copied from the corresponding
extensions following the most recent MPEG-2 picture coding
extension and they remain constant for each RTP packet of a
given picture.
それらが絵を解読するのにおいて重大でないかもしれないので、MPEG-2のビデオ特有のヘッダー拡大がパケット(T=1)に含まれるときさえ、RTPパケットでのこれらの拡大のどれかの包含は任意です。 (付録1を見てください。) 存在しているなら、最新のMPEG-2画像符号化拡大に続いて、それらは対応する拡大からコピーされるべきです、そして、与えられた絵のそれぞれのRTPパケットに一定のままで、残っています。
The extension start code (32 bits) and the extension start
code ID (4 bits) are included. Therefore the extensions are
self identifying.
拡大スタートコード(32ビット)と拡大スタートコードID(4ビット)は含まれています。 したがって、拡大は自己特定です。
f_[0,0]: forward horizontal f_code (4 bits)
f_[0,1]: forward vertical f_code (4 bits)
f_[1,0]: backward horizontal f_code (4 bits)
f_[1,1]: backward vertical f_code (4 bits)
DC: intra_DC_precision (2 bits)
PS: picture_structure (2 bits)
f_[0、0]: 水平なf_コード(4ビット)f_[0、1]を進めてください: 垂直なf_コード(4ビット)f_[1、0]を進めてください: 後方の水平なf_コード(4ビット)f_[1、1]: 後方の垂直なf_コード(4ビット)DC: イントラ_DC_精度(2ビット)PS: 絵_構造(2ビット)
Hoffman, et. al. Standards Track [Page 9] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[9ページ]。
T: top_field_first (1 bit)
P: frame_predicted_frame_dct (1 bit)
C: concealment_motion_vectors (1 bit)
Q: q_scale type (1 bit)
V: intra_vlc_format (1 bit)
A: alternate scan (1 bit)
R: repeat_first_field (1 bit)
H: chroma_420_type (1 bit)
G: progressive frame (1 bit)
D: composite_display_flag (1 bit). If set to 1, next 32 bits
following this one contains 12 zeros followed by 20 bits
of composite display information.
T: 最高_分野_最初の(1ビット)P: フレーム_は_フレーム_dct(1ビット)Cを予測しました: 隠すこと_動き_ベクトル(1ビット)Q: q_スケールタイプ(1ビット)V: イントラ_vlc_形式(1ビット)A: スキャン(1ビット)Rを交替してください: __最初に、分野(1ビット)Hを繰り返してください: 彩度_420_タイプ(1ビット)G: 進歩的なフレーム(1ビット)D: _表示_旗(1ビット)を合成してください。 設定されるなら、1、これに続くと含む次の32ビットに12のゼロが20ビットの合成表示情報で続きました。
These values are copied from the most recent picture coding
extension and are constant for each RTP packet of a given
picture. Their meanings are as explained in the MPEG-2 standard.
これらの値は、最新の画像符号化拡大からコピーされて、与えられた絵のそれぞれのRTPパケットに、一定です。 それらの意味がMPEG-2規格で説明されるようにあります。
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.
_オフセットを破片手榴弾で殺傷してください: バイトはこのパケットのデータのためのオーディオフレームに相殺されました。
4. Security Considerations
4. セキュリティ問題
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [3], and any appropriate RTP profile (for example [4]). 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仕様[3]、およびどんな適切なRTPプロフィールでも議論したセキュリティ問題を条件としています。(例えば、[4])。 これは、メディアの流れの秘密性が暗号化で達成されるのを含意します。 このペイロード形式と共に使用されるデータ圧縮が適用された終わりから終わりであるので、暗号化が圧縮の後に実行されるかもしれないので、2つの操作の間には、闘争が全くありません。
A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity.
潜在的サービスの否定の脅威は、データencodingsのために不均等な受信端末コンピュータの負荷を持っている圧縮のテクニックを使用することで存在しています。 攻撃者は、流れの中への解読するために複雑な病理学的なデータグラムを注入して、受信機を積みすぎさせることができます。 しかしながら、このコード化は少しの重要な非の一様性も示しません。
Hoffman, et. al. Standards Track [Page 10] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[10ページ]。
As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [5] and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it.
どんなIPベースのプロトコル、いくつかの事情ではも、受信機は単に必要であるか望まれないあまりに多くのパケットの領収書で積みすぎられるかもしれません。 ネットワーク層認証は望まれないソースからパケットを捨てるのに使用されるかもしれませんが、認証自体の加工費は高過ぎるかもしれません。 マルチキャスト環境で、特定のソースを取り除くのは、受信機が、どのソースがそれに達することができるかを選択するのを許容するためにIGMP[5]の将来のバージョンとマルチキャストルーティング・プロトコルで実行されるかもしれません。
A security review of this payload format found no additional considerations beyond those in the RTP specification.
このペイロード形式の安全レビューはRTP仕様によるそれらを超えてどんな追加問題も見つけませんでした。
Hoffman, et. al. Standards Track [Page 11] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[11ページ]。
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 12] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[12ページ]。
For MPEG-1 payloads, 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から再建された後にMPEG-1ペイロードのために、TR、FBV、BFC、FFV、およびFFCはそのパケットと、流れの依存するデフォルトから値を含みました。
For MPEG-2, additional information is needed for the reconstruction. This information is provided by the MPEG-2 video specific header extension contained in that packet if the T bit is set to 1, or the Picture Header for the current picture may be available from previous packets belonging to the same picture. The transmitter's strategy for inclusion of the MPEG-2 video specific header extension may depend upon a number of factors. This header may not be needed when:
MPEG-2において、追加情報が再建に必要です。 Tビットが1に設定されるか、または現在の絵のためのPicture Headerが同じ絵に属す前のパケットから利用可能であるかもしれないならそのパケットに含まれたMPEG-2のビデオの特定のヘッダー拡大でこの情報を提供します。 MPEG-2のビデオの特定のヘッダー拡大の包含のための送信機の戦略は多くの要因に依存するかもしれません。 このヘッダーは必要でないかもしれない、いつ:
1. the information has been transmitted a sufficient number of
times in previous packets to assure reception with the desired
probability, or
または1. 情報が必要な確率があるレセプションを保証できるくらいの前のパケットの回の伝えられたa番号である。
2. the information is transmitted over a separate reliable
channel, or
または2. 情報が別々の高信頼のチャンネルの上に伝えられる。
3. expected loss rates are low enough that missed frames are not a
concern, or
または3. 期待損失率が逃されたフレームが関心でない低い。
4. conserving bandwidth is more important than error resilience,
etc.
4. 帯域幅を保存するのは誤り弾力などより重要です。
If T=1 and E=0, there may be extensions present in the original video bitstream that are not included in the current packet. The transmitter may choose not to include extensions in a packet when they are not necessary for decoding or if one of the cases listed above for not including the MPEG-2 video specific header extension in a packet applies only to the extension data.
T=1とE=0であるなら、オリジナルのビデオbitstreamでの現在のパケットに含まれていない拡大プレゼントがあるかもしれません。 送信機が、それらは解読するのに必要でないときに、パケットに拡大を含んでいないのを選ぶかもしれませんか、またはケースの1つが包含でないために上に記載したなら、パケットでのMPEG-2のビデオの特定のヘッダー拡大が拡大データだけに適用されます。
If N=0, then the Picture Header from a previous picture of the same type (I,P or B) may be used so long as 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. This may involve:
同じタイプ(私、PまたはB)の前の絵からのPicture HeaderがN=0であるならそれほど長い間使用されるかもしれないので、同じタイプとそのあらゆる介入している絵のために少なくとも1つのパケットを受け取ったように、Nビットはそれぞれのそれらの絵のための0でした。 これは以下にかかわるかもしれません。
1. Saving the relevant picture header information that can be
obtained from the MPEG-2 video specific header extension or
directly from the video bitstream for each picture type,
1. MPEG-2のビデオの特定のヘッダー拡大かそれぞれの絵のタイプのための直接ビデオbitstreamから関連絵のヘッダー情報にそれを救うのを得ることができます。
2. Keeping validity indicators for this saved information based on
the received N bits and lost packets, and,
2. 情報が保存されたこれのために正当性がインディケータであることを保つのが、ビットを容認されたNに基礎づけて、そして、パケットを失いました。
3. Updating the data whenever a packet with N=1 is received.
3. N=1があるパケットが受け取られているときはいつも、データをアップデートします。
Hoffman, et. al. Standards Track [Page 13] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[13ページ]。
If the necessary information is not available from any of these sources, data deletion until a new picture start code is advised.
必要事項がこれらのソースのいずれからも利用可能でないなら、新しい絵のスタートコードまでのデータ削除は教えられます。
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] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[3]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[4] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[4]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
[5] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, August 1989.
[5] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
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
Hoffman, et. al. Standards Track [Page 14] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[14ページ]。
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
M. Reha Civanlar AT&T Labs - Research 100 Schutlz Drive, 3-213 Red Bank, NJ 07701-7033 USA
M.Reha Civanlar AT&T研究室--研究100Schutlzドライブ、3-213の赤い銀行、ニュージャージー07701-7033米国
Phone: +1 732-345-3305 EMail: civanlar@research.att.com
以下に電話をしてください。 +1 732-345-3305 メールしてください: civanlar@research.att.com
Hoffman, et. al. Standards Track [Page 15] RFC 2250 RTP Format for MPEG1/MPEG2 Video January 1998
etホフマン、アル。 規格はビデオ1998年1月にMPEG1/MPEG2のためにRFC2250RTP形式を追跡します[15ページ]。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Hoffman, et. al. Standards Track [Page 16]
etホフマン、アル。 標準化過程[16ページ]
一覧
スポンサーリンク
