RFC3984 日本語訳
3984 RTP Payload Format for H.264 Video. S. Wenger, M.M. Hannuksela,T. Stockhammer, M. Westerlund, D. Singer. February 2005. (Format: TXT=205093 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Wenger
Request for Comments: 3984 M.M. Hannuksela
Category: Standards Track T. Stockhammer
M. Westerlund
D. Singer
February 2005
コメントを求めるワーキンググループS.ウェンガー要求をネットワークでつないでください: 3984年のM.M.Hannukselaカテゴリ: 標準化過程T.Stockhammer M.Westerlund D.歌手2005年2月
RTP Payload Format for H.264 Video
H.264ビデオのためのRTP有効搭載量形式
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit- rate video-on-demand.
このメモはITU-T Recommendation H.264ビデオコーデックと技術的に同じISO/IEC国際規格14496-10ビデオコーデックのためにRTP有効搭載量形式について説明します。RTPペイロード形式はそれぞれのRTPペイロードでH.264ビデオエンコーダによって生産された1Network Abstraction Layer Units(NALUs)のpacketizationを考慮します。 ペイロード形式には、広い適用性があります、簡単な低いビット伝送速度会話の用法からのアプリケーションをサポートするとき、はさみ込まれたトランスミッションがあるインターネットビデオ・ストリーミングに、高いビットレートビデオ・オン・デマンドに。
Table of Contents
目次
1. Introduction.................................................. 3
1.1. The H.264 Codec......................................... 3
1.2. Parameter Set Concept................................... 4
1.3. Network Abstraction Layer Unit Types.................... 5
2. Conventions................................................... 6
3. Scope......................................................... 6
4. Definitions and Abbreviations................................. 6
4.1. Definitions............................................. 6
5. RTP Payload Format............................................ 8
5.1. RTP Header Usage........................................ 8
5.2. Common Structure of the RTP Payload Format.............. 11
5.3. NAL Unit Octet Usage.................................... 12
1. 序論… 3 1.1. H.264コーデック… 3 1.2. パラメタは概念を設定しました… 4 1.3. 抽象化層のユニット型をネットワークでつないでください… 5 2. コンベンション… 6 3. 範囲… 6 4. 定義と略語… 6 4.1. 定義… 6 5. RTP有効搭載量形式… 8 5.1. RTPヘッダー用法… 8 5.2. RTP有効搭載量形式の一般的な構造… 11 5.3. NALユニット八重奏用法… 12
Wenger, et al. Standards Track [Page 1] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[1ページ]。
5.4. Packetization Modes..................................... 14
5.5. Decoding Order Number (DON)............................. 15
5.6. Single NAL Unit Packet.................................. 18
5.7. Aggregation Packets..................................... 18
5.8. Fragmentation Units (FUs)............................... 27
6. Packetization Rules........................................... 31
6.1. Common Packetization Rules.............................. 31
6.2. Single NAL Unit Mode.................................... 32
6.3. Non-Interleaved Mode.................................... 32
6.4. Interleaved Mode........................................ 33
7. De-Packetization Process (Informative)........................ 33
7.1. Single NAL Unit and Non-Interleaved Mode................ 33
7.2. Interleaved Mode........................................ 34
7.3. Additional De-Packetization Guidelines.................. 36
8. Payload Format Parameters..................................... 37
8.1. MIME Registration....................................... 37
8.2. SDP Parameters.......................................... 52
8.3. Examples................................................ 58
8.4. Parameter Set Considerations............................ 60
9. Security Considerations....................................... 62
10. Congestion Control............................................ 63
11. IANA Considerations........................................... 64
12. Informative Appendix: Application Examples.................... 65
12.1. Video Telephony according to ITU-T Recommendation H.241
Annex A................................................. 65
12.2. Video Telephony, No Slice Data Partitioning, No NAL
Unit Aggregation........................................ 65
12.3. Video Telephony, Interleaved Packetization Using NAL
Unit Aggregation........................................ 66
12.4. Video Telephony with Data Partitioning.................. 66
12.5. Video Telephony or Streaming with FUs and Forward
Error Correction........................................ 67
12.6. Low Bit-Rate Streaming.................................. 69
12.7. Robust Packet Scheduling in Video Streaming............. 70
13. Informative Appendix: Rationale for Decoding Order Number..... 71
13.1. Introduction............................................ 71
13.2. Example of Multi-Picture Slice Interleaving............. 71
13.3. Example of Robust Packet Scheduling..................... 73
13.4. Robust Transmission Scheduling of Redundant Coded
Slices.................................................. 77
13.5. Remarks on Other Design Possibilities................... 77
14. Acknowledgements.............................................. 78
15. References.................................................... 78
15.1. Normative References.................................... 78
15.2. Informative References.................................. 79
Authors' Addresses................................................ 81
Full Copyright Statement.......................................... 83
5.4. Packetizationモード… 14 5.5. 注文番号(氏)を解読します… 15 5.6. 単一のNALユニットパケット… 18 5.7. 集合パケット… 18 5.8. 断片化ユニット(FUs)… 27 6. Packetizationは統治します… 31 6.1. 一般的なPacketizationは統治します… 31 6.2. ただ一つのNALユニットモード… 32 6.3. 非はさみ込まれたモード… 32 6.4. モードをはさみ込みます… 33 7. 反-Packetizationは処理します(有益な)… 33 7.1. 単一のNAL単位と非はさみ込まれたモード… 33 7.2. モードをはさみ込みます… 34 7.3. 追加反-Packetizationガイドライン… 36 8. 有効搭載量形式パラメタ… 37 8.1. 登録をまねてください… 37 8.2. SDPパラメタ… 52 8.3. 例… 58 8.4. パラメタは問題を設定しました… 60 9. セキュリティ問題… 62 10. 混雑コントロール… 63 11. IANA問題… 64 12. 有益な付録: アプリケーションの例… 65 12.1. ITU-T推薦H.241別館A.に従ったビデオ電話… 65 12.2. ビデオ電話、部分データ仕切りでない、NALユニット集合がありません… 65 12.3. ビデオ電話、NALユニット集合を使用するはさみ込まれたPacketization… 66 12.4. データ仕切りがあるビデオ電話… 66 12.5. FUsと前進型誤信号訂正があるビデオ電話かストリーミング… 67 12.6. 低いビット伝送速度ストリーミング… 69 12.7. ビデオ・ストリーミングにおける強健なパケットスケジューリング… 70 13. 有益な付録: 注文番号を解読するための原理… 71 13.1. 序論… 71 13.2. マルチ画像部分インターリービングに関する例… 71 13.3. 強健なパケットスケジューリングに関する例… 73 13.4. 余分の強健なトランスミッションスケジューリングは部分をコード化しました… 77 13.5. 他のデザインポシビリティーズに関する所見… 77 14. 承認… 78 15. 参照… 78 15.1. 標準の参照… 78 15.2. 有益な参照… 79人の作者のアドレス… 81 完全な著作権宣言文… 83
Wenger, et al. Standards Track [Page 2] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[2ページ]。
1. Introduction
1. 序論
1.1. The H.264 Codec
1.1. H.264コーデック
This memo specifies an RTP payload specification for the video coding standard known as ITU-T Recommendation H.264 [1] and ISO/IEC International Standard 14496 Part 10 [2] (both also known as Advanced Video Coding, or AVC). Recommendation H.264 was approved by ITU-T on May 2003, and the approved draft specification is available for public review [8]. In this memo the H.264 acronym is used for the codec and the standard, but the memo is equally applicable to the ISO/IEC counterpart of the coding standard.
このメモはITU-T Recommendation H.264[1]とISO/IEC国際規格14496Part10[2](また、Advanced Video Coding、またはAVCとして知られている両方)として知られているビデオコーディング標準のためのRTPペイロード仕様を指定します。 推薦H.264は2003年5月にITU-Tによって承認されました、そして、承認された草稿仕様は公開レビュー[8]に利用可能です。 このメモでは、H.264頭文字語はコーデックと規格に使用されますが、メモは等しくコーディング標準のISO/IECの対応者に適切です。
The H.264 video codec has a very broad application range that covers all forms of digital compressed video from, low bit-rate Internet streaming applications to HDTV broadcast and Digital Cinema applications with nearly lossless coding. Compared to the current state of technology, the overall performance of H.264 is such that bit rate savings of 50% or more are reported. Digital Satellite TV quality, for example, was reported to be achievable at 1.5 Mbit/s, compared to the current operation point of MPEG 2 video at around 3.5 Mbit/s [9].
H.264ビデオコーデックはほとんどlosslessコード化と共にデジタルのフォームがビデオを圧縮したすべてをカバーする非常に広い応用範囲、低いビット伝送速度インターネットストリーミング・アプリケーションをHDTV放送とDigitalシネマアプリケーションに持っています。 技術の現状と比べて、H.264の総合的な性能がそのようなものであるので、50%以上のビット伝送速度の節約は報告されます。 例えば、デジタルSatelliteテレビの品質が1.5で達成可能であると報告されました。およそ3.5メガビット/s[9]でMPEG2ビデオの現在の操作先と比較されたメガビット/s。
The codec specification [1] itself distinguishes conceptually between a video coding layer (VCL) and a network abstraction layer (NAL). The VCL contains the signal processing functionality of the codec; mechanisms such as transform, quantization, and motion compensated prediction; and a loop filter. It follows the general concept of most of today's video codecs, a macroblock-based coder that uses inter picture prediction with motion compensation and transform coding of the residual signal. The VCL encoder outputs slices: a bit string that contains the macroblock data of an integer number of macroblocks, and the information of the slice header (containing the spatial address of the first macroblock in the slice, the initial quantization parameter, and similar information). Macroblocks in slices are arranged in scan order unless a different macroblock allocation is specified, by using the so-called Flexible Macroblock Ordering syntax. In-picture prediction is used only within a slice. More information is provided in [9].
コーデック仕様[1]自体は概念的にビデオ符号化(VCL)層とネットワーク抽象化(NAL)層を見分けます。 VCLはコーデックの信号処理の機能性を含んでいます。 変換や、量子化や、動きなどのメカニズムは予測を代償しました。 そして、ループ・フィルタ。 それは今日のビデオコーデック(残りの信号の動き補償と変換コード化による間の画像予測を使用するmacroblockベースの符号化器)の大部分に関する一般概念に従います。 VCLエンコーダは部分を出力します: macroblocksの整数に関するmacroblockデータ、および部分ヘッダーの情報(部分における最初のmacroblockの空間的なアドレス、初期の量子化パラメタの、そして、同様の情報を含んでいる)を含むしばらくストリング。 異なったmacroblock配分が指定されない場合、部分におけるMacroblocksはスキャン命令に配置されます、いわゆるFlexible Macroblock Ordering構文を使用することによって。 画像における予測は部分だけの中で使用されます。 詳しい情報を[9]に提供します。
The Network Abstraction Layer (NAL) encoder encapsulates the slice output of the VCL encoder into Network Abstraction Layer Units (NAL units), which are suitable for transmission over packet networks or use in packet oriented multiplex environments. Annex B of H.264 defines an encapsulation process to transmit such NAL units over byte-stream oriented networks. In the scope of this memo, Annex B is not relevant.
Network Abstraction Layer(NAL)エンコーダは、部分がVCLエンコーダの出力であるとNetwork Abstraction Layer Units(NALユニット)にカプセル化します。(Network Abstraction Layer Unitsはパケット網の上でトランスミッションに適しているか、またはパケットで指向のマルチプレックス環境を使用します)。 H.264の別館Bは、バイト・ストリーム指向のネットワークの上にそのようなNALユニットを送るためにカプセル化プロセスを定義します。 このメモの範囲では、Annex Bは関連していません。
Wenger, et al. Standards Track [Page 3] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[3ページ]。
Internally, the NAL uses NAL units. A NAL unit consists of a one- byte header and the payload byte string. The header indicates the type of the NAL unit, the (potential) presence of bit errors or syntax violations in the NAL unit payload, and information regarding the relative importance of the NAL unit for the decoding process. This RTP payload specification is designed to be unaware of the bit string in the NAL unit payload.
本質的に、NALはNALユニットを使用します。 NALユニットは1バイトのヘッダーとペイロードバイトストリングから成ります。 ヘッダーは解読過程のためにNALユニットのタイプか噛み付いている誤りの(潜在的)の存在かNALユニットペイロードにおける構文違反と、NALユニットの相対的な重要性の情報を示します。 このRTPペイロード仕様は、NALユニットペイロードのビット列に気づかなくなるように設計されています。
One of the main properties of H.264 is the complete decoupling of the transmission time, the decoding time, and the sampling or presentation time of slices and pictures. The decoding process specified in H.264 is unaware of time, and the H.264 syntax does not carry information such as the number of skipped frames (as is common in the form of the Temporal Reference in earlier video compression standards). Also, there are NAL units that affect many pictures and that are, therefore, inherently timeless. For this reason, the handling of the RTP timestamp requires some special considerations for NAL units for which the sampling or presentation time is not defined or, at transmission time, unknown.
H.264の主な特性の1つは部分と画像のトランスミッション時間か、解読時間と、標本抽出かプレゼンテーション時間の完全なデカップリングです。 H.264で指定された解読過程は時間に気づきません、そして、H.264構文はスキップされたフレーム(以前の画像圧縮規格における、Temporal Referenceの形のコモンのような)の数などの情報を運びません。 また、多くの画像に影響している、したがって本来永遠であることのNALユニットがあります。 この理由で、RTPタイムスタンプの取り扱いは標本抽出かプレゼンテーション時間が定義されないNALユニットかトランスミッション時の未知のためにいくつかの特別な問題を必要とします。
1.2. Parameter Set Concept
1.2. パラメタセット概念
One very fundamental design concept of H.264 is to generate self- contained packets, to make mechanisms such as the header duplication of RFC 2429 [10] or MPEG-4's Header Extension Code (HEC) [11] unnecessary. This was achieved by decoupling information relevant to more than one slice from the media stream. This higher layer meta information should be sent reliably, asynchronously, and in advance from the RTP packet stream that contains the slice packets. (Provisions for sending this information in-band are also available for applications that do not have an out-of-band transport channel appropriate for the purpose.) The combination of the higher-level parameters is called a parameter set. The H.264 specification includes two types of parameter sets: sequence parameter set and picture parameter set. An active sequence parameter set remains unchanged throughout a coded video sequence, and an active picture parameter set remains unchanged within a coded picture. The sequence and picture parameter set structures contain information such as picture size, optional coding modes employed, and macroblock to slice group map.
H.264の1つの非常に基本的な設計思想はヘッダーなどのメカニズムをRFC2429[10]かMPEG-4のHeader Extension Code(HEC)[11]の複製に不要な状態でするように含まれたパケットを自己に生成することです。 これは1切れ以上に関連しているデカップリング情報によってメディアストリームから達成されました。 非同期にこのより高い層のメタ情報を確かに送るべきです、そして、あらかじめ、RTPパケットストリームから、それは部分パケットを含みます。 (また、バンドでこの情報を送るための条項もバンドで出かけている輸送チャンネルを目的のために適切にしないアプリケーションに利用可能です。) よりハイレベルのパラメタの組み合わせはパラメタセットと呼ばれます。 H.264仕様は2つのタイプのパラメタセットを含んでいます: 系列パラメタはセットしました、そして、画像パラメタはセットしました。 活動的な系列パラメタセットはコード化されたビデオ系列中で変わりがありません、そして、活動的な画像パラメタセットはコード化された画像の中で変わりがありません。 系列と画像パラメタセット構造は画像サイズ、使われた任意のコード化モード、および部分グループへのmacroblockが写像する情報を含んでいます。
To be able to change picture parameters (such as the picture size) without having to transmit parameter set updates synchronously to the slice packet stream, the encoder and decoder can maintain a list of more than one sequence and picture parameter set. Each slice header contains a codeword that indicates the sequence and picture parameter set to be used.
同時部分パケットストリーム、エンコーダ、およびデコーダにパラメタセット最新版を伝える必要はなくて画像パラメタ(画像サイズなどの)を変えることができるのは、1つ以上の系列と画像パラメタのリストがセットしたと主張できます。 それぞれの部分ヘッダーは系列と画像パラメタが使用されるためにセットしたのを示す符号語を含んでいます。
Wenger, et al. Standards Track [Page 4] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[4ページ]。
This mechanism allows the decoupling of the transmission of parameter sets from the packet stream, and the transmission of them by external means (e.g., as a side effect of the capability exchange), or through a (reliable or unreliable) control protocol. It may even be possible that they are never transmitted but are fixed by an application design specification.
このメカニズムはパケットストリームからのパラメタセットのトランスミッションのデカップリング、および外部の手段(例えば、能力交換の副作用としての)の近く、または、(信頼できるか頼り無い)の制御プロトコルを通したそれらのトランスミッションを許容します。 それらが決して伝えられませんが、アプリケーション設計仕様で修理されているのは、可能でさえあるかもしれません。
1.3. Network Abstraction Layer Unit Types
1.3. ネットワーク抽象化層のユニット型
Tutorial information on the NAL design can be found in [12], [13], and [14].
[12]、[13]、および[14]でNALデザインの家庭教師の情報を見つけることができます。
All NAL units consist of a single NAL unit type octet, which also co-serves as the payload header of this RTP payload format. The payload of a NAL unit follows immediately.
すべてのNALユニットがただ一つのNALユニット型八重奏から成ります。(また、それは、このRTPペイロード形式のペイロードヘッダーとして共同機能します)。 NALユニットのペイロードはすぐに、続きます。
The syntax and semantics of the NAL unit type octet are specified in [1], but the essential properties of the NAL unit type octet are summarized below. The NAL unit type octet has the following format:
NALユニット型八重奏の構文と意味論は[1]で指定されますが、NALユニット型八重奏の不可欠の特性は以下へまとめられます。 NALユニット型八重奏には、以下の形式があります:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
+---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |F|NRI| タイプ| +---------------+
The semantics of the components of the NAL unit type octet, as specified in the H.264 specification, are described briefly below.
H.264仕様で指定されるNALユニット型八重奏のコンポーネントの意味論は簡潔に以下で説明されます。
F: 1 bit
forbidden_zero_bit. The H.264 specification declares a value of
1 as a syntax violation.
F: 1ビットの禁制の_ゼロ_に噛み付きました。 H.264仕様は構文違反として1の値を宣言します。
NRI: 2 bits
nal_ref_idc. A value of 00 indicates that the content of the NAL
unit is not used to reconstruct reference pictures for inter
picture prediction. Such NAL units can be discarded without
risking the integrity of the reference pictures. Values greater
than 00 indicate that the decoding of the NAL unit is required to
maintain the integrity of the reference pictures.
NRI: 2ビットのnal_審判_idc。 00の値は、NALユニットの内容が間の画像予測のために参照画像を再建するのに使用されないのを示します。 参照画像の保全を危険にさらさないで、そのようなNALユニットを捨てることができます。 値より多くの00は、NALユニットの解読が参照画像の保全を維持するのに必要であることを示します。
Type: 5 bits
nal_unit_type. This component specifies the NAL unit payload type
as defined in table 7-1 of [1], and later within this memo. For a
reference of all currently defined NAL unit types and their
semantics, please refer to section 7.4.1 in [1].
以下をタイプしてください。 5ビットのnal_ユニット_はタイプされます。 このコンポーネントは[1]のテーブル7-1と、このメモの中で、より遅く定義されるようにNALユニットペイロードタイプを指定します。 すべての現在定義されたNALユニット型と彼らの意味論の参照について、[1]のセクション7.4.1を参照してください。
Wenger, et al. Standards Track [Page 5] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[5ページ]。
This memo introduces new NAL unit types, which are presented in section 5.2. The NAL unit types defined in this memo are marked as unspecified in [1]. Moreover, this specification extends the semantics of F and NRI as described in section 5.3.
このメモは新しいNALユニット型を導入します。(そのユニット型は、セクション5.2に提示されます)。 このメモで定義されたNALユニット型は[1]で不特定であるとしてマークされます。 そのうえ、この仕様はセクション5.3で説明されるようにFとNRIの意味論について敷衍しています。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[3])で説明されるように本書では解釈されることであるべきです。
This specification uses the notion of setting and clearing a bit when bit fields are handled. Setting a bit is the same as assigning that bit the value of 1 (On). Clearing a bit is the same as assigning that bit the value of 0 (Off).
この仕様は噛み付いている分野が扱われるとき、セットして、少しクリアするという概念を使用します。 少しセットするのは1(On)の値に噛み付いた割り当てと同じです。 少しクリアするのは0(Off)の値に噛み付いた割り当てと同じです。
3. Scope
3. 範囲
This payload specification can only be used to carry the "naked" H.264 NAL unit stream over RTP, and not the bitstream format discussed in Annex B of H.264. Likely, the first applications of this specification will be in the conversational multimedia field, video telephony or video conferencing, but the payload format also covers other applications, such as Internet streaming and TV over IP.
H.264のAnnex Bで議論したbitstream形式ではなく、RTPの上まで「裸」のH.264 NALユニットストリームを運ぶのにこのペイロード仕様を使用できるだけです。 おそらく、会話のマルチメディア分野、ビデオ電話またはビデオ会議にはこの仕様の最初の利用があるでしょうが、また、ペイロード形式はインターネットストリーミングやテレビなどの他のアプリケーションをIPの上にカバーしています。
4. Definitions and Abbreviations
4. 定義と略語
4.1. Definitions
4.1. 定義
This document uses the definitions of [1]. The following terms, defined in [1], are summed up for convenience:
このドキュメントは[1]の定義を使用します。 [1]で定義された次の用語は便宜のためにまとめられます:
access unit: A set of NAL units always containing a primary coded
picture. In addition to the primary coded picture, an access unit
may also contain one or more redundant coded pictures or other NAL
units not containing slices or slice data partitions of a coded
picture. The decoding of an access unit always results in a
decoded picture.
ユニットにアクセスしてください: いつも予備選挙を含む1セットのNAL単位が絵をコード化しました。 また、第一のコード化された絵に加えて、アクセスユニットはコード化された絵の1枚以上の余分なコード化された絵、部分を含まない他のNALユニットまたは部分データパーティションを含むかもしれません。 アクセスユニットの解読はいつも解読された絵をもたらします。
coded video sequence: A sequence of access units that consists, in
decoding order, of an instantaneous decoding refresh (IDR) access
unit followed by zero or more non-IDR access units including all
subsequent access units up to but not including any subsequent IDR
access unit.
コード化されたビデオ系列: オーダーを解読する際に成るアクセスユニットの系列、瞬時に起こっている解読では、ゼロがあとに続いた(IDR)アクセスユニットをリフレッシュしてください。さもないと、より多くの非IDRがすべてのその後のアクセスユニットを包含だけでないまで含むユニットにどんなその後のIDRアクセスユニットアクセスします。
IDR access unit: An access unit in which the primary coded picture
is an IDR picture.
IDRはユニットにアクセスします: 予備選挙が絵をコード化したアクセスユニットはIDRの絵です。
Wenger, et al. Standards Track [Page 6] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[6ページ]。
IDR picture: A coded picture containing only slices with I or SI
slice types that causes a "reset" in the decoding process. After
the decoding of an IDR picture, all following coded pictures in
decoding order can be decoded without inter prediction from any
picture decoded prior to the IDR picture.
IDRは以下について描写します。 Aは解読過程でIに従った部分だけを含む画像かそれが「リセット」を引き起こすSI部分タイプをコード化しました。 IDRの絵の解読の後に、IDRの絵の前で解読されたどんな絵からも間の予測なしでオーダーを解読することにおけるすべての次のコード化された絵を解読できます。
primary coded picture: The coded representation of a picture to be
used by the decoding process for a bitstream conforming to H.264.
The primary coded picture contains all macroblocks of the picture.
予備選挙は絵をコード化しました: H.264に一致しているbitstreamに解読過程で使用されるべき絵のコード値。 第一のコード化された画像は絵のすべてのmacroblocksを含んでいます。
redundant coded picture: A coded representation of a picture or a
part of a picture. The content of a redundant coded picture shall
not be used by the decoding process for a bitstream conforming to
H.264. The content of a redundant coded picture may be used by
the decoding process for a bitstream that contains errors or
losses.
余分なコード化された絵: 絵のコード値か絵の一部。 H.264に一致しているbitstreamに解読過程で余分なコード化された絵の内容を使用しないものとします。 余分なコード化された絵の内容は誤りか損失を含むbitstreamに解読過程で使用されるかもしれません。
VCL NAL unit: A collective term used to refer to coded slice and
coded data partition NAL units.
VCL NALユニット: 集合語は以前はよくコード化された部分とコード化されたデータパーティションNALユニットについて言及していました。
In addition, the following definitions apply:
さらに、以下の定義は適用されます:
decoding order number (DON): A field in the payload structure, or
a derived variable indicating NAL unit decoding order. Values of
DON are in the range of 0 to 65535, inclusive. After reaching the
maximum value, the value of DON wraps around to 0.
解読して、数(DON)を命令してください: ペイロード構造の分野、またはオーダーを解読するNALユニットを示す派生している変数。 DONの値が0〜65535の範囲にあります。包括的。 最大値に達した後に、DONの値は0に巻きつけられます。
NAL unit decoding order: A NAL unit order that conforms to the
constraints on NAL unit order given in section 7.4.1.2 in [1].
オーダーを解読するNALユニット: NALは[1]でNALユニットオーダー当然のことコネセクション7.4.1の.2における規制に従いますユニットが、それを命令する。
transmission order: The order of packets in ascending RTP sequence
number order (in modulo arithmetic). Within an aggregation
packet, the NAL unit transmission order is the same as the order
of appearance of NAL units in the packet.
トランスミッション命令: RTP一連番号オーダー(モジュロ演算の)を昇ることにおける、パケットの注文。 集合パケットの中では、NALユニットトランスミッション命令はパケットのNALユニットの外観の注文と同じです。
media aware network element (MANE): A network element, such as a
middlebox or application layer gateway that is capable of parsing
certain aspects of the RTP payload headers or the RTP payload and
reacting to the contents.
メディア意識しているネットワーク要素(MANE): RTPペイロードヘッダーかRTPペイロードのある一定の局面を分析して、コンテンツに反応できるmiddleboxか応用層ゲートウェイなどのネットワーク要素。
Informative note: The concept of a MANE goes beyond normal
routers or gateways in that a MANE has to be aware of the
signaling (e.g., to learn about the payload type mappings of
the media streams), and in that it has to be trusted when
working with SRTP. The advantage of using MANEs is that they
allow packets to be dropped according to the needs of the media
coding. For example, if a MANE has to drop packets due to
congestion on a certain link, it can identify those packets
有益な注意: MANEがシグナリングを意識していなければならなくて(例えばメディアの流れのペイロードタイプマッピングに関して学ぶ)、SRTPと共に働いているときそれが信じられなければならないので、MANEの概念は正常なルータかゲートウェイを越えます。 MANEsを使用する利点はメディアコード化の必要性に従って彼らがパケットが低下するということです。 例えば、MANEが混雑のためあるリンクでパケットを落とさなければならないなら、それはそれらのパケットを特定できます。
Wenger, et al. Standards Track [Page 7] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[7ページ]。
whose dropping has the smallest negative impact on the user
experience and remove them in order to remove the congestion
and/or keep the delay low.
低下は、ユーザへの最も小さい負の衝撃が混雑を取り除く、そして/または、遅れを低く保つためにそれらを経験して、取り除くのをさせます。
Abbreviations
略語
DON: Decoding Order Number
DONB: Decoding Order Number Base
DOND: Decoding Order Number Difference
FEC: Forward Error Correction
FU: Fragmentation Unit
IDR: Instantaneous Decoding Refresh
IEC: International Electrotechnical Commission
ISO: International Organization for Standardization
ITU-T: International Telecommunication Union,
Telecommunication Standardization Sector
MANE: Media Aware Network Element
MTAP: Multi-Time Aggregation Packet
MTAP16: MTAP with 16-bit timestamp offset
MTAP24: MTAP with 24-bit timestamp offset
NAL: Network Abstraction Layer
NALU: NAL Unit
SEI: Supplemental Enhancement Information
STAP: Single-Time Aggregation Packet
STAP-A: STAP type A
STAP-B: STAP type B
TS: Timestamp
VCL: Video Coding Layer
以下を身につけてください。 解読して、数のDONBを注文してください: 解読注文番号はDONDを基礎づけます: 解読して、数の違いのFECを注文してください: エラー修正FUを進めてください: 断片化ユニットIDR: 瞬時に起こっている解読はIECをリフレッシュします: 国際電気標準化会議ISO: 国際標準化機構ITU-T: 国際電気通信連合、電気通信標準化セクターたてがみ: メディアの意識しているネットワーク要素MTAP: マルチ時間集合パケットMTAP16: 16ビットのタイムスタンプがあるMTAPはMTAP24を相殺します: 24ビットのタイムスタンプがあるMTAPはNALを相殺します: 抽象化層のNALUをネットワークでつないでください: NALユニットSEI: 補足の増進情報STAP: ただ一つの時間集合パケットSTAP-A: STAPはA STAP-Bをタイプします: STAPはB TSをタイプします: タイムスタンプVCL: ビデオ符号化層
5. RTP Payload Format
5. RTP有効搭載量形式
5.1. RTP Header Usage
5.1. RTPヘッダー用法
The format of the RTP header is specified in RFC 3550 [4] and reprinted in Figure 1 for convenience. This payload format uses the fields of the header in a manner consistent with that specification.
RTPヘッダーの形式は、RFC3550[4]で指定されて、便宜のために図1で増刷されます。 このペイロード形式はその仕様と一致した方法でヘッダーの分野を使用します。
When one NAL unit is encapsulated per RTP packet, the RECOMMENDED RTP payload format is specified in section 5.6. The RTP payload (and the settings for some RTP header bits) for aggregation packets and fragmentation units are specified in sections 5.7 and 5.8, respectively.
1NALユニットがRTPパケット単位で要約されるとき、RECOMMENDED RTPペイロード形式はセクション5.6で指定されます。 集合パケットと断片化ユニットRTPペイロード(そして、いくつかのRTPヘッダービット設定)はセクション5.7に5.8にそれぞれ指定されています。
Wenger, et al. Standards Track [Page 8] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[8ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC|M| 太平洋標準時| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 同期ソース(SSRC)識別子| +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ソース(CSRC)識別子を寄付します。| | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. RTP header according to RFC 3550
図1。 RFC3550に従ったRTPヘッダー
The RTP header information to be set according to this RTP payload format is set as follows:
このRTPペイロード形式に従って設定されるべきRTPヘッダー情報は以下の通り設定されます:
Marker bit (M): 1 bit
Set for the very last packet of the access unit indicated by the
RTP timestamp, in line with the normal use of the M bit in video
formats, to allow an efficient playout buffer handling. For
aggregation packets (STAP and MTAP), the marker bit in the RTP
header MUST be set to the value that the marker bit of the last
NAL unit of the aggregation packet would have been if it were
transported in its own RTP packet. Decoders MAY use this bit as
an early indication of the last packet of an access unit, but MUST
NOT rely on this property.
マーカービット(M): アクセスユニットの最後のまさしくそのパケットのための1ビットのSetは、標準に沿ったRTPタイムスタンプでMの使用に効率的な再生バッファ取り扱いを許すためにビデオ形式で噛み付いたのを示しました。 集合パケット(STAPとMTAP)に関しては、RTPヘッダーのマーカービットはマーカーが噛み付いた集合パケットの最後のNALユニットの値へのセットがそれがそれ自身のRTPパケットで輸送されたかどうかということであっただろうということであるに違いありません。 デコーダは、アクセスユニットの最後のパケットの早めのしるしとしてこのビットを使用するかもしれませんが、この特性を当てにしてはいけません。
Informative note: Only one M bit is associated with an
aggregation packet carrying multiple NAL units. Thus, if a
gateway has re-packetized an aggregation packet into several
packets, it cannot reliably set the M bit of those packets.
有益な注意: 噛み付かれたのMだけが複数のNALユニット運ぶ集合パケットに関連しています。 したがって、ゲートウェイが再packetizedされた集合パケットをいくつかのパケットに持っているなら、それはそれらのパケットについて噛み付かれたMを確かに設定できません。
Payload type (PT): 7 bits
The assignment of an RTP payload type for this new packet format
is outside the scope of this document and will not be specified
here. The assignment of a payload type has to be performed either
through the profile used or in a dynamic way.
有効搭載量タイプ(太平洋標準時の): この新しいパケット・フォーマットのためのRTPペイロードタイプの課題は、7ビット、このドキュメントの範囲の外にあって、ここで指定されないでしょう。 ペイロードタイプの課題は使用されるプロフィールかダイナミックな方法で実行されなければなりません。
Sequence number (SN): 16 bits
Set and used in accordance with RFC 3550. For the single NALU and
non-interleaved packetization mode, the sequence number is used to
determine decoding order for the NALU.
一連番号(SN): RFC3550によると、Setの、そして、中古の16ビット。 独身のNALUと非はさみ込まれたpacketizationモードにおいて、一連番号はNALUの注文を解読するのにおいて決定するのにおいて使用されています。
Timestamp: 32 bits
The RTP timestamp is set to the sampling timestamp of the content.
A 90 kHz clock rate MUST be used.
タイムスタンプ: 32ビット、RTPタイムスタンプは内容に関する標本抽出タイムスタンプに設定されます。 90kHzのクロックレートを使用しなければなりません。
Wenger, et al. Standards Track [Page 9] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[9ページ]。
If the NAL unit has no timing properties of its own (e.g.,
parameter set and SEI NAL units), the RTP timestamp is set to the
RTP timestamp of the primary coded picture of the access unit in
which the NAL unit is included, according to section 7.4.1.2 of
[1].
NALユニットにそれ自身(例えば、パラメタセットとSEI NALユニット)のタイミング特性が全くないなら、RTPタイムスタンプはNALユニットが含まれているアクセスユニットの第一のコード化された絵に関するRTPタイムスタンプに設定されます、セクション7.4によると。.1 .2 [1]について。
The setting of the RTP Timestamp for MTAPs is defined in section
5.7.2.
MTAPsのためのRTP Timestampの設定はセクション5.7.2で定義されます。
Receivers SHOULD ignore any picture timing SEI messages included
in access units that have only one display timestamp. Instead,
receivers SHOULD use the RTP timestamp for synchronizing the
display process.
1つの表示タイムスタンプしか持っていないアクセスユニットにタイミングSEIメッセージを含んでいて、受信機SHOULDはどんな絵も無視します。 代わりに、受信機SHOULDは、表示の過程を同期させるのにRTPタイムスタンプを使用します。
RTP senders SHOULD NOT transmit picture timing SEI messages for
pictures that are not supposed to be displayed as multiple fields.
RTP送付者SHOULD NOTは複数の分野として表示されるべきでない絵への絵のタイミングSEIメッセージを送ります。
If one access unit has more than one display timestamp carried in
a picture timing SEI message, then the information in the SEI
message SHOULD be treated as relative to the RTP timestamp, with
the earliest event occurring at the time given by the RTP
timestamp, and subsequent events later, as given by the difference
in SEI message picture timing values. Let tSEI1, tSEI2, ...,
tSEIn be the display timestamps carried in the SEI message of an
access unit, where tSEI1 is the earliest of all such timestamps.
Let tmadjst() be a function that adjusts the SEI messages time
scale to a 90-kHz time scale. Let TS be the RTP timestamp. Then,
the display time for the event associated with tSEI1 is TS. The
display time for the event with tSEIx, where x is [2..n] is TS +
tmadjst (tSEIx - tSEI1).
絵のタイミングSEIメッセージで1アクセスユニットで1つ以上の表示タイムスタンプを運ぶなら、SEIメッセージSHOULDの情報がRTPタイムスタンプに比例して扱われて、RTPタイムスタンプで与えるとき最も早い出来事が起こって、その後の出来事が後であることの状態で、SEIメッセージの違いで与えるようにタイミング値について描写してください。 tSEI1、tSEI2、…をさせてください。, tSEIn、tSEI1がすべて、そのようにタイムスタンプである最も初期であるアクセスユニットに関するSEIメッセージで運ばれた表示タイムスタンプになってください。 tmadjst()が90kHzのタイムスケールにSEIメッセージタイムスケールを調整する機能であることをさせてください。 TSがRTPタイムスタンプであることをさせてください。 そして、tSEI1に関連している出来事のための表示時間はTSです。 tSEIxがある出来事のための表示時間であり、xがどこの[2..n]であるかはTS+tmadjst(tSEIx--tSEI1)です。
Informative note: Displaying coded frames as fields is needed
commonly in an operation known as 3:2 pulldown, in which film
content that consists of coded frames is displayed on a display
using interlaced scanning. The picture timing SEI message
enables carriage of multiple timestamps for the same coded
picture, and therefore the 3:2 pulldown process is perfectly
controlled. The picture timing SEI message mechanism is
necessary because only one timestamp per coded frame can be
conveyed in the RTP timestamp.
有益な注意: 分野としてコード化されたフレームを表示するのが、コード化されたフレームから成るどのフィルム含有量を表示に表示するかの折りたたみ式の3:2として知られている操作で飛越走査方式を使用することで一般的に必要です。 絵のタイミングSEIメッセージは同じコード化された絵のための複数のタイムスタンプのキャリッジを可能にします、そして、したがって、3:2の折りたたみ式の過程は完全に制御されます。 絵のタイミングSEIメッセージメカニズムが、RTPタイムスタンプでコード化されたフレームあたり1つのタイムスタンプしか伝えることができないので、必要です。
Informative note: Because H.264 allows the decoding order to be
different from the display order, values of RTP timestamps may
not be monotonically non-decreasing as a function of RTP
sequence numbers. Furthermore, the value for interarrival
jitter reported in the RTCP reports may not be a trustworthy
indication of the network performance, as the calculation rules
有益な注意: H.264がRTP一連番号の関数として非減少する状態で表示命令と異なります、RTPタイムスタンプの値がないかもしれないということである解読命令を単調に許すので。 その上、RTCPレポートで報告されたinterarrivalジターのための値はネットワーク性能の信頼できるしるしでないかもしれません、計算が統治されるように
Wenger, et al. Standards Track [Page 10] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[10ページ]。
for interarrival jitter (section 6.4.1 of RFC 3550) assume that
the RTP timestamp of a packet is directly proportional to its
transmission time.
interarrivalジター(.1セクション6.4RFC3550)に関しては、パケットのRTPタイムスタンプがトランスミッション時間に正比例していると仮定してください。
5.2. Common Structure of the RTP Payload Format
5.2. RTP有効搭載量形式の一般的な構造
The payload format defines three different basic payload structures. A receiver can identify the payload structure by the first byte of the RTP payload, which co-serves as the RTP payload header and, in some cases, as the first byte of the payload. This byte is always structured as a NAL unit header. The NAL unit type field indicates which structure is present. The possible structures are as follows:
ペイロード形式は3つの異なった基本的なペイロード構造を定義します。 RTPペイロードの最初のバイトに従って、受信機はペイロード構造を特定できます。(ペイロードはRTPペイロードヘッダーとしていくつかの場合ペイロードの最初のバイトとして共同機能します)。 このバイトはNALユニットヘッダーとしていつも構造化されます。 NALユニット型分野は、どの構造が存在しているかを示します。 可能な構造は以下の通りです:
Single NAL Unit Packet: Contains only a single NAL unit in the payload. The NAL header type field will be equal to the original NAL unit type; i.e., in the range of 1 to 23, inclusive. Specified in section 5.6.
単一のNALユニットパケット: ペイロードに単一のNAL単位だけを含んでいます。 NALヘッダータイプ分野は元のNALユニット型と等しくなるでしょう。 すなわち、1〜23の範囲で包括的である、包括的です。 セクション5.6では、指定されています。
Aggregation packet: Packet type used to aggregate multiple NAL units into a single RTP payload. This packet exists in four versions, the Single-Time Aggregation Packet type A (STAP-A), the Single-Time Aggregation Packet type B (STAP-B), Multi-Time Aggregation Packet (MTAP) with 16-bit offset (MTAP16), and Multi-Time Aggregation Packet (MTAP) with 24-bit offset (MTAP24). The NAL unit type numbers assigned for STAP-A, STAP-B, MTAP16, and MTAP24 are 24, 25, 26, and 27, respectively. Specified in section 5.7.
集合パケット: パケットタイプは以前はよく複数のNALユニットをただ一つのRTPペイロードに集めていました。 このパケットは4つのバージョンに存在しています、Aggregation PacketがAをタイプするSingle-時代に。(STAP-a)、Single-時間Aggregation PacketタイプB(STAP-B)、16ビットのオフセット(MTAP16)があるMulti-時間Aggregation Packet(MTAP)、および24ビットがあるMulti-時間Aggregation Packet(MTAP)は(MTAP24)を相殺します。 STAP-A、STAP-B、MTAP16、およびMTAP24のために割り当てられたNALユニット型番号は、それぞれ24と、25と、26と、27です。 セクション5.7では、指定されています。
Fragmentation unit: Used to fragment a single NAL unit over multiple RTP packets. Exists with two versions, FU-A and FU-B, identified with the NAL unit type numbers 28 and 29, respectively. Specified in section 5.8.
断片化ユニット: 複数のRTPパケットの上で単一のNAL単位を断片化するのにおいて、使用されています。 それぞれNALユニット型No.28と29と同一視された2つのバージョン、FU-A、およびFU-Bと共に存在しています。 セクション5.8では、指定されています。
Table 1. Summary of NAL unit types and their payload structures
1を見送ってください。 NALユニット型と彼らのペイロード構造の概要
Type Packet Type name Section
---------------------------------------------------------
0 undefined -
1-23 NAL unit Single NAL unit packet per H.264 5.6
24 STAP-A Single-time aggregation packet 5.7.1
25 STAP-B Single-time aggregation packet 5.7.1
26 MTAP16 Multi-time aggregation packet 5.7.2
27 MTAP24 Multi-time aggregation packet 5.7.2
28 FU-A Fragmentation unit 5.8
29 FU-B Fragmentation unit 5.8
30-31 undefined -
Packet Type名前セクションをタイプしてください。--------------------------------------------------------- 0、未定義である、1-23 H.264 5.6 24STAP-A Single-時間集合パケット5.7.1 25STAP-B Single-時間集合パケット5.7.1 26MTAP16 Multi-時間集合パケット5.7.2 27MTAP24 Multi-時間集合パケット5.7.2 28FU-A Fragmentation単位5.8 29FU-B Fragmentationユニット5.8 30-31未定義であるのあたりのNALユニットSingle NALユニットパケット、-
Wenger, et al. Standards Track [Page 11] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[11ページ]。
Informative note: This specification does not limit the size of
NAL units encapsulated in single NAL unit packets and
fragmentation units. The maximum size of a NAL unit encapsulated
in any aggregation packet is 65535 bytes.
有益な注意: この仕様は単一のNALユニットパケットと断片化単位で要約されたNALユニットのサイズを制限しません。 どんな集合パケットでも要約されたNALユニットの最大サイズは65535バイトです。
5.3. NAL Unit Octet Usage
5.3. NALユニット八重奏用法
The structure and semantics of the NAL unit octet were introduced in section 1.3. For convenience, the format of the NAL unit type octet is reprinted below:
NALユニット八重奏の構造と意味論はセクション1.3で紹介されました。 便利において、NALユニット型八重奏の形式は以下で増刷されます:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
+---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |F|NRI| タイプ| +---------------+
This section specifies the semantics of F and NRI according to this specification.
このセクションはこの仕様通りにFとNRIの意味論を指定します。
F: 1 bit
forbidden_zero_bit. A value of 0 indicates that the NAL unit type
octet and payload should not contain bit errors or other syntax
violations. A value of 1 indicates that the NAL unit type octet
and payload may contain bit errors or other syntax violations.
F: 1ビットの禁制の_ゼロ_に噛み付きました。 0の値は、NALユニット型八重奏とペイロードが噛み付いている誤りか他の構文違反を含むはずがないのを示します。 1の値は、NALユニット型八重奏とペイロードが噛み付いている誤りか他の構文違反を含むかもしれないのを示します。
MANEs SHOULD set the F bit to indicate detected bit errors in the
NAL unit. The H.264 specification requires that the F bit is
equal to 0. When the F bit is set, the decoder is advised that
bit errors or any other syntax violations may be present in the
payload or in the NAL unit type octet. The simplest decoder
reaction to a NAL unit in which the F bit is equal to 1 is to
discard such a NAL unit and to conceal the lost data in the
discarded NAL unit.
MANEs SHOULDは、FビットにNALユニットにおける検出された噛み付いている誤りを示すように設定します。 H.264仕様は、Fビットが0と等しいのを必要とします。 Fビットが設定されるとき、デコーダは噛み付いている誤りかいかなる他の構文違反もペイロードかNALユニット型八重奏で存在しているかもしれないと忠告されます。 Fビットが1と等しいNALユニットへの最も簡単なデコーダ反応は、そのようなNALユニットを捨てて、捨てられたNALユニットのロストデータを隠すことです。
NRI: 2 bits
nal_ref_idc. The semantics of value 00 and a non-zero value
remain unchanged from the H.264 specification. In other words, a
value of 00 indicates that the content of the NAL unit is not used
to reconstruct reference pictures for inter picture prediction.
Such NAL units can be discarded without risking the integrity of
the reference pictures. Values greater than 00 indicate that the
decoding of the NAL unit is required to maintain the integrity of
the reference pictures.
NRI: 2ビットのnal_審判_idc。 価値00の意味論と非ゼロ値はH.264仕様から変わりがありません。 言い換えれば、00の値は、NALユニットの内容が間の絵の予測のために参照の絵を再建するのに使用されないのを示します。 参照の絵の保全を危険にさらさないで、そのようなNALユニットを捨てることができます。 値より多くの00は、NALユニットの解読が参照の絵の保全を維持するのに必要であることを示します。
In addition to the specification above, according to this RTP
payload specification, values of NRI greater than 00 indicate the
relative transport priority, as determined by the encoder. MANEs
このRTPペイロード仕様に従ったNRIの値を超えた仕様に加えて、00以上は相対的な輸送優先権を示します、エンコーダで決定するように。 たてがみ
Wenger, et al. Standards Track [Page 12] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[12ページ]。
can use this information to protect more important NAL units
better than they do less important NAL units. The highest
transport priority is 11, followed by 10, and then by 01; finally,
00 is the lowest.
それほど重要でないNALユニットをするより何ユニットも良いさらに重要なNALを保護するのにこの情報を使用できます。 最も高い輸送優先度は10、およびそして、01がいうことになった11です。 最終的に、00は最も低いです。
Informative note: Any non-zero value of NRI is handled
identically in H.264 decoders. Therefore, receivers need not
manipulate the value of NRI when passing NAL units to the
decoder.
有益な注意: NRIのどんな非ゼロ値も同様にH.264デコーダで扱われます。 したがって、デコーダへのユニットをNALに通過するとき、受信機はNRIの値を操る必要はありません。
An H.264 encoder MUST set the value of NRI according to the H.264
specification (subclause 7.4.1) when the value of nal_unit_type is
in the range of 1 to 12, inclusive. In particular, the H.264
specification requires that the value of NRI SHALL be equal to 0
for all NAL units having nal_unit_type equal to 6, 9, 10, 11, or
12.
H.264エンコーダがH.264仕様通りにNRIの値を設定しなければならない、(「副-節」、7.4、.1、)、_nalの値であるときに、ユニット_タイプが1〜12の範囲にあります、包括的です。 特に、H.264仕様は、6、9、10、11、または12と等しいnal_ユニット_タイプがあるすべてのNALユニットに、NRI SHALLの値が0と等しいのを必要とします。
For NAL units having nal_unit_type equal to 7 or 8 (indicating a
sequence parameter set or a picture parameter set, respectively),
an H.264 encoder SHOULD set the value of NRI to 11 (in binary
format). For coded slice NAL units of a primary coded picture
having nal_unit_type equal to 5 (indicating a coded slice
belonging to an IDR picture), an H.264 encoder SHOULD set the
value of NRI to 11 (in binary format).
nal_ユニット_タイプがSHOULDを7か8(系列パラメタがセットしたか、または絵のパラメタがセットしたのを示しますそれぞれ)、H.264エンコーダとの等しさにすると、NALユニット、NRIの値は11に設定されました(バイナリフォーマットで)。 コード化された部分NALのために、nal_ユニット_タイプがSHOULDを5(IDRの絵に属すコード化された部分を示す)、H.264エンコーダとの等しさにする第一のコード化された絵のユニットは11(バイナリフォーマットの)にNRIの値を設定します。
For a mapping of the remaining nal_unit_types to NRI values, the
following example MAY be used and has been shown to be efficient
in a certain environment [13]. Other mappings MAY also be
desirable, depending on the application and the H.264/AVC Annex A
profile in use.
NRI値への残っているnal_ユニット_タイプのマッピングに関しては、以下の例は、使用されているかもしれなくて、ある環境[13]で効率的になるように示されました。 また、アプリケーションとH.264/AVC Annex Aプロフィールに使用中によって、他のマッピングも望ましいかもしれません。
Informative note: Data Partitioning is not available in certain
profiles; e.g., in the Main or Baseline profiles.
Consequently, the nal unit types 2, 3, and 4 can occur only if
the video bitstream conforms to a profile in which data
partitioning is allowed and not in streams that conform to the
Main or Baseline profiles.
有益な注意: データPartitioningはあるプロフィールで利用可能ではありません。 例えば、MainかBaselineプロフィールで。 その結果、ビデオbitstreamがデータ仕切りがMainに一致している流れかBaselineプロフィールに許容されているのではなく、許されているプロフィールに一致している場合にだけ、nalユニット型2、3、および4は起こることができます。
Table 2. Example of NRI values for coded slices and coded slice
data partitions of primary coded reference pictures
2を見送ってください。 コード化された部分のためのNRI値に関する例と第一のコード化された参照の絵のコード化された部分データパーティション
NAL Unit Type Content of NAL unit NRI (binary)
----------------------------------------------------------------
1 non-IDR coded slice 10
2 Coded slice data partition A 10
3 Coded slice data partition B 01
4 Coded slice data partition C 01
NALユニットNRI(バイナリー)のNAL Unit Type Content---------------------------------------------------------------- 1 非IDRは部分10 2Coded部分データパーティションA10 3Coded部分データパーティションB01 4Coded部分データパーティションC01をコード化しました。
Wenger, et al. Standards Track [Page 13] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[13ページ]。
Informative note: As mentioned before, the NRI value of non-
reference pictures is 00 as mandated by H.264/AVC.
有益な注意: 以前言及されるように、H.264/AVCによって強制されるように非参照している絵のNRI値は00です。
An H.264 encoder SHOULD set the value of NRI for coded slice and
coded slice data partition NAL units of redundant coded reference
pictures equal to 01 (in binary format).
コード化された部分のためのNRIの値とコード化された部分データパーティションNAL単位の余分なコード化された参照の絵が01(バイナリフォーマットの)と等しいH.264エンコーダSHOULDセット。
Definitions of the values for NRI for NAL unit types 24 to 29,
inclusive, are given in sections 5.7 and 5.8 of this memo.
このメモのセクション5.7と5.8でNALユニット型24〜29のためのNRIのための値の包括的な定義を与えます。
No recommendation for the value of NRI is given for NAL units
having nal_unit_type in the range of 13 to 23, inclusive, because
these values are reserved for ITU-T and ISO/IEC. No
recommendation for the value of NRI is given for NAL units having
nal_unit_type equal to 0 or in the range of 30 to 31, inclusive,
as the semantics of these values are not specified in this memo.
NRIの値のための推薦を全くnal_ユニット_タイプが13〜23の範囲にあるNALユニット与えません、包括的です、これらの値がITU-TとISO/IECのために予約されるので。 推薦は、全くNRIの値を与えるので、このメモでこれらの値の意味論が0か包括的な30〜31の範囲において等しいのですが、nal_ユニット_タイプがあるNALユニット指定しませんでした。
5.4. Packetization Modes
5.4. Packetizationモード
This memo specifies three cases of packetization modes:
このメモは3つのケースのpacketizationモードを指定します:
o Single NAL unit mode
o Non-interleaved mode
o Interleaved mode
o ただ一つのNALユニットモードoはモードo InterleavedモードをNonはさみ込みました。
The single NAL unit mode is targeted for conversational systems that comply with ITU-T Recommendation H.241 [15] (see section 12.1). The non-interleaved mode is targeted for conversational systems that may not comply with ITU-T Recommendation H.241. In the non-interleaved mode, NAL units are transmitted in NAL unit decoding order. The interleaved mode is targeted for systems that do not require very low end-to-end latency. The interleaved mode allows transmission of NAL units out of NAL unit decoding order.
ただ一つのNALユニットモードはITU-T Recommendation H.241[15]に従う会話システムのために狙います(セクション12.1を見てください)。 非はさみ込まれたモードはITU-T Recommendation H.241に従わないかもしれない会話システムのために狙います。 非はさみ込まれたモードで、NALユニットは、オーダーを解読しながら、NALユニットで送られます。 はさみ込まれたモードは安値が終わるために非常に終わっている潜在を必要としないシステムのために狙います。 はさみ込まれたモードはオーダーを解読するNALユニットからNALユニットのトランスミッションを許容します。
The packetization mode in use MAY be signaled by the value of the OPTIONAL packetization-mode MIME parameter or by external means. The used packetization mode governs which NAL unit types are allowed in RTP payloads. Table 3 summarizes the allowed NAL unit types for each packetization mode. Some NAL unit type values (indicated as undefined in Table 3) are reserved for future extensions. NAL units of those types SHOULD NOT be sent by a sender and MUST be ignored by a receiver. For example, the Types 1-23, with the associated packet type "NAL unit", are allowed in "Single NAL Unit Mode" and in "Non- Interleaved Mode", but disallowed in "Interleaved Mode". Packetization modes are explained in more detail in section 6.
OPTIONAL packetization-モードMIMEパラメタの値か外部の手段で使用中のpacketizationモードは合図されるかもしれません。 中古のpacketizationモードは、どのNALユニット型がRTPペイロードに許容されているかを治めます。 テーブル3はそれぞれのpacketizationモードのための許容NALユニット型をまとめます。 いくつかのNALユニット型値(Table3で未定義であるとして、示される)が今後の拡大のために予約されます。 NALユニットのそういったタイプの人SHOULD NOTを送付者によって送られて、受信機で無視しなければなりません。例えば、関連パケットタイプ「NALユニット」で、Types1-23は「ただ一つのNALユニットモード」と「非はさみ込まれたモード」で許容されていますが、「はさみ込まれたモード」で禁じられます。 Packetizationモードはさらに詳細にセクション6で説明されます。
Wenger, et al. Standards Track [Page 14] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[14ページ]。
Table 3. Summary of allowed NAL unit types for each packetization mode (yes = allowed, no = disallowed, ig = ignore)
3を見送ってください。 それぞれのpacketizationモードのための許容NALユニット型の概要(はい=が許容した禁じられたig=が無視しない=全く)
Type Packet Single NAL Non-Interleaved Interleaved
Unit Mode Mode Mode
-------------------------------------------------------------
パケットの独身のNALをタイプしてください、非はさみ込まれたはさみ込まれたユニットモードモードモード-------------------------------------------------------------
0 undefined ig ig ig
1-23 NAL unit yes yes no
24 STAP-A no yes no
25 STAP-B no no yes
26 MTAP16 no no yes
27 MTAP24 no no yes
28 FU-A no yes yes
29 FU-B no no yes
30-31 undefined ig ig ig
0の未定義のig ig ig1-23NALユニットはいはいノー、24STAP-A、いいえ、はい、いいえ、25STAP-B、いいえ、いいえ、はい、26MTAP16、いいえ、いいえ、はい、27MTAP24、いいえ、いいえ、はい、28FU-A、はい30-31、未定義のはいはい29FU-Bノーないig ig ig
5.5. Decoding Order Number (DON)
5.5. 注文番号を解読します。(氏)
In the interleaved packetization mode, the transmission order of NAL units is allowed to differ from the decoding order of the NAL units. Decoding order number (DON) is a field in the payload structure or a derived variable that indicates the NAL unit decoding order. Rationale and examples of use cases for transmission out of decoding order and for the use of DON are given in section 13.
はさみ込まれたpacketizationモードで、NALユニットのトランスミッション命令はNALユニットの解読注文と異なることができます。 注文番号(DON)を解読するのは、オーダーを解読するNALユニットを示すペイロード構造か派生している変数で分野です。 オーダーを解読するのからのトランスミッションとDONの使用のためのケースがセクション13で与えられている使用に関する原理と例。
The coupling of transmission and decoding order is controlled by the OPTIONAL sprop-interleaving-depth MIME parameter as follows. When the value of the OPTIONAL sprop-interleaving-depth MIME parameter is equal to 0 (explicitly or per default) or transmission of NAL units out of their decoding order is disallowed by external means, the transmission order of NAL units MUST conform to the NAL unit decoding order. When the value of the OPTIONAL sprop-interleaving-depth MIME parameter is greater than 0 or transmission of NAL units out of their decoding order is allowed by external means,
トランスミッションと解読注文のカップリングは以下のOPTIONAL spropインターリービングの深さMIMEパラメタによって制御されます。 OPTIONAL spropインターリービングの深さMIMEパラメタの値が0(明らかかデフォルトあたりの)と等しいか、またはオーダーを解読するのからのNALユニットのトランスミッションが外部の手段で禁じられるとき、NALユニットのトランスミッション命令はオーダーを解読するNALユニットに従わなければなりません。 いつ、OPTIONAL spropインターリービングの深さMIMEパラメタの値が0以上であるか、そして、オーダーを解読するのからのNALユニットのトランスミッションが外部の手段で許容されています。
o the order of NAL units in an MTAP16 and an MTAP24 is NOT REQUIRED
to be the NAL unit decoding order, and
o そしてMTAP16とMTAP24でのNALユニットの注文がオーダーを解読するNALユニットであるNOT REQUIREDである。
o the order of NAL units generated by decapsulating STAP-Bs, MTAPs,
and FUs in two consecutive packets is NOT REQUIRED to be the NAL
unit decoding order.
o decapsulating STAP-Bs、MTAPs、およびFUsによって2つの連続したパケットで発生したNALユニットの注文はオーダーを解読するNALユニットであるNOT REQUIREDです。
The RTP payload structures for a single NAL unit packet, an STAP-A, and an FU-A do not include DON. STAP-B and FU-B structures include DON, and the structure of MTAPs enables derivation of DON as specified in section 5.7.2.
単一のNALユニットパケットのためのRTPペイロード構造、STAP-A、およびFU-AはDONを含んでいません。 STAP-BとFU-B構造はDONを含んでいます、そして、MTAPsの構造はセクション5.7.2における指定されるとしてのDONの派生を可能にします。
Wenger, et al. Standards Track [Page 15] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[15ページ]。
Informative note: When an FU-A occurs in interleaved mode, it
always follows an FU-B, which sets its DON.
有益な注意: FU-Aがはさみ込まれたモードで起こるとき、それはいつもFU-Bに続きます。(FU-BはDONを設定します)。
Informative note: If a transmitter wants to encapsulate a single
NAL unit per packet and transmit packets out of their decoding
order, STAP-B packet type can be used.
有益な注意: 送信機がパケット単位で単一のNAL単位を要約して、オーダーを解読しないようにパケットを伝えたいなら、STAP-Bパケットタイプを使用できます。
In the single NAL unit packetization mode, the transmission order of NAL units, determined by the RTP sequence number, MUST be the same as their NAL unit decoding order. In the non-interleaved packetization mode, the transmission order of NAL units in single NAL unit packets, STAP-As, and FU-As MUST be the same as their NAL unit decoding order. The NAL units within an STAP MUST appear in the NAL unit decoding order. Thus, the decoding order is first provided through the implicit order within a STAP, and second provided through the RTP sequence number for the order between STAPs, FUs, and single NAL unit packets.
単一のNAL単位では、packetizationモード(RTP一連番号で決定するNALユニットのトランスミッション順番)はオーダーを解読するそれらのNALユニットと同じであるに違いありません。 非はさみ込まれたpacketizationモード、単一のNALユニットパケットでのNALユニットのトランスミッション命令でSTAP、-、FU、-、オーダーを解読するそれらのNALユニットと同じくらいはそうであるに違いありません。 STAP MUSTの中のNALユニットは、オーダーを解読しながら、NALユニットに現れます。 したがって、最初にSTAPの中の暗黙のオーダーで解読オーダーを提供します、そして、パケットは2番目に、RTP一連番号を通してSTAPsと、FUsと、単一のNAL単位の間のオーダーに提供されました。
Signaling of the value of DON for NAL units carried in STAP-B, MTAP, and a series of fragmentation units starting with an FU-B is specified in sections 5.7.1, 5.7.2, and 5.8, respectively. The DON value of the first NAL unit in transmission order MAY be set to any value. Values of DON are in the range of 0 to 65535, inclusive. After reaching the maximum value, the value of DON wraps around to 0.
そして、DONの価値にNALユニット合図して、断片化ユニットのSTAP-B、MTAP、およびaシリーズで運ばれて、FU-Bから始まって、指定されたコネセクション5.7.1、5.7が.2である、5.8 それぞれ。 トランスミッション命令における、最初のNALユニットのDON値はどんな値にも設定されるかもしれません。 DONの値が0〜65535の範囲にあります。包括的。 最大値に達した後に、DONの値は0に巻きつけられます。
The decoding order of two NAL units contained in any STAP-B, MTAP, or a series of fragmentation units starting with an FU-B is determined as follows. Let DON(i) be the decoding order number of the NAL unit having index i in the transmission order. Function don_diff(m,n) is specified as follows:
FU-Bから始まって、どんなSTAP-B、MTAP、または一連の断片化ユニットにも含まれた2NALユニットの解読注文は以下の通り決定しています。 DON(i)がトランスミッション命令にインデックスiを持っているNALユニットの解読注文番号であることをさせてください。 機能氏_デフ(m、n)は以下の通り指定されます:
If DON(m) == DON(n), don_diff(m,n) = 0
DON(m)=DON(n)、_デフ(m、n)=0を身につけてくださいなら
If (DON(m) < DON(n) and DON(n) - DON(m) < 32768),
don_diff(m,n) = DON(n) - DON(m)
(DON(m)<DON(n)とDON(n)--DON(m)<32768)、氏_デフ(m、n)=DON(n)--DON(m)
If (DON(m) > DON(n) and DON(m) - DON(n) >= 32768),
don_diff(m,n) = 65536 - DON(m) + DON(n)
(DON(m)>DON(n)とDON(m)--DON(n)>=32768)、氏_デフ(m、n)=65536--DON(m)+DON(n)
If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768),
don_diff(m,n) = - (DON(m) + 65536 - DON(n))
(DON(m)<DON(n)とDON(n)--DON(m)>=32768)、_デフ(m、n)=を身につけてください、-(氏(m)+65536--(n))を身につけてください。
If (DON(m) > DON(n) and DON(m) - DON(n) < 32768),
don_diff(m,n) = - (DON(m) - DON(n))
(DON(m)>DON(n)とDON(m)--DON(n)<32768)、_デフ(m、n)=を身につけてください、-((m)を身につけてください--(n))を身につけてください。
A positive value of don_diff(m,n) indicates that the NAL unit having transmission order index n follows, in decoding order, the NAL unit having transmission order index m. When don_diff(m,n) is equal to 0,
氏_デフ(m、n)の正の数は、オーダー(トランスミッション順位指数mを持っているNALユニット)を解読する際にトランスミッション順位指数nを持っているNALユニットが続くのを示します。 氏_デフ(m、n)が0と等しいときに
Wenger, et al. Standards Track [Page 16] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[16ページ]。
then the NAL unit decoding order of the two NAL units can be in either order. A negative value of don_diff(m,n) indicates that the NAL unit having transmission order index n precedes, in decoding order, the NAL unit having transmission order index m.
そして、2NALユニットの注文を解読するNALユニットがオーダーにあることができます。 氏_デフ(m、n)の負の数は、オーダー(トランスミッション順位指数mを持っているNALユニット)を解読する際にトランスミッション順位指数nを持っているNALユニットが先行するのを示します。
Values of DON related fields (DON, DONB, and DOND; see section 5.7) MUST be such that the decoding order determined by the values of DON, as specified above, conforms to the NAL unit decoding order. If the order of two NAL units in NAL unit decoding order is switched and the new order does not conform to the NAL unit decoding order, the NAL units MUST NOT have the same value of DON. If the order of two consecutive NAL units in the NAL unit stream is switched and the new order still conforms to the NAL unit decoding order, the NAL units MAY have the same value of DON. For example, when arbitrary slice order is allowed by the video coding profile in use, all the coded slice NAL units of a coded picture are allowed to have the same value of DON. Consequently, NAL units having the same value of DON can be decoded in any order, and two NAL units having a different value of DON should be passed to the decoder in the order specified above. When two consecutive NAL units in the NAL unit decoding order have a different value of DON, the value of DON for the second NAL unit in decoding order SHOULD be the value of DON for the first, incremented by one.
DON関連分野(ドン、DONB、およびDOND; セクション5.7を見る)の値がそのようなものでなければならないので、上で指定されるとして、オーダーがDONの値で決定した解読はオーダーを解読するNALユニットに従います。 オーダーを解読するNALユニットにおける、2NALユニットの注文を切り換えて、新しいオーダーがオーダーを解読するNALユニットに従わないなら、NALユニットには、DONの同じ値があってはいけません。 NALユニットの連続したNALユニットが流す2の注文を切り換えて、新しいオーダーがまだオーダーを解読するNALユニットに従っているなら、NALユニットには、DONの同じ値があるかもしれません。 任意の部分オーダーがビデオ符号化プロフィールによって使用中に許容されているとき、例えば、コード化された絵のすべてのコード化された部分NAL単位がDONの同じ値を持つことができます。 その結果、順不同にDONの同じ値を持っているNALユニットは解読できます、そして、DONの異価を持っている2NALユニットは上で指定されたオーダーにおけるデコーダに通過されるべきです。 オーダーを解読するNALユニットの連続した2NALユニットにDONの異価があるとき、1番目のためのDONの値であり、増加されたオーダーSHOULDを解読することにおける、1の2番目のNALユニット単位でDONの値です。
An example of the decapsulation process to recover the NAL unit decoding order is given in section 7.
オーダーを解読するNALユニットを回復する被膜剥離術の過程に関する例はセクション7で出されます。
Informative note: Receivers should not expect that the absolute
difference of values of DON for two consecutive NAL units in the
NAL unit decoding order will be equal to one, even in error-free
transmission. An increment by one is not required, as at the time
of associating values of DON to NAL units, it may not be known
whether all NAL units are delivered to the receiver. For example,
a gateway may not forward coded slice NAL units of non-reference
pictures or SEI NAL units when there is a shortage of bit rate in
the network to which the packets are forwarded. In another
example, a live broadcast is interrupted by pre-encoded content,
such as commercials, from time to time. The first intra picture
of a pre-encoded clip is transmitted in advance to ensure that it
is readily available in the receiver. When transmitting the first
intra picture, the originator does not exactly know how many NAL
units will be encoded before the first intra picture of the pre-
encoded clip follows in decoding order. Thus, the values of DON
for the NAL units of the first intra picture of the pre-encoded
clip have to be estimated when they are transmitted, and gaps in
values of DON may occur.
有益な注意: 受信機は、オーダーを解読するNALユニットの連続した2NALユニットのためのDONの値の絶対違いが1つと等しくなると予想するはずがありません、エラーのないトランスミッションでさえ。 1の増分は必要ではありません、DONの値をNALユニットに関連づける時点ですべてのNALユニットを受信機に渡すかどうかが知られていないかもしれないように。パケットが送られるネットワークのビット伝送速度の不足があるとき、例えば、ゲートウェイはコード化された部分NAL単位の非参照の絵かSEI NALユニットを進めないかもしれません。 別の例では、生中継は時々あらかじめコード化されることによってコマーシャルなどのように満足していた状態で中断されます。 あらかじめコード化されたクリップの最初のイントラの絵は、あらかじめ、それが受信機で容易に利用可能であることを保証するために送られます。最初のイントラの絵を送るとき、創始者は、あらかじめコード化されたクリップの最初のイントラの絵がオーダーを解読する際に従う前にいくつのNALユニットがコード化されるかをまさに知りません。 それらが伝えられて、DONの値におけるギャップが起こるとき、したがって、あらかじめコード化されたクリップの最初のイントラの絵のNALユニット単位でDONの値は見積もられなければなりません。
Wenger, et al. Standards Track [Page 17] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[17ページ]。
5.6. Single NAL Unit Packet
5.6. 単一のNALユニットパケット
The single NAL unit packet defined here MUST contain only one NAL unit, of the types defined in [1]. This means that neither an aggregation packet nor a fragmentation unit can be used within a single NAL unit packet. A NAL unit stream composed by decapsulating single NAL unit packets in RTP sequence number order MUST conform to the NAL unit decoding order. The structure of the single NAL unit packet is shown in Figure 2.
ここで定義された単一のNALユニットパケットは[1]で定義されたタイプの1NAL単位だけを含まなければなりません。 これは、単一のNALユニットパケットの中で集合パケットも断片化ユニットも使用できないことを意味します。 NALユニットストリームは、オーダーを解読するRTP一連番号オーダーにおけるパケットが従わせなければならない単一のNAL単位からNALユニットをdecapsulatingすることによって、構成されました。 単一のNALユニットパケットの構造は図2で見せられます。
Informative note: The first byte of a NAL unit co-serves as the
RTP payload header.
有益な注意: NALユニットの最初のバイトは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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| Bytes 2..n of a Single NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|NRI| タイプ| | +-+-+-+-+-+-+-+-+ | | | | バイト2。n Single NALユニット| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. RTP payload format for single NAL unit packet
図2。 単一のNALユニットパケットのためのRTPペイロード形式
5.7. Aggregation Packets
5.7. 集合パケット
Aggregation packets are the NAL unit aggregation scheme of this payload specification. The scheme is introduced to reflect the dramatically different MTU sizes of two key target networks: wireline IP networks (with an MTU size that is often limited by the Ethernet MTU size; roughly 1500 bytes), and IP or non-IP (e.g., ITU-T H.324/M) based wireless communication systems with preferred transmission unit sizes of 254 bytes or less. To prevent media transcoding between the two worlds, and to avoid undesirable packetization overhead, a NAL unit aggregation scheme is introduced.
集合パケットはこのペイロード仕様のNALユニット集合計画です。 2つの主要な目標ネットワークの劇的に異なったMTUサイズを反映するために計画を導入します: ワイヤーラインIPネットワーク(イーサネットMTUサイズによってしばしばおよそ1500バイト制限されるMTUサイズがある)、および254バイト以下の都合のよいトランスミッションユニットサイズがあるIPか非IP(例えば、ITU-T H.324/M)のベースの無線通信システム。 2つの世界の間のメディアコード変換を防いで、望ましくないpacketizationオーバーヘッド、NALユニットを避けるために、集合計画を導入します。
Two types of aggregation packets are defined by this specification:
2つのタイプの集合パケットはこの仕様で定義されます:
o Single-time aggregation packet (STAP): aggregates NAL units with
identical NALU-time. Two types of STAPs are defined, one without
DON (STAP-A) and another including DON (STAP-B).
o ただ一つの時間集合パケット(STAP): 同じNALU-時間でNALユニットを集めます。 そして、STAPsの2つのタイプが定義される、ドンのいない1、(STAP-a)、別の包含ドン(STAP-B。)
o Multi-time aggregation packet (MTAP): aggregates NAL units with
potentially differing NALU-time. Two different MTAPs are defined,
differing in the length of the NAL unit timestamp offset.
o マルチ時間集合パケット(MTAP): 潜在的に異なったNALU-時間でNALユニットを集めます。 NALユニットタイムスタンプオフセットの長さにおいて異なって、2異なったMTAPsが定義されます。
Wenger, et al. Standards Track [Page 18] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[18ページ]。
The term NALU-time is defined as the value that the RTP timestamp would have if that NAL unit would be transported in its own RTP packet.
そのNALユニットがそれ自身のRTPパケットで輸送されるなら、用語NALU-時間はRTPタイムスタンプが持っている値と定義されます。
Each NAL unit to be carried in an aggregation packet is encapsulated in an aggregation unit. Please see below for the four different aggregation units and their characteristics.
それぞれの集合パケットで運ばれるべきNALユニットは集合単位で要約されます。 異なった4集合単位とそれらの特性に関して以下を見てください。
The structure of the RTP payload format for aggregation packets is presented in Figure 3.
集合パケットのためのRTPペイロード形式の構造は図3に提示されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| one or more aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|NRI| タイプ| | +-+-+-+-+-+-+-+-+ | | | | 複数の集合単位| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RTP payload format for aggregation packets
図3。 集合パケットのためのRTPペイロード形式
MTAPs and STAPs share the following packetization rules: The RTP timestamp MUST be set to the earliest of the NALU times of all the NAL units to be aggregated. The type field of the NAL unit type octet MUST be set to the appropriate value, as indicated in Table 4. The F bit MUST be cleared if all F bits of the aggregated NAL units are zero; otherwise, it MUST be set. The value of NRI MUST be the maximum of all the NAL units carried in the aggregation packet.
MTAPsとSTAPsは以下のpacketization規則を共有します: RTPタイムスタンプは、集められるためにはすべてのNALユニットの最も早いNALU倍のセットでなければなりません。 NALユニット型八重奏のタイプ分野を適切な値に設定しなければなりません、Table4にみられるように。 集められたNALユニットのすべてのFビットがゼロであるならFビットをきれいにしなければなりません。 さもなければ、それを設定しなければなりません。 値、NRI MUSTでは、集合パケットで運ばれたすべてのNALユニットの最大になってください。
Table 4. Type field for STAPs and MTAPs
4を見送ってください。 STAPsとMTAPsのために分野をタイプしてください。
Type Packet Timestamp offset DON related fields
field length (DON, DONB, DOND)
(in bits) present
--------------------------------------------------------
24 STAP-A 0 no
25 STAP-B 0 yes
26 MTAP16 16 yes
27 MTAP24 24 yes
Packet TimestampのオフセットDON関連分野フィールド長(ドン、DONB、DOND)(ビットの)が提示するタイプ-------------------------------------------------------- 24STAP-A0ノー25STAP-B0はい26MTAP16 16はい27のMTAP24 24はい
The marker bit in the RTP header is set to the value that the marker bit of the last NAL unit of the aggregated packet would have if it were transported in its own RTP packet.
それがそれ自身のRTPパケットで輸送されたなら、RTPヘッダーのマーカービットは集められたパケットの最後のNALユニットのマーカービットが持っている値に設定されます。
Wenger, et al. Standards Track [Page 19] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[19ページ]。
The payload of an aggregation packet consists of one or more aggregation units. See sections 5.7.1 and 5.7.2 for the four different types of aggregation units. An aggregation packet can carry as many aggregation units as necessary; however, the total amount of data in an aggregation packet obviously MUST fit into an IP packet, and the size SHOULD be chosen so that the resulting IP packet is smaller than the MTU size. An aggregation packet MUST NOT contain fragmentation units specified in section 5.8. Aggregation packets MUST NOT be nested; i.e., an aggregation packet MUST NOT contain another aggregation packet.
集合パケットのペイロードは複数の集合単位から成ります。 セクション5.7.1と5.7を見てください。.2 4つの異なったタイプの集合単位。 集合パケットは必要な多くの集合同じくらい単位として運ばれることができます。 しかしながら、結果として起こるIPパケットがそうである選ばれたそうがMTUサイズより小さかったなら、集合パケットのデータの総量は明らかにIPパケット、およびサイズSHOULDに収まらなければなりません。 集合パケットはセクション5.8で指定された断片化ユニットを含んではいけません。 集合パケットを入れ子にしてはいけません。 すなわち、集合パケットは別の集合パケットを含んではいけません。
5.7.1. Single-Time Aggregation Packet
5.7.1. ただ一つの時間集合パケット
Single-time aggregation packet (STAP) SHOULD be used whenever NAL units are aggregated that all share the same NALU-time. The payload of an STAP-A does not include DON and consists of at least one single-time aggregation unit, as presented in Figure 4. The payload of an STAP-B consists of a 16-bit unsigned decoding order number (DON) (in network byte order) followed by at least one single-time aggregation unit, as presented in Figure 5.
集合パケット(STAP)SHOULDをシングル調節してください。同NALU-時間を共有するNALユニットがすべて、集められるときはいつも、使用されてください。 STAP-Aのペイロードは、DONを含まないで、少なくとも1ただ一つの時間集合単位から成ります、図4に示されるように。 STAP-Bのペイロードは少なくとも1ただ一つの時間集合単位が支えた16ビットの無記名の解読注文番号(DON)(ネットワークバイトオーダーにおける)から成ります、図5に示されるように。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: |
+-+-+-+-+-+-+-+-+ |
| |
| single-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | +-+-+-+-+-+-+-+-+ | | | | ただ一つの時間集合単位| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Payload format for STAP-A
図4。 STAP-Aのための有効搭載量形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: decoding order number (DON) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| single-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 注文番号(DON)を解読します。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ただ一つの時間集合単位| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Payload format for STAP-B
図5。 STAP-Bのための有効搭載量形式
Wenger, et al. Standards Track [Page 20] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[20ページ]。
The DON field specifies the value of DON for the first NAL unit in an STAP-B in transmission order. For each successive NAL unit in appearance order in an STAP-B, the value of DON is equal to (the value of DON of the previous NAL unit in the STAP-B + 1) % 65536, in which '%' stands for the modulo operation.
DON分野はトランスミッション命令におけるSTAP-Bにおける最初のNALユニットにDONの値を指定します。 STAP-Bでの外観命令におけるそれぞれの連続したNALユニットに、DONの値は(STAP-B+1の前のNALユニットのDONの値)%65536と等しいです。('%'は%で法操作を表します)。
A single-time aggregation unit consists of 16-bit unsigned size information (in network byte order) that indicates the size of the following NAL unit in bytes (excluding these two octets, but including the NAL unit type octet of the NAL unit), followed by the NAL unit itself, including its NAL unit type byte. A single-time aggregation unit is byte aligned within the RTP payload, but it may not be aligned on a 32-bit word boundary. Figure 6 presents the structure of the single-time aggregation unit.
ただ一つの時間集合単位はNALユニット型バイトを含むNALユニット自体があとに続いたバイト(これらの2つの八重奏を除きますが、NALユニットのNALユニット型八重奏を含んでいる)で表現される以下のNALユニットのサイズを示す16ビットの無記名のサイズ情報(ネットワークバイトオーダーにおける)から成ります。 ただ一つの時間集合単位はRTPペイロードの中に並べられたバイトですが、それは32ビットの語境界で並べられないかもしれません。 図6はただ一つの時間集合単位の構造を提示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : NALユニットサイズ| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | NALユニット| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Structure for single-time aggregation unit
図6。 ただ一つの時間集合単位構造
Wenger, et al. Standards Track [Page 21] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[21ページ]。
Figure 7 presents an example of an RTP packet that contains an STAP- A. The STAP contains two single-time aggregation units, labeled as 1 and 2 in the figure.
図7は図の1と2としてラベルされたただ一つの時の2集合単位をSTAPが含むSTAP A.を含む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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-A NAL HDR | NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Data |
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAP-Aナル川HDR| NALU1サイズ| NALU1HDR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU1データ| : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NALU2サイズ| NALU2HDR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU2データ| : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. An example of an RTP packet including an STAP-A and two
single-time aggregation units
図7。 STAP-Aと2ただ一つの時間集合単位を含むRTPパケットに関する例
Wenger, et al. Standards Track [Page 22] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[22ページ]。
Figure 8 presents an example of an RTP packet that contains an STAP- B. The STAP contains two single-time aggregation units, labeled as 1 and 2 in the figure.
エイト環は図の1と2としてラベルされたただ一つの時の2集合単位をSTAPが含むSTAP B.を含む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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-B NAL HDR | DON | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR | NALU 1 Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |STAP-Bナル川HDR| 氏| NALU1サイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU1サイズ| NALU1HDR| NALU1データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NALU2サイズ| NALU2HDR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU2データ| : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. An example of an RTP packet including an STAP-B and two
single-time aggregation units
エイト環。 STAP-Bと2ただ一つの時間集合単位を含むRTPパケットに関する例
5.7.2. Multi-Time Aggregation Packets (MTAPs)
5.7.2. マルチ時間集合パケット(MTAPs)
The NAL unit payload of MTAPs consists of a 16-bit unsigned decoding order number base (DONB) (in network byte order) and one or more multi-time aggregation units, as presented in Figure 9. DONB MUST contain the value of DON for the first NAL unit in the NAL unit decoding order among the NAL units of the MTAP.
MTAPsのNALユニットペイロードは16ビットの無記名の解読注文番号ベース(DONB)(ネットワークバイトオーダーにおける)と1マルチ時間集合単位以上から成ります、図9に示されるように。 DONB MUSTはMTAPのNALユニットでオーダーを解読するNALユニットにおける最初のNALユニット単位でDONの値を含んでいます。
Informative note: The first NAL unit in the NAL unit decoding
order is not necessarily the first NAL unit in the order in which
the NAL units are encapsulated in an MTAP.
有益な注意: オーダーを解読するNALユニットにおける最初のNALユニットは必ずNALユニットがMTAPで要約されるオーダーで最初のNALユニットであるというわけではありません。
Wenger, et al. Standards Track [Page 23] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[23ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: decoding order number base | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| multi-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : オーダーナンバーベースを解読します。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | マルチ時間集合単位| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. NAL unit payload format for MTAPs
図9。 MTAPsのためのNALユニットペイロード形式
Two different multi-time aggregation units are defined in this specification. Both of them consist of 16 bits unsigned size information of the following NAL unit (in network byte order), an 8- bit unsigned decoding order number difference (DOND), and n bits (in network byte order) of timestamp offset (TS offset) for this NAL unit, whereby n can be 16 or 24. The choice between the different MTAP types (MTAP16 and MTAP24) is application dependent: the larger the timestamp offset is, the higher the flexibility of the MTAP, but the overhead is also higher.
異なった2マルチ時間集合単位はこの仕様に基づき定義されます。 それらの両方が以下のNALユニット(ネットワークバイトオーダーにおける)の16ビットの無記名のサイズ情報から成って、8ビット、無記名の解読している注文番号差(DOND)、およびnビット(ネットワークバイトオーダーにおける)のタイムスタンプはこのNALユニットのために相殺します(TSは相殺します)。(nはそれによる16か24であるかもしれません)。 異なったMTAPタイプ(MTAP16とMTAP24)の選択はアプリケーションに依存しています: タイムスタンプオフセットが大きければ大きいほど、MTAPの柔軟性が、より高いのですが、また、オーバーヘッドも、より高いです。
The structure of the multi-time aggregation units for MTAP16 and MTAP24 are presented in Figures 10 and 11, respectively. The starting or ending position of an aggregation unit within a packet is NOT REQUIRED to be on a 32-bit word boundary. The DON of the following NAL unit is equal to (DONB + DOND) % 65536, in which % denotes the modulo operation. This memo does not specify how the NAL units within an MTAP are ordered, but, in most cases, NAL unit decoding order SHOULD be used.
それぞれMTAP16とMTAP24のための集合単位が図10と11に示されるマルチ時の構造。 パケットの中の集合単位の始めの、または、終わりの位置は32ビットの語境界にあるNOT REQUIREDです。 以下のNALユニットのDONは(DONB+DOND)%65536と等しいです。(%は%で法操作を指示します)。 このメモはどうMTAPの中のNALユニットを注文するかを指定しませんが、多くの場合、NALユニット解読はSHOULDを注文します。使用されます。
The timestamp offset field MUST be set to a value equal to the value of the following formula: If the NALU-time is larger than or equal to the RTP timestamp of the packet, then the timestamp offset equals (the NALU-time of the NAL unit - the RTP timestamp of the packet). If the NALU-time is smaller than the RTP timestamp of the packet, then the timestamp offset is equal to the NALU-time + (2^32 - the RTP timestamp of the packet).
以下の公式の値と等しい値にタイムスタンプオフセット分野を設定しなければなりません: NALU-時間がパケットに関する、よりRTPタイムスタンプ以上であるなら、タイムスタンプは同輩を相殺しました(NALユニットのNALU-時間--パケットに関するRTPタイムスタンプ)。 NALU-時間がパケットに関するRTPタイムスタンプより小さいなら、タイムスタンプオフセットはNALU-時間+(2^32--パケットに関するRTPタイムスタンプ)と等しいです。
Wenger, et al. Standards Track [Page 24] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[24ページ]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : NALユニットサイズ| DOND| TSは相殺します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSは相殺します。| | +++++++++NALユニット| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Multi-time aggregation unit for MTAP16
図10。 MTAP16のためのマルチ時間集合単位
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NALU unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| NAL unit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : NALUユニットサイズ| DOND| TSは相殺します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSは相殺します。| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NALユニット| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11. Multi-time aggregation unit for MTAP24
図11。 MTAP24のためのマルチ時間集合単位
For the "earliest" multi-time aggregation unit in an MTAP the timestamp offset MUST be zero. Hence, the RTP timestamp of the MTAP itself is identical to the earliest NALU-time.
MTAPにおける「最も早い」マルチ時間集合単位のために、タイムスタンプオフセットはゼロでなければなりません。 したがって、MTAP自身のRTPタイムスタンプはNALU-時間最も前半と同じです。
Informative note: The "earliest" multi-time aggregation unit is
the one that would have the smallest extended RTP timestamp among
all the aggregation units of an MTAP if the aggregation units were
encapsulated in single NAL unit packets. An extended timestamp is
a timestamp that has more than 32 bits and is capable of counting
the wraparound of the timestamp field, thus enabling one to
determine the smallest value if the timestamp wraps. Such an
"earliest" aggregation unit may not be the first one in the order
in which the aggregation units are encapsulated in an MTAP. The
"earliest" NAL unit need not be the same as the first NAL unit in
the NAL unit decoding order either.
有益な注意: 「最も早い」マルチ時間集合単位は集合単位が単一のNALユニットパケットで要約されるならMTAPのすべての集合単位に最も小さい拡張RTPタイムスタンプを持っているものです。 拡張タイムスタンプは、32ビット以上を持っているタイムスタンプであり、タイムスタンプ分野の巻きつけて着るドレスを数えることができます、その結果、タイムスタンプ機密であるなら人が最も小さい値を決定するのを可能にします。 そのような「最も早い」集合単位は集合単位がMTAPで要約されるオーダーで最初のものでないかもしれません。 「最も早い」NALユニットはNALユニットでオーダーを解読するのにおいて最初のNALユニットと同じである必要はありません。
Wenger, et al. Standards Track [Page 25] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[25ページ]。
Figure 12 presents an example of an RTP packet that contains a multi-time aggregation packet of type MTAP16 that contains two multi-time aggregation units, labeled as 1 and 2 in the figure.
図12は図の1と2としてラベルされた2マルチ時間集合単位を含むタイプMTAP16のマルチ時間集合パケットを含む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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP16 NAL HDR | decoding order number base | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 DOND | NALU 1 TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 HDR | NALU 1 DATA |
+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 SIZE | NALU 2 DOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 TS offset | NALU 2 HDR | NALU 2 DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MTAP16ナル川HDR| オーダーナンバーベースを解読します。| NALU1サイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU1サイズ| NALU1DOND| NALU1TSは相殺します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU1HDR| NALU1データ| +-+-+-+-+-+-+-+-+ + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NALU2サイズ| NALU2DOND| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU2TSは相殺します。| NALU2HDR| NALU2データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12. An RTP packet including a multi-time aggregation
packet of type MTAP16 and two multi-time aggregation
units
図12。 タイプMTAP16と2マルチ時間集合単位のマルチ時間集合パケットを含むRTPパケット
Wenger, et al. Standards Track [Page 26] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[26ページ]。
Figure 13 presents an example of an RTP packet that contains a multi-time aggregation packet of type MTAP24 that contains two multi-time aggregation units, labeled as 1 and 2 in the figure.
図13は図の1と2としてラベルされた2マルチ時間集合単位を含むタイプMTAP24のマルチ時間集合パケットを含む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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP24 NAL HDR | decoding order number base | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 DOND | NALU 1 TS offs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NALU 1 TS offs | NALU 1 HDR | NALU 1 DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 SIZE | NALU 2 DOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 TS offset | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 DATA |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTPヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MTAP24ナル川HDR| オーダーナンバーベースを解読します。| NALU1サイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU1サイズ| NALU1DOND| NALU1TS offs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NALU1TS offs| NALU1HDR| NALU1データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | NALU2サイズ| NALU2DOND| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU2TSは相殺します。| NALU2HDR| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NALU2データ| : : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13. An RTP packet including a multi-time aggregation
packet of type MTAP24 and two multi-time aggregation
units
図13。 タイプMTAP24と2マルチ時間集合単位のマルチ時間集合パケットを含むRTPパケット
5.8. Fragmentation Units (FUs)
5.8. 断片化ユニット(FUs)
This payload type allows fragmenting a NAL unit into several RTP packets. Doing so on the application layer instead of relying on lower layer fragmentation (e.g., by IP) has the following advantages:
このペイロードタイプはいくつかのRTPパケットにNALユニットを断片化させます。 などに下層断片化(例えば、IPによる)に依存することの代わりに応用層をするのにおいて、以下の利点があります:
o The payload format is capable of transporting NAL units bigger
than 64 kbytes over an IPv4 network that may be present in pre-
recorded video, particularly in High Definition formats (there is
a limit of the number of slices per picture, which results in a
limit of NAL units per picture, which may result in big NAL
units).
o ペイロード形式はあらかじめ記録されたビデオで存在するかもしれないIPv4ネットワークの上で64キロバイトより何ユニットも大きいNALを輸送できます、特にHigh Definition形式で(1 1大きいNAL単位をもたらすかもしれない絵あたりのNALユニットの限界をもたらす絵あたりの部分の数の限界があります)。
o The fragmentation mechanism allows fragmenting a single picture
and applying generic forward error correction as described in
section 12.5.
o 断片化メカニズムで、セクション12.5で説明されるようにただ一つの絵を断片化して、一般的な前進型誤信号訂正を適用します。
Wenger, et al. Standards Track [Page 27] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[27ページ]。
Fragmentation is defined only for a single NAL unit and not for any aggregation packets. A fragment of a NAL unit consists of an integer number of consecutive octets of that NAL unit. Each octet of the NAL unit MUST be part of exactly one fragment of that NAL unit. Fragments of the same NAL unit MUST be sent in consecutive order with ascending RTP sequence numbers (with no other RTP packets within the same RTP packet stream being sent between the first and last fragment). Similarly, a NAL unit MUST be reassembled in RTP sequence number order.
断片化はどんな集合パケットのためにも定義されるのではなく、単一のNAL単位のためだけに定義されます。 NALユニットの断片はそのNALユニットの連続した八重奏の整数から成ります。 NALユニットの各八重奏はまさにそのNALユニットの1個の断片の一部であるに違いありません。 RTP一連番号を昇る連続した注文で同じNALユニットの断片を送らなければなりません(1番目と最後の断片の間に送られる同じRTPパケットの流れの中の他のRTPパケットなしで)。 同様に、RTP一連番号オーダーでNALユニットを組み立て直さなければなりません。
When a NAL unit is fragmented and conveyed within fragmentation units (FUs), it is referred to as a fragmented NAL unit. STAPs and MTAPs MUST NOT be fragmented. FUs MUST NOT be nested; i.e., an FU MUST NOT contain another FU.
NALユニットが断片化ユニット(FUs)の中に断片化されて、運ばれるとき、それは断片化しているNALユニットと呼ばれます。 STAPsとMTAPsを断片化してはいけません。 FUsを入れ子にしてはいけません。 すなわち、フーは別のFUを含んではいけません。
The RTP timestamp of an RTP packet carrying an FU is set to the NALU time of the fragmented NAL unit.
FUを運ぶRTPパケットに関するRTPタイムスタンプは断片化しているNALユニットのNALU時間に設定されます。
Figure 14 presents the RTP payload format for FU-As. An FU-A consists of a fragmentation unit indicator of one octet, a fragmentation unit header of one octet, and a fragmentation unit payload.
図14がRTPペイロード形式を提示する、FU、- FU-Aは1つの八重奏の断片化ユニットインディケータ、1つの八重奏の断片化ユニットヘッダー、および断片化ユニットペイロードから成ります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FUインディケータ| FUヘッダー| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | FUペイロード| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14. RTP payload format for FU-A
図14。 FU-AのためのRTPペイロード形式
Wenger, et al. Standards Track [Page 28] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[28ページ]。
Figure 15 presents the RTP payload format for FU-Bs. An FU-B consists of a fragmentation unit indicator of one octet, a fragmentation unit header of one octet, a decoding order number (DON) (in network byte order), and a fragmentation unit payload. In other words, the structure of FU-B is the same as the structure of FU-A, except for the additional DON field.
図15はFU-BsのためにRTPペイロード形式を提示します。 FU-Bは1つの八重奏の断片化ユニットインディケータ、1つの八重奏の断片化ユニットヘッダー、解読注文番号(DON)(ネットワークバイトオーダーにおける)、および断片化ユニットペイロードから成ります。 言い換えれば、FU-Bの構造はFU-Aの構造と同じです、追加DON分野を除いて。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | DON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FUインディケータ| FUヘッダー| 氏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | FUペイロード| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15. RTP payload format for FU-B
図15。 FU-BのためのRTPペイロード形式
NAL unit type FU-B MUST be used in the interleaved packetization mode for the first fragmentation unit of a fragmented NAL unit. NAL unit type FU-B MUST NOT be used in any other case. In other words, in the interleaved packetization mode, each NALU that is fragmented has an FU-B as the first fragment, followed by one or more FU-A fragments.
NALユニットは中古のコネが断片化しているNALユニットの最初の断片化ユニット単位ではさみ込まれたpacketizationモードであったに違いないならフー-Bをタイプします。 タイプフー-Bを使用してはいけないいかなる他のもケースに入れるNALユニット。 言い換えれば、はさみ込まれたpacketizationモードで、断片化される各NALUは1個以上のFU-A断片が支えた最初の断片としてFU-Bを持っています。
The FU indicator octet has the following format:
FUインディケータ八重奏には、以下の形式があります:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
+---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |F|NRI| タイプ| +---------------+
Values equal to 28 and 29 in the Type field of the FU indicator octet identify an FU-A and an FU-B, respectively. The use of the F bit is described in section 5.3. The value of the NRI field MUST be set according to the value of the NRI field in the fragmented NAL unit.
FUインディケータ八重奏のType分野の28と29と等しい値はそれぞれFU-AとFU-Bを特定します。 Fビットの使用はセクション5.3で説明されます。 断片化しているNALユニットのNRI分野の値に従って、NRI分野の値を設定しなければなりません。
The FU header has the following format:
FUヘッダーには、以下の形式があります:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
+---------------+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ |S|E|R| タイプ| +---------------+
Wenger, et al. Standards Track [Page 29] RFC 3984 RTP Payload Format for H.264 Video February 2005
ウェンガー、他 規格はビデオ2005年2月にH.264のためにRFC3984RTP有効搭載量形式を追跡します[29ページ]。
S: 1 bit
When set to one, the Start bit indicates the start of a fragmented
NAL unit. When the following FU payload is not the start of a
fragmented NAL unit payload, the Start bit is set to zero.
S: 1ビットのWhenは1つにセットして、Startビットは断片化しているNALユニットの始まりを示します。 以下のFUペイロードが断片化しているNALユニットペイロードの始まりでないときに、Startビットはゼロに設定されます。
E: 1 bit
When set to one, the End bit indicates the end of a fragmented NAL
unit, i.e., the last byte of the payload is also the last byte of
the fragmented NAL unit. When the following FU payload is not the
last fragment of a fragmented NAL unit, the End bit is set to
zero.
E: 1ビットのWhenは1つにセットしました、Endビットが断片化しているNALユニットの端を示します、すなわち、また、ペイロードの最後のバイトが断片化しているNALユニットの最後のバイトです。 以下のFUペイロードが断片化しているNALユニットの最後の断片でないときに、Endビットはゼロに設定されます。
R: 1 bit
The Reserved bit MUST be equal to 0 and MUST be ignored by the
receiver.
R: Reservedビットを1ビット、0と等しくなければならなく、受信機で無視しなければなりません。
Type: 5 bits
The NAL unit payload type as defined in table 7-1 of [1].
以下をタイプしてください。 5ビット、NALユニットペイロードは[1]のテーブル7-1で定義されるようにタイプします。
The value of DON in FU-Bs is selected as described in section 5.5.
FU-BsのDONの値はセクション5.5で説明されるように選択されます。
Informative note: The DON field in FU-Bs allows gateways to
fragment NAL units to FU-Bs without organizing the incoming NAL
units to the NAL unit decoding order.
有益な注意: FU-BsのDON分野で、オーダーを解読する入って来るNALユニットからNALユニットを組織化しないで、ゲートウェイはNALユニットをFU-Bsに断片化できます。
A fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the Start bit and End bit MUST NOT both be set to one in the same FU header.
1FUで断片化しているNALユニットを送ってはいけません。 ともにすなわち、StartビットとEndビットを同じFUヘッダーの1つに設定してはいけません。
一覧
スポンサーリンク
