Internet Engineering Task Force (IETF) S. Wenger
Request for Comments: 6190 Independent
Category: Standards Track Y.-K. Wang
ISSN: 2070-1721 Huawei Technologies
T. Schierl
Fraunhofer HHI
A. Eleftheriadis
Vidyo
May 2011
RTP Payload Format for Scalable Video Coding
Abstract
抽象
This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.
このメモは、ISO / IEC国際規格14496-10の改正3に技術的に同一であるITU-T勧告H.264の付属書Gで定義されるようなスケーラブルビデオ用のRTPペイロードフォーマットコーディング（SVC）を記述する。 RTPペイロードフォーマットは、複数のRTPパケット内のNALユニットの各RTPパケットのペイロード内の1つまたは複数のネットワーク抽象化層（NAL）ユニットパケット、ならびに断片化を可能にします。また、単一上SVCストリームの送信、ならびに複数のRTPセッションをサポートします。ペイロード・フォーマットは、新しいメディアサブタイプ名「H264-SVC」を定義するが、それでもベース層ので、RFC 6184に下位互換性があり、それ自身のRTPストリーム内にカプセル化された場合、H.264メディアサブタイプ名（「H264」）を使用する必要がありますおよびRFC 6184.ペイロード形式で指定されたパケット化の方法は、とりわけ、ワイドテレビ会議での適用、インターネットのビデオストリーミング、および高ビットレートエンターテインメント品質のビデオを持っています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6190.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6190で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................5
1.1. The SVC Codec ..............................................6
1.1.1. Overview ............................................6
1.1.2. Parameter Sets ......................................8
1.1.3. NAL Unit Header .....................................9
1.2. Overview of the Payload Format ............................12
1.2.1. Design Principles ..................................12
1.2.2. Transmission Modes and Packetization Modes .........13
1.2.3. New Payload Structures .............................15
2. Conventions ....................................................16
3. Definitions and Abbreviations ..................................16
3.1. Definitions ...............................................16
3.1.1. Definitions from the SVC Specification .............16
3.1.2. Definitions Specific to This Memo ..................18
3.2. Abbreviations .............................................22
4. RTP Payload Format .............................................23
4.1. RTP Header Usage ..........................................23
4.2. NAL Unit Extension and Header Usage .......................23
4.2.1. NAL Unit Extension .................................23
4.2.2. NAL Unit Header Usage ..............................24
4.3. Payload Structures ........................................25
4.4. Transmission Modes ........................................28
4.5. Packetization Modes .......................................28
4.5.1. Packetization Modes for Single-Session
Transmission .......................................28
4.5.2. Packetization Modes for Multi-Session
Transmission .......................................29
4.6. Single NAL Unit Packets ...................................32
4.7. Aggregation Packets .......................................33
4.7.1. Non-Interleaved Multi-Time Aggregation
Packets (NI-MTAPs) .................................33
4.8. Fragmentation Units (FUs) .................................35
4.9. Payload Content Scalability Information (PACSI) NAL Unit ..35
4.10. Empty NAL unit ...........................................43
4.11. Decoding Order Number (DON) ..............................43
4.11.1. Cross-Session DON (CS-DON) for
Multi-Session Transmission ........................43
5. Packetization Rules ............................................45
5.1. Packetization Rules for Single-Session Transmission .......45
5.2. Packetization Rules for Multi-Session Transmission ........46
5.2.1. NI-T/NI-TC Packetization Rules .....................47
5.2.2. NI-C/NI-TC Packetization Rules .....................49
5.2.3. I-C Packetization Rules ............................50
5.2.4. Packetization Rules for Non-VCL NAL Units ..........50
5.2.5. Packetization Rules for Prefix NAL Units ...........51
6. De-Packetization Process .......................................51
6.1. De-Packetization Process for Single-Session Transmission ..51
6.2. De-Packetization Process for Multi-Session Transmission ...51
6.2.1. Decoding Order Recovery for the NI-T and
NI-TC Modes ........................................52
6.2.1.1. Informative Algorithm for NI-T
Decoding Order Recovery within
an Access Unit ............................55
6.2.2. Decoding Order Recovery for the NI-C,
NI-TC, and I-C Modes ...............................57
7. Payload Format Parameters ......................................59
7.1. Media Type Registration ...................................60
7.2. SDP Parameters ............................................75
7.2.1. Mapping of Payload Type Parameters to SDP ..........75
7.2.2. Usage with the SDP Offer/Answer Model ..............76
7.2.3. Dependency Signaling in Multi-Session
Transmission .......................................84
7.2.4. Usage in Declarative Session Descriptions ..........85
7.3. Examples ..................................................86
7.3.1. Example for Offering a Single SVC Session ..........86
7.3.2. Example for Offering a Single SVC Session Using
scalable-layer-id ..................................87
7.3.3. Example for Offering Multiple Sessions in MST ......87
7.3.4. Example for Offering Multiple Sessions in
MST Including Operation with Answerer Using
scalable-layer-id ..................................89
7.3.5. Example for Negotiating an SVC Stream with
a Constrained Base Layer in SST ....................90
7.4. Parameter Set Considerations ..............................91
8. Security Considerations ........................................91
9. Congestion Control .............................................92
10. IANA Considerations ...........................................93
11. Informative Appendix: Application Examples ....................93
11.1. Introduction .............................................93
11.2. Layered Multicast ........................................93
11.3. Streaming ................................................94
11.4. Videoconferencing (Unicast to MANE, Unicast to
Endpoints) ...............................................95
11.5. Mobile TV (Multicast to MANE, Unicast to Endpoint) .......96
12. Acknowledgements ..............................................97
13. References ....................................................97
13.1. Normative References .....................................97
13.2. Informative References ...................................98
This memo specifies an RTP [RFC3550] payload format for the Scalable Video Coding (SVC) extension of the H.264/AVC video coding standard. SVC is specified in Amendment 3 to ISO/IEC 14496 Part 10 [ISO/IEC14496-10] and equivalently in Annex G of ITU-T Rec. H.264 [H.264]. In this memo, unless explicitly stated otherwise, "H.264/AVC" refers to the specification of [H.264] excluding Annex G.
このメモは、符号化規格H.264 / AVCビデオのスケーラブルビデオ符号化（SVC）拡張のためにRTP [RFC3550]ペイロードフォーマットを指定します。 SVCは、ITU-T勧告の付属書Gに等価ISO / IEC 14496パート10 [ISO / IEC14496-10]に修正3で指定されています。 H.264 [H.264]。特に明記しない限り、このメモでは、「H.264 / AVC」は、[264]を除く付属書Gの仕様を指し
SVC covers the entire application range of H.264/AVC, from low-bitrate mobile applications, to High-Definition Television (HDTV) broadcasting, and even Digital Cinema that requires nearly lossless coding and hundreds of megabits per second. The scalability features that SVC adds to H.264/AVC enable several system-level functionalities related to the ability of a system to adapt the signal to different system conditions with no or minimal processing. The adaptation relates both to the capabilities of potentially heterogeneous receivers (differing in screen resolution, processing speed, etc.), and to differing or time-varying network conditions. The adaptation can be performed at the source, the destination, or in intermediate media-aware network elements (MANEs). The payload format specified in this memo exposes these system-level functionalities so that system designers can take direct advantage of these features.
SVCは、ほぼロスレス符号化とメガビット毎秒数百人を必要とする低ビットレートのモバイルアプリケーションから、高精細テレビ（HDTV）放送、さらにはデジタルシネマへのH.264 / AVCのアプリケーション全体の範囲をカバーしています。 SVCは、H.264 / AVCに追加スケーラビリティ機能がないかまたは最小限の処理と異なるシステム条件に信号を適応させるシステムの能力に関連するいくつかのシステムレベルの機能を有効にします。適応は、及び異なる又は時間的に変化するネットワーク条件に（画面解像度、処理速度、等の異なる）潜在的に異種の受信機の能力の両方に関する。適応は、ソース、または中間メディアアウェアネットワーク要素（マネス）で先に行うことができます。システム設計者は、これらの機能を直接活用することができるように、このメモで指定されたペイロードフォーマットは、これらのシステムレベルの機能を公開します。
Informative note: Since SVC streams contain, by design, a sub-stream that is compliant with H.264/AVC, it is trivial for a MANE to filter the stream so that all SVC-specific information is removed. This memo, in fact, defines a media type parameter (sprop-avc-ready, Section 7.2) that indicates whether or not the stream can be converted to one compliant with [RFC6184] by eliminating RTP packets, and rewriting RTP Control Protocol (RTCP) to match the changes to the RTP packet stream as specified in Section 7 of [RFC3550].
有益注：SVCストリームが含まれているので、すべてのSVC固有の情報が削除されるように、MANEストリームをフィルタリングするために、設計により、H.264 / AVCに準拠したサブストリームは、それが自明です。このメモは、実際には、RTCPストリームは（RTPパケットを除去することによって、[RFC6184]に準拠したものに変換され、RTP制御プロトコルを書き換えることができるか否かを示すメディアタイプのパラメータ（のsprop-AVC対応、セクション7.2）を定義します[RFC3550]のセクション7で指定されるように）RTPパケットストリームへの変更を一致させます。
This memo defines two basic modes for transmission of SVC data, single-session transmission (SST) and multi-session transmission (MST). In SST, a single RTP session is used for the transmission of all scalability layers comprising an SVC bitstream; in MST, the scalability layers are transported on different RTP sessions. In SST, packetization is a straightforward extension of [RFC6184]. For MST, four different modes are defined in this memo. They differ on whether or not they allow interleaving, i.e., transmitting Network Abstraction Layer (NAL) units in an order different than the decoding order, and by the technique used to effect inter-session NAL unit decoding order recovery. Decoding order recovery is performed using either inter-session timestamp alignment [RFC3550] or cross-session decoding order numbers (CS-DONs). One of the MST modes supports both decoding order recovery techniques, so that receivers can select their preferred technique. More details can be found in Section 1.2.2.
このメモは、SVCデータを、シングルセッション送信（SST）とマルチセッション送信（MST）の送信のための2つの基本モードを定義しています。 SSTでは、単一のRTPセッションは、SVCビットストリームを含む全てのスケーラビリティレイヤの送信のために使用されます。 MSTには、スケーラビリティ層が異なるRTPセッションに輸送されます。 SSTにおいて、パケットは、[RFC6184]の簡単な拡張です。 MSTのために、4つの異なるモードは、このメモで定義されています。彼らは、復号化順序とは異なる順序でネットワーク抽象化層（NAL）ユニットを送信する、すなわち、インターリーブ許可か否か異なり、インターセッションNALユニットの復号化順序の回復を達成するために使用される技術によります。復号化順序の回復は、間、セッションタイムスタンプアライメント[RFC3550]またはクロスセッション復号順序番号（CS-DONS）のいずれかを用いて行われます。受信機は彼らの好適な技術を選択することができるように、MSTモードの一つは、両方の復号順序回復技術をサポートしています。詳細は、セクション1.2.2に記載されています。
This memo further defines three new NAL unit types. The first type is the payload content scalability information (PACSI) NAL unit, which is used to provide an informative summary of the scalability information of the data contained in an RTP packet, as well as ancillary data (e.g., CS-DON values). The second and third new NAL unit types are the empty NAL unit and the non-interleaved multi-time aggregation packet (NI-MTAP) NAL unit. The empty NAL unit is used to ensure inter-session timestamp alignment required for decoding order recovery in MST. The NI-MTAP is used as a new payload structure allowing the grouping of NAL units of different time instances in decoding order. More details about the new packet structures can be found in Section 1.2.3.
このメモは、さらに3つの新しいNALユニットのタイプを定義します。第一のタイプは、RTPパケットに含まれるデータのスケーラビリティ情報の有益な要約、並びに補助データ（例えば、CS-DON値）を提供するために使用されるペイロードコンテンツスケーラビリティ情報（PACSI）NALユニットです。第二及び第三の新しいNALユニットタイプは空NALユニットと非インターリーブマルチタイム集約パケット（NI-MTAP）NALユニットです。空のNALユニットは、MSTにおける復号順序回復のために必要な間、セッションタイムスタンプのアライメントを確実にするために使用されます。 NI-MTAPは、復号順序において異なる時間インスタンスのNALユニットのグループ化を可能にする新しいペイロード構造として使用されます。新しいパケット構造についての詳細は、セクション1.2.3に記載されています。
This memo also defines the signaling support for SVC transport over RTP, including a new media subtype name (H264-SVC).
また、このメモは新しいメディアサブタイプ名（H264-SVC）を含むRTPオーバーSVCの輸送のためのシグナリングをサポートし、定義されています。
A non-normative overview of the SVC codec and the payload is given in the remainder of this section.
SVCコーデックおよびペイロードの非規範的な概要は、このセクションの残りの部分に示されています。
SVC defines a coded video representation in which a given bitstream offers representations of the source material at different levels of fidelity (hence the term "scalable"). Scalable video coding bitstreams, or scalable bitstreams, are constructed in a pyramidal fashion: the coding process creates bitstream components that improve the fidelity of hierarchically lower components.
SVCは、与えられたビットストリームが（従って、用語「スケーラブル」）忠実度の異なるレベルで原料の表現を提供する符号化された映像表現を定義します。ビットストリームをスケーラブルビデオコーディングまたはスケーラブルビットストリームは、ピラミッド方式で構築される：符号化プロセスは、階層的に下位コンポーネントの忠実度を改善するビットストリーム要素を作成します。
The fidelity dimensions offered by SVC are spatial (picture size), quality (or Signal-to-Noise Ratio (SNR)), and temporal (pictures per second). Bitstream components associated with a given level of spatial, quality, and temporal fidelity are identified using corresponding parameters in the bitstream: dependency_id, quality_id, and temporal_id (see also Section 1.1.3). The fidelity identifiers have integer values, where higher values designate components that are higher in the hierarchy. It is noted that SVC offers significant flexibility in terms of how an encoder may choose to structure the dependencies between the various components. Decoding of a particular component requires the availability of all the components it depends upon, either directly, or indirectly. An operation point of an SVC bitstream consists of the bitstream components required to be able to decode a particular dependency_id, quality_id, and temporal_id combination.
SVCが提供する忠実度の大きさは、空間（画像サイズ）、品質（または信号対雑音比（SNR））、および時間（毎秒画像）です。空間、品質、および時間的忠実度の所定のレベルに関連付けられたビットストリーム成分は、ビットストリームに対応するパラメータを用いて同定される：のdependency_id、quality_id、およびtemporal_idを（セクション1.1.3を参照します）。忠実度の識別子は、より高い値は、階層の高い成分を指定する整数値を有します。 SVCエンコーダは、さまざまなコンポーネント間の依存関係を構築することもできます方法の面で大幅な柔軟性を提供することを指摘しています。特定の構成要素の復号化は、直接的、または間接的に、それが依存するすべてのコンポーネントの可用性を必要とします。 SVCビットストリームの動作点は、特定のdependency_id、quality_id、およびtemporal_id組み合わせをデコードすることができるように必要なビットストリーム要素から構成されています。
The term "layer" is used in various contexts in this memo. For example, in the terms "Video Coding Layer" and "Network Abstraction Layer" it refers to conceptual organization levels. When referring to bitstream syntax elements such as block layer or macroblock layer, it refers to hierarchical bitstream structure levels. When used in the context of bitstream scalability, e.g., "AVC base layer", it refers to a level of representation fidelity of the source signal with a specific set of NAL units included. The correct interpretation is supported by providing the appropriate context.
「層」という用語は、このメモでは、様々な場面で使用されています。例えば、用語「ビデオ符号化レイヤ」と「ネットワーク抽象化レイヤ」には概念的な組織レベルを指します。このようなブロック層またはマクロブロック層としてのシンタックス要素をビットストリームに言及する場合、それは、階層ビットストリーム構造レベルを指します。ビットストリームのスケーラビリティの文脈で使用される場合、例えば、「AVCベース層」は、そのNALユニットの特定のセットが含まれてソース信号の表現の忠実度のレベルを指します。正しい解釈は適切なコンテキストを提供することで、サポートされています。
SVC maintains the bitstream organization introduced in H.264/AVC. Specifically, all bitstream components are encapsulated in Network Abstraction Layer (NAL) units, which are organized as Access Units (AUs). An AU is associated with a single sampling instance in time. A subset of the NAL unit types correspond to the Video Coding Layer (VCL), and contain the coded picture data associated with the source content. Non-VCL NAL units carry ancillary data that may be necessary for decoding (e.g., parameter sets as explained below) or that facilitate certain system operations but are not needed by the decoding process itself. Coded picture data at the various fidelity dimensions are organized in slices. Within one AU, a coded picture of an operation point consists of all the coded slices required for decoding up to the particular combination of dependency_id and quality_id values at the time instance corresponding to the AU.
SVCは、H.264 / AVCで導入されたビットストリームの組織を維持しています。具体的には、すべてのビットストリーム要素は、アクセスユニット（AUS）として編成されているネットワーク抽象化層（NAL）ユニット内にカプセル化されています。 AUは、時間内に単一のサンプリングインスタンスに関連付けられています。 NALユニット・タイプのサブセットは、ビデオ符号化レイヤ（VCL）に対応し、ソース・コンテンツに関連付けられた符号化画像データを含みます。非VCL NALユニットは、（以下に説明するように、例えば、パラメータセット）復号化に必要であり得る補助データを運ぶか、または特定のシステムの操作を容易にするが、復号プロセス自体によって必要とされません。様々な忠実度の大きさで符号化された画像データは、スライスに編成されています。 1 AU内に、動作点の符号化ピクチャは、AUに対応する時間インスタンスでのdependency_id及びquality_id値の特定の組み合わせにまで復号するために必要なすべての符号化されたスライスから成ります。
It is noted that the concept of temporal scalability is already present in H.264/AVC, as profiles defined in Annex A of [H.264] already support it. Specifically, in H.264/AVC, the concept of sub-sequences has been introduced to allow optional use of temporal layers through Supplemental Enhancement Information (SEI) messages. SVC extends this approach by exposing the temporal scalability information using the temporal_id parameter, alongside (and unified with) the dependency_id and quality_id values that are used for spatial and quality scalability, respectively. For coded picture data defined in Annex G of [H.264], this is accomplished by using a new type of NAL unit, namely, coded slice in scalable extension NAL unit (type 20), where the fidelity parameters are part of its header. For coded picture data that follow H.264/AVC, and to ensure compatibility with existing H.264/AVC decoders, another new type of NAL unit, namely, prefix NAL unit (type 14), has been defined to carry this header information. SVC additionally specifies a third new type of NAL unit, namely, subset sequence parameter set NAL unit (type 15), to contain sequence parameter set information for quality and spatial enhancement layers. All these three newly specified NAL unit types (14, 15, and 20) are among those reserved in H.264/AVC and are to be ignored by decoders conforming to one or more of the profiles specified in Annex A of [H.264].
[264]の附属書Aに定義されたプロファイルがすでにそれをサポートするように時間的スケーラビリティの概念は、既にH.264 / AVCで存在していることに留意されたいです。具体的には、H.264 / AVCでは、サブシーケンスの概念は、付加拡張情報（SEI）メッセージを介して一時的層の任意の使用を可能にするために導入されています。 SVCは、それぞれ、空間的および品質スケーラビリティのために使用されるのdependency_id及びquality_id値を一緒に、temporal_idパラメータを使用して時間的スケーラビリティ情報を露出（およびと一体化）することにより、このアプローチを拡張します。付属書G [264]で定義された符号化画像データの場合、これは忠実度パラメータは、そのヘッダの一部であるNALユニット、スケーラブル拡張NALユニット（タイプ20）で、すなわち、符号化されたスライスの新しいタイプを使用することによって達成されます。 H.264 / AVCに追従し、既存のH.264 / AVCデコーダ、NALユニット、すなわち、プレフィックスNALユニット（タイプ14）の別の新しいタイプとの互換性を確保するために、符号化画像データの場合、このヘッダー情報を運ぶために定義されています。 SVCは、さらに、NALユニット、すなわち、サブセットシーケンスパラメータセットNALユニット（タイプ15）の第三の新しいタイプを指定し、品質と空間拡張層のシーケンスパラメータセット情報を含みます。すべてのこれら三つの新たに指定されたNALユニット・タイプ（14、15、及び20）は、H.264 / AVCに貯留ものの中で、[264の付属書Aに指定されたプロファイルの1つまたは複数に準拠デコーダによって無視されます]。
Within an AU, the VCL NAL units associated with a given dependency_id and quality_id are referred to as a "layer representation". The layer representation corresponding to the lowest values of dependency_id and quality_id (i.e., zero for both) is compliant by design to H.264/AVC. The set of VCL and associated non-VCL NAL units across all AUs in a bitstream associated with a particular combination of values of dependency_id and quality_id, and regardless of the value of temporal_id, is conceptually a scalable layer. For backward compatibility with H.264/AVC, it is important to differentiate, however, whether or not SVC-specific NAL units are present in a given bitstream. This is particularly important for the lowest fidelity values in terms of dependency_id and quality_id (zero for both), as the corresponding VCL data are compliant with H.264/AVC, and may or may not be accompanied by associated prefix NAL units. This memo therefore uses the term "AVC base layer" to designate the layer that does not contain SVC-specific NAL units, and "SVC base layer" to designate the same layer but with the addition of the associated SVC prefix NAL units. Note that the SVC specification uses the term "base layer" for what in this memo will be referred to as "AVC base layer". Similarly, it is also important to be able to differentiate, within a layer, the temporal fidelity components it contains. This memo uses the term "T0" to indicate, within a particular layer, the subset that contains the NAL units associated with temporal_id equal to 0.
AU内で、所与のdependency_id及びquality_idに関連付けられたVCL NALユニットは、「レイヤ表現」と呼ばれます。 dependency_id及びquality_idの最小値（両方のための、すなわち、ゼロ）に対応する層表現は、H.264 / AVCの設計によって準拠しています。かかわらずtemporal_idの値のdependency_id及びquality_id、との値の特定の組み合わせに関連付けられたビットストリーム内の全てのAUを横切っVCLと関連する非VCL NALユニットのセットは、概念的にスケーラブル層です。 H.264 / AVCとの下位互換性のために、NALユニットが所与のビットストリーム内に存在するSVC固有のか否かが、区別することが重要です。これは、対応するVCLデータをH.264 / AVCに準拠し、及び又は関連プレフィックスNALユニットが付随してもしなくてもよいように、（両方のためのゼロ）のdependency_id及びquality_idの点で最も低い忠実度の値は特に重要です。このメモは、従って、同じ層を示すためにSVC固有のNALユニットを含まない層、および「SVCベース層」を指定する用語「AVCベース層」を使用するが、関連するSVCプレフィックスNALユニットを添加しました。 SVC仕様は、「AVCベース層」と呼ばれるこのメモで何のために、用語「ベース層」を使用することに注意してください。同様に、層内に、それに含まれる時間的忠実性成分を区別することができることも重要です。このメモは、特定の層内に、0に等しいtemporal_idに関連付けられているNAL単位を含むサブセットを示すために、用語「T0」を使用します。
SNR scalability in SVC is offered in two different ways. In what is called coarse-grain scalability (CGS), scalability is provided by including or excluding a complete layer when decoding a particular bitstream. In contrast, in medium-grain scalability (MGS), scalability is provided by selectively omitting the decoding of specific NAL units belonging to MGS layers. The selection of the NAL units to omit can be based on fixed-length fields present in the NAL unit header (see also Sections 1.1.3 and 4.2).
SVCにおけるSNRスケーラビリティは、2つの異なる方法で提供されています。粗粒度スケーラビリティ（CGS）と呼ばれるもので、スケーラビリティは、特定のビットストリームを復号する際に完全な層を含むまたは除外することによって提供されます。対照的に、中粒のスケーラビリティ（MGS）に、スケーラビリティを選択MGS層に属する特定のNALユニットの復号化を省略することによって提供されます。省略するNALユニットの選択は、NALユニットヘッダに存在する固定長フィールドに基づくことができる（また、セクション1.1.3および4.2を参照）。
SVC maintains the parameter sets concept in H.264/AVC and introduces a new type of sequence parameter set, referred to as the subset sequence parameter set [H.264]. Subset sequence parameter sets have NAL unit type equal to 15, which is different from the NAL unit type value (7) of sequence parameter sets. VCL NAL units of NAL unit type 1 to 5 must only (indirectly) refer to sequence parameter sets, while VCL NAL units of NAL unit type 20 must only (indirectly) refer to subset sequence parameter sets. The references are indirect because
SVCパラメータは、H.264 / AVCで概念を設定し、シーケンスパラメータセットの新しいタイプを導入し維持し、[264]に設定サブセットシーケンスパラメータと呼びます。サブセットシーケンスパラメータセットは、シーケンスパラメータセットのNALユニット・タイプの値と異なる15に等しいNALユニットの種類、（7）を有します。 NALユニットタイプ20のVCL NALユニットのみ（間接的に）シーケンスパラメータセットのサブセットを参照する必要がありながら5にNALユニットタイプ1のVCL NALユニットのみ（間接的に）、シーケンスパラメータセットを参照しなければなりません。参照があるため、間接的です
VCL NAL units refer to picture parameter sets (in their slice header), which in turn refer to regular or subset sequence parameter sets. Subset sequence parameter sets use a separate identifier value space than sequence parameter sets.
VCL NALユニットは、次に、規則的またはサブセットシーケンスパラメータセットを参照（そのスライスヘッダに）パラメータセット、ピクチャを参照します。サブセットシーケンスパラメータセットはシーケンスパラメータセットとは別の識別子の値のスペースを使用します。
In SVC, coded picture data from different layers may use the same or different sequence and picture parameter sets. Let the variable DQId be equal to dependency_id * 16 + quality_id. At any time instant during the decoding process there is one active sequence parameter set for the layer representation with the highest value of DQId and one or more active layer SVC sequence parameter set(s) for layer representations with lower values of DQId. The active sequence parameter set or an active layer SVC sequence parameter set remains unchanged throughout a coded video sequence in the scalable layer in which the active sequence parameter set or active layer SVC sequence parameter set is referred to. This means that the referred sequence parameter set or subset sequence parameter set can only change at instantaneous decoding refresh (IDR) access units for any layer. At any time instant during the decoding process there may be one active picture parameter set (for the layer representation with the highest value of DQId) and one or more active layer picture parameter set(s) (for layer representations with lower values of DQId). The active picture parameter set or an active layer picture parameter set remains unchanged throughout a layer representation in which the active picture parameter set or active layer picture parameter set is referred to, but may change from one AU to the next.
SVCにおいて、異なる層からの符号化された画像データは、同一または異なる配列とピクチャパラメータセットを使用してもよいです。変数DQIdが* 16 + quality_idをdependency_idを等しいとします。復号化プロセス中の任意の時点でDQIdの低い値を有するレイヤ表現の最高DQIdの値および1つ以上の活性層SVCのシーケンスパラメータセット（S）を有するレイヤ表現のための1つのアクティブなシーケンスパラメータセットが存在します。アクティブなシーケンスパラメータセット又は活性層SVCのシーケンスパラメータセットは、スケーラブルレイヤに符号化されたビデオシーケンスにわたって不変のまま、活性シーケンスパラメータセット又は活性層SVCのシーケンスパラメータセットが参照されています。これは呼ばれるシーケンスパラメータセットまたはサブセットシーケンスパラメータセットのみを任意の層の瞬時復号化リフレッシュ（IDR）アクセスユニットに変更することができることを意味します。復号化プロセス中の任意の時点で（DQIdの最高値を有するレイヤ表現のための）一つの活性ピクチャパラメータセットと1つ以上の活性層のピクチャパラメータセット（複数可）が存在してもよい（DQIdの低い値を有するレイヤ表現用） 。アクティブピクチャパラメータセットまたは活性層ピクチャパラメータセットは、アクティブなピクチャパラメータセットまたは活性層ピクチャパラメータセットが参照された層の表現を通して不変のままであるが、1つのAUから次へと変更することができます。
SVC extends the one-byte H.264/AVC NAL unit header by three additional octets for NAL units of types 14 and 20. The header indicates the type of the NAL unit, the (potential) presence of bit errors or syntax violations in the NAL unit payload, information regarding the relative importance of the NAL unit for the decoding process, the layer identification information, and other fields as discussed below.
SVCは、ヘッダは、NALユニット内のビットエラーまたは構文違反の（潜在的）の存在のタイプを示す14および20タイプのNALユニットのための3つの追加のオクテットずつバイトH.264 / AVC NALユニットヘッダを拡張しますNALユニットペイロード、復号処理、層識別情報のNALユニットの相対的な重要性に関する情報、及び以下に説明するように他のフィールド。
The syntax and semantics of the NAL unit header are specified in [H.264], but the essential properties of the NAL unit header are summarized below for convenience.
NALユニットヘッダの構文と意味論は[264]で指定されているが、NALユニットヘッダの本質的な特性は、便宜のために以下にまとめます。
The first byte of the NAL unit header has the following format (the bit fields are the same as defined for the one-byte H.264/AVC NAL unit header, while the semantics of some fields have changed slightly, in a backward-compatible way):
いくつかのフィールドのセマンティクスは、後方互換性で、わずかに変更されていながら、NALユニットヘッダの最初のバイトは、（ビットフィールドは、1バイトのH.264 / AVC NALユニットヘッダの定義と同じで、次の形式であるました仕方）：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
The semantics of the components of the NAL unit type octet, as specified in [H.264], are described briefly below. In addition to the name and size of each field, the corresponding syntax element name in [H.264] is also provided.
NALユニットタイプオクテットの構成要素の意味は、[264]で指定されるように、以下に簡単に説明されています。 [264]の各フィールドの名前とサイズに加えて、対応する構文要素名も提供されます。
F: 1 bit forbidden_zero_bit. H.264/AVC declares a value of 1 as a syntax violation.
F：1ビットforbidden_zero_bit。 H.264 / AVCは、構文違反として1の値を宣言します。
NRI: 2 bits nal_ref_idc. A value of "00" (in binary form) indicates that the content of the NAL unit is not used to reconstruct reference pictures for future prediction. Such NAL units can be discarded without risking the integrity of the reference pictures in the same layer. A value greater than "00" indicates that the decoding of the NAL unit is required to maintain the integrity of reference pictures in the same layer or that the NAL unit contains parameter sets.
NRI：2ビットnal_ref_idcを。 （バイナリ形式で）「00」の値は、NALユニットの内容は、将来予測のための参照ピクチャを再構成するために使用されていないことを示します。そのようなNALユニットは、同一層内の参照ピクチャの完全性を危険にさらすことなく廃棄することができます。 「00」よりも大きい値は、NALユニットの復号が同一層内又はNALユニットは、パラメータセットが含まれている参照ピクチャの完全性を維持するために必要とされることを示しています。
Type: 5 bits nal_unit_type. This component specifies the NAL unit type as defined in Table 7-1 of [H.264], 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 [H.264].
タイプ：5ビットnal_unit_typeは。このメモ内の後の表7-1 [264]で定義され、そして、このコンポーネントは、NALユニットのタイプを指定します。 [264]で現在定義されているすべてのNALユニットの種類とその意味論の参考のために、セクション7.4.1を参照してください。
In H.264/AVC, NAL unit types 14, 15, and 20 are reserved for
future extensions. SVC uses these three NAL unit types as
follows: NAL unit type 14 is used for prefix NAL unit, NAL unit
type 15 is used for subset sequence parameter set, and NAL unit
type 20 is used for coded slice in scalable extension (see
Section 7.4.1 in [H.264]). NAL unit types 14 and 20 indicate
the presence of three additional octets in the NAL unit header,
as shown below.
+---------------+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|I| PRID |N| DID | QID | TID |U|D|O| RR|
+---------------+---------------+---------------+
R: 1 bit reserved_one_bit. Reserved bit for future extension. R must be equal to 1. The value of R must be ignored by decoders.
R：1ビットreserved_one_bit。将来の拡張のための予約ビット。 Rは、Rの値は、デコーダによって無視されなければならない1に等しくなければなりません。
I: 1 bit idr_flag. This component specifies whether the layer representation is an instantaneous decoding refresh (IDR) layer representation (when equal to 1) or not (when equal to 0).
I：1ビットidr_flag。このコンポーネントは、レイヤ表現が瞬時復号リフレッシュ（IDR）レイヤ表現（等しい1）か否（等しい0）であるかどうかを指定します。
PRID: 6 bits priority_id. This flag specifies a priority identifier for the NAL unit. A lower value of PRID indicates a higher priority.
PRID：6ビットPRIORITY_ID。このフラグは、NALユニットの優先識別子を指定します。 PRIDの低い値は、より高い優先度を示します。
N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0).
N：1ビットno_inter_layer_pred_flag。このフラグは、層間予測（0に等しい）（1に等しい）か否かを符号化スライスを復号化するために使用することができるかどうかをするとき符号化スライスNALユニット内に存在する、特定します。
DID: 3 bits dependency_id. This component indicates the inter-layer coding dependency level of a layer representation. At any access unit, a layer representation with a given dependency_id may be used for inter-layer prediction for coding of a layer representation with a higher dependency_id, while a layer representation with a given dependency_id shall not be used for inter-layer prediction for coding of a layer representation with a lower dependency_id.
DID：3ビットのdependency_id。このコンポーネントは、レイヤ表現のインターレイヤ符号化依存性レベルを示します。所与のdependency_idを有するレイヤ表現が符号化レイヤ間予測のために使用されないものとしつつ、任意のアクセスユニットに、所与のdependency_idを有するレイヤ表現は、より高いdependency_idを有するレイヤ表現の符号化のためのレイヤ間予測のために使用することができます下部のdependency_idを有するレイヤ表現の。
QID: 4 bits quality_id. This component indicates the quality level of an MGS layer representation. At any access unit and for identical dependency_id values, a layer representation with quality_id equal to ql uses a layer representation with quality_id equal to ql-1 for inter-layer prediction.
QID：4ビットquality_id。このコンポーネントは、MGS層表現の品質レベルを示します。任意のアクセスユニットに同一のdependency_id値について、QLに等しいquality_id有するレイヤ表現は、レイヤ間予測のためQL-1に等しいquality_id有するレイヤ表現を使用します。
TID: 3 bits temporal_id. This component indicates the temporal level of a layer representation. The temporal_id is associated with the frame rate, with lower values of _temporal_id corresponding to lower frame rates. A layer representation at a given temporal_id typically depends on layer representations with lower temporal_id values, but it never depends on layer representations with higher temporal_id values.
TID：3ビットがtemporal_id。このコンポーネントは、レイヤ表現の時間的レベルを示します。 temporal_idは_temporal_idの低い値は、より低いフレームレートに対応して、フレームレートに関連しています。所与temporal_idに層表現は、典型的にはより低いtemporal_id値を有するレイヤ表現に依存するが、それはより高いtemporal_id値を有するレイヤ表現に依存することはありません。
U: 1 bit use_ref_base_pic_flag. A value of 1 indicates that only reference base pictures are used during the inter prediction process. A value of 0 indicates that the reference base pictures are not used during the inter prediction process.
U：1ビットuse_ref_base_pic_flag。 1の値は、参照ベースピクチャがインター予測処理中に使用されていることを示しています。 0の値は、参照ベースピクチャがインター予測処理中に使用されていないことを示しています。
D: 1 bit discardable_flag. A value of 1 indicates that the current NAL unit is not used for decoding NAL units with values of dependency_id higher than the one of the current NAL unit, in the current and all subsequent access units. Such NAL units can be discarded without risking the integrity of layers with higher dependency_id values. discardable_flag equal to 0 indicates that the decoding of the NAL unit is required to maintain the integrity of layers with higher dependency_id.
D：1ビットdiscardable_flag。 1の値は、現在のNALユニットは、現在および後続のすべてのアクセス単位で、現在のNALユニットのいずれよりも高いのdependency_idの値を有するNALユニットを復号するために使用されていないことを示しています。そのようなNALユニットは、より高いのdependency_id値を有する層の完全性を危険にさらすことなく廃棄することができます。 0に等しいdiscardable_flagはNALユニットの復号化はより高いdependency_idを有する層の完全性を維持するために必要であることを示しています。
O: 1 bit output_flag: Affects the decoded picture output process as defined in Annex C of [H.264].
O：1ビットoutput_flagは：[264]の附属書Cに定義されている復号化画像出力処理に影響を与えます。
RR: 2 bits reserved_three_2bits. Reserved bits for future extension. RR MUST be equal to "11" (in binary form). The value of RR must be ignored by decoders.
RR：2ビットreserved_three_2bits。将来の拡張のための予約ビット。 RRは、（バイナリ形式で）「11」に等しくなければなりません。 RRの値は、デコーダによって無視されなければなりません。
This memo extends the semantics of F, NRI, I, PRID, DID, QID, TID, U, and D per Annex G of [H.264] as described in Section 4.2.
このメモは、セクション4.2で説明したようにF、NRI、I、PRID、[264]のDID、QID、TID、U、及びD附属書あたりGのセマンティクスを拡張します。
Similar to [RFC6184], this payload format can only be used to carry the raw NAL unit stream over RTP and not the bytestream format specified in Annex B of [H.264].
[RFC6184]と同様に、このペイロードフォーマットは、RTP及び[264]の付録Bで指定されていないバイトストリームフォーマット上生NALユニットストリームを運ぶために使用することができます。
The design principles, transmission modes, and packetization modes as well as new payload structures are summarized in this section. It is assumed that the reader is familiar with the terminology and concepts defined in [RFC6184].
設計原則、伝送モード、およびパケット化モードと同様に、新たなペイロード構造は、このセクションにまとめられています。読者が[RFC6184]で定義された用語と概念に精通しているものとします。
The following design principles have been observed for this payload format:
以下の設計原理は、このペイロード形式のために観察されています。
o Backward compatibility with [RFC6184] wherever possible.
[RFC6184]とO下位互換可能な限り。
o The SVC base layer or any H.264/AVC compatible subset of the SVC base layer, when transmitted in its own RTP stream, must be encapsulated using [RFC6184]. This ensures that such an RTP stream can be understood by [RFC6184] receivers.
それ自身のRTPストリームで送信SVCベース層またはSVCベース層のいずれかH.264 / AVC互換のサブセット、O、[RFC6184]を使用してカプセル化されなければなりません。これは、RTPストリームは[RFC6184]受信機によって理解することができることを確実にします。
o Media-aware network elements (MANEs) as defined in [RFC6184] are signaling-aware, rely on signaling information, and have state.
[RFC6184]で定義されるように、Oメディアアウェアネットワーク要素（マネス）は、対応のシグナリング情報をシグナリングに依存し、そして状態を有しています。
o MANEs can aggregate multiple RTP streams, possibly from multiple RTP sessions.
入出力マネスは、複数のRTPは、複数のRTPセッションからおそらく、ストリームを集約することができます。
o MANEs can perform media-aware stream thinning (selective elimination of packets or portions thereof). By using the payload header information identifying layers within an RTP session, MANEs are able to remove packets or portions thereof from the incoming RTP packet stream. This implies rewriting the RTP headers of the outgoing packet stream, and rewriting of RTCP packets as specified in Section 7 of [RFC3550].
入出力マネスは薄く、メディアアウェアストリーム（そのパケットまたは部分の選択的な除去）を行うことができます。 RTPセッション内で層を識別するペイロードヘッダ情報を用いて、マネス着信RTPパケットストリームから、そのパケットまたは部分を除去することができます。これは、発信パケットストリームのRTPヘッダを書き換え、および[RFC3550]のセクション7で指定されたRTCPパケットの書き換えを意味しています。
This memo allows the packetization of SVC data for both single-session transmission (SST) and multi-session transmission (MST). In the case of SST all SVC data are carried in a single RTP session. In the case of MST two or more RTP sessions are used to carry the SVC data, in accordance with the MST-specific packetization modes defined in this memo, which are based on the packetization modes defined in [RFC6184]. In MST, each RTP session is associated with one RTP stream, which may carry one or more layers.
このメモは、シングルセッション送信（SST）とマルチセッション送信（MST）の両方のためのSVCデータのパケット化を可能にします。 SSTの場合は、すべてのSVCデータは、単一のRTPセッションに運ばれます。 MST二つ以上のRTPセッションの場合には[RFC6184]で定義されたパケット化モードに基づいて、このメモで定義されたMST-特定のパケット化モードに応じて、SVCデータを運ぶために使用されます。 MSTでは、各RTPセッションは、1つ以上の層を有していてもよい1つのRTPストリームと関連しています。
The base layer is, by design, compatible to H.264/AVC. During transmission, the associated prefix NAL units, which are introduced by SVC and, when present, are ignored by H.264/AVC decoders, may be encapsulated within the same RTP packet stream as the H.264/AVC VCL NAL units or in a different RTP packet stream (when MST is used). For convenience, the term "AVC base layer" is used to refer to the base layer without prefix NAL units, while the term "SVC base layer" is used to refer to the base layer with prefix NAL units.
ベース層は、設計により、H.264 / AVCに互換性があります。送信中に、H.264 / AVCデコーダによって無視され、本SVCと、によって導入される関連プレフィックスNALユニットは、H.264 / AVC VCL NALユニットとして又はにおける同一のRTPパケットストリーム内にカプセル化することができます（MSTが使用される）異なるRTPパケットストリーム。用語「SVCベース層」プレフィックスNALユニットを有するベース層を指すために使用されている間、便宜上、用語「AVCベース層」とは、前置NALユニットなしのベース層を指すために使用されます。
Furthermore, the base layer may have multiple temporal components (i.e., supporting different frame rates). As a result, the lowest temporal component ("T0") of the AVC or SVC base layer is used as the starting point of the SVC bitstream hierarchy.
また、下地層は、複数の時間成分（すなわち、支持異なるフレームレート）を有していてもよいです。結果として、AVCまたはSVCベースレイヤの最下位の時間成分（「T0」）は、SVCビットストリームの階層の出発点として使用されます。
This memo allows encapsulating in a given RTP stream any of the following three alternatives of layer combinations:
このメモは、与えられたRTPストリームのレイヤの組み合わせの次の3つの選択肢のいずれかをカプセル化できます。
1. the T0 AVC base layer or the T0 SVC base layer only; 2. one or more enhancement layers only; or 3. the T0 SVC base layer, and one or more enhancement layers.
1. T0 AVCベース層のみT0 SVCベース層と前記一つ以上のエンハンスメントレイヤのみ。または3 T0 SVCベース層、および1つまたは複数のエンハンスメントレイヤ。
SST should be used in point-to-point unicast applications and, in general, whenever the potential benefit of using multiple RTP sessions does not justify the added complexity. When SST is used, the layer combination cases 1 and 3 above can be used. When an H.264/AVC compatible subset of the SVC base layer is transmitted using SST, the packetization of [RFC6184] must be used, thus ensuring compatibility with [RFC6184] receivers. When, however, one or more SVC quality or spatial enhancement layers are transmitted using SST, the packetization defined in this memo must be used. In SST, any of the three [RFC6184] packetization modes, namely, single NAL unit mode, non-interleaved mode, and interleaved mode, can be used.
SSTは、ポイントツーポイントのユニキャストアプリケーションで使用されるべきであり、一般的に、いつでも複数のRTPセッションを使用することの潜在的な利点は、追加の複雑さを正当化しません。 SSTを使用する場合、層の組み合わせケース1及び上記3を使用することができます。 SVCベースレイヤのH.264 / AVC互換のサブセットがSST、[RFC6184]のパケットを用いて送信される場合、したがって[RFC6184]受信機との互換性を確保し、使用しなければなりません。しかしながら、一つ以上のSVC品質又は空間拡張層がSSTを使用して送信される場合、このメモで定義されたパケットを使用しなければなりません。 SST三[RFC6184]パケット化モード、すなわち、単一NALユニットモード、非インタリーブモード、およびインターリーブモードのいずれにおいても、使用することができます。
MST should be used in a multicast session when different receivers may request different layers of the scalable bitstream. An operation point for an SVC bitstream, as defined in this memo, corresponds to a set of layers that together conform to one of the profiles defined in Annex A or G of [H.264] and, when decoded, offer a representation of the original video at a certain fidelity. The number of streams used in MST should be at least equal to the number of operation points that may be requested by the receivers. Depending on the application, this may result in each layer being carried in its own RTP session, or in having multiple layers encapsulated within one RTP session.
異なる受信機は、スケーラブルビットストリームの異なる層を要求することができる場合MSTは、マルチキャストセッションで使用されるべきです。 SVCビットストリームの動作点を、このメモで定義されるように、一緒に[264]の附属書A又はGで定義されたプロファイルのいずれかに適合層の組に対応し、復号化されたとき、の表現を提供特定忠実にオリジナルのビデオ。 MSTに使用されるストリームの数は、受信機によって要求されてもよい動作点の数と少なくとも等しくなければなりません。用途に応じて、これは、各層は、それ自身のRTPセッションで運ばれる、または1つのRTPセッション内でカプセル化された複数の層を有することをもたらすことができます。
Informative note: Layered multicast is a term commonly used to describe the application where multicast is used to transmit layered or scalable data that has been encapsulated into more than one RTP session. This application allows different receivers in the multicast session to receive different operation points of the scalable bitstream. Layered multicast, among other application examples, is discussed in more detail in Section 11.2.
有益注：階層化マルチキャストは、一般的にマルチキャストが複数のRTPセッションにカプセル化された層またはスケーラブルなデータを送信するために使用されるアプリケーションを記述するために使用される用語です。このアプリケーションは、マルチキャストセッション内の異なる受信機は、スケーラブルビットストリームの異なる動作点を受け入れることを可能にします。他の応用例のうち、階層化マルチキャストは、第11.2節で詳しく説明されています。
When MST is used, any of the three layer combinations above can be used for each of the sessions. When an H.264/AVC compatible subset of the SVC base layer is transmitted in its own session in MST, the packetization of [RFC6184] must be used, such that [RFC6184] receivers can be part of the MST and receive only this session. For MST, this memo defines four different MST-specific packetization modes, namely, non-interleaved timestamp (NI-T) based mode, non-interleaved CS-DON (NI-C) based mode, non-interleaved combined timestamp and CS-DON mode (NI-TC), and interleaved CS-DON (I-C) based mode (detailed in Section 4.5.2). The modes differ depending on whether the SVC data are allowed to be interleaved, i.e., to be transmitted in an order different than the intended decoding order, and they also differ in the mechanisms provided in order to recover the correct decoding order of the NAL units across the multiple RTP sessions. These four MST modes reuse the packetization modes introduced in [RFC6184] for the packetization of NAL units in each of their individual RTP sessions.
MSTを使用した場合、上記3層の組合せのいずれかがセッションの各々のために使用することができます。 SVCベースレイヤのH.264 / AVC互換のサブセットがMSTに独自のセッションで送信される場合、[RFC6184]のパケットは、[RFC6184]受信機はMSTの一部であるとのみ、このセッションを受け入れることができるように、使用されなければなりません。 MSTのために、このメモは、4つの異なるMST-特定のパケット化モード、すなわち、非インターリーブタイムスタンプ（NI-T）ベースのモード、非インターリーブCS-DON（NI-C）ベースのモード、非インターリーブ合成タイムスタンプとCS-を定義しますDONモード（NI-TC）、及びインターリーブCS-DON（IC）ベースモード（4.5.2項で詳述）。モードは、意図復号順序とは異なる順序で送信される、すなわち、SVCデータをインターリーブすることを許可するかどうかによって異なり、それらはまた、NALユニットの正しい復号化順序を回復するために提供されるメカニズムが異なります複数のRTPセッション間。これら四つのMSTモードは、個々のRTPセッションの各々におけるNALユニットパケットのために[RFC6184]で導入されたパケット化モードを再利用します。
As the names of the MST packetization modes imply, the NI-T, NI-C, and NI-TC modes do not allow interleaved transmission, while the I-C mode allows interleaved transmission. With any of the three non-interleaved MST packetization modes, legacy [RFC6184] receivers with implementation of the non-interleaved mode specified in [RFC6184] can join a multi-session transmission of SVC, to receive the base RTP session encapsulated according to [RFC6184].
MSTパケット化モードの名前が暗示するようにI-Cモードはインターリーブ送信を可能にしながら、NI-T、NI-C、およびNI-TCモードは、インターリーブされた送信を許可しません。 [RFC6184]で指定された非インタリーブモードの実装を持つ3つの非インターリーブMSTパケット化モードのいずれかと、レガシー[RFC6184]受信機は、SVCのマルチセッションの伝送に参加することができるに従ってカプセル化されたベースRTPセッションを受信するために[ RFC6184]。
[RFC6184] specifies three basic payload structures, namely, single NAL unit packet, aggregation packet, and fragmentation unit. Depending on the basic payload structure, an RTP packet may contain a NAL unit not aggregating other NAL units, one or more NAL units aggregated in another NAL unit, or a fragment of a NAL unit not aggregating other NAL units. Each NAL unit of a type specified in [H.264] (i.e., 1 to 23, inclusive) may be carried in its entirety in a single NAL unit packet, may be aggregated in an aggregation packet, or may be fragmented and carried in a number of fragmentation unit packets. To enable aggregation or fragmentation of NAL units while still ensuring that the RTP packet payload is only composed of NAL units, [RFC6184] introduced six new NAL unit types (24-29) to be used as payload structures, selected from the NAL unit types left unspecified in [H.264].
[RFC6184]は三つの基本的なペイロード構造、即ち、単一NALユニットパケット、アグリゲーションパケット、および断片化ユニットを特定します。基本的なペイロードの構造に応じて、RTPパケットは、他のNALユニット、別のNALユニット、または他のNALユニットを集約しないNALユニットの断片に凝集一つ以上のNALユニットを集約しないNALユニットを含んでいてもよいです。 [264]（すなわち、1〜23、を含む）単一NALユニットパケットにその全体を実施することができる、集約パケットに集約することができる、又は断片とで実施することができるで指定されたタイプの各NALユニットフラグメンテーションユニットパケットの数。依然としてRTPパケットのペイロードのみNALユニットから構成されていることを確保しつつ、[RFC6184]をNALユニットの凝集または断片化を可能にするためにNALユニットのタイプから選択されたペイロード構造として使用する6つの新しいNALユニットタイプ（24-29）を導入し[264]に指定されないまま。
This memo reuses all the payload structures used in [RFC6184]. Furthermore, three new types of NAL units are defined: payload content scalability information (PACSI) NAL unit, empty NAL unit, and non-interleaved multi-time aggregation packet (NI-MTAP) (specified in Sections 4.9, 4.10, and 4.7.1, respectively).
このメモは、[RFC6184]で使用されるすべてのペイロード構造を再利用します。さらに、定義されたNALユニットの三の新しいタイプ：ペイロードコンテンツスケーラビリティ情報（PACSI）NALユニット、空のNALユニット、及び非インターリーブマルチタイム集約パケット（NI-MTAP）（4.10、セクション4.9で指定され、そして4.7。 1、それぞれ）。
PACSI NAL units may be used for the following purposes:
PACSI NALユニットは、次の目的のために使用することができます。
o To enable MANEs to decide whether to forward, process, or discard aggregation packets, by checking in PACSI NAL units the scalability information and other characteristics of the aggregated NAL units, rather than looking into the aggregated NAL units themselves, which are defined by the video coding specification.
oはPACSI NAL単位で集約NALユニットのスケーラビリティ情報および他の特性を調べるのではなく、によって定義される凝集NALユニット自体に調べることによって、集合パケットを転送するプロセス、または廃棄するかを決定するマネスを有効にしますビデオは、仕様をコーディングします。
o To enable correct decoding order recovery in MST using the NI-C or NI-TC mode, with the help of the CS-DON information included in PACSI NAL units.
oはPACSI NALユニットに含まれるCS-DON情報の助けを借りて、NI-CまたはNI-TCモードを使用して、MSTにおける正しい復号化順序の回復を有効にします。
o To improve resilience to packet losses, e.g., by utilizing the following data or information included in PACSI NAL units: repeated Supplemental Enhancement Information (SEI) messages, information regarding the start and end of layer representations, and the indices to layer representations of the lowest temporal subset.
PACSI NALユニットに含まれる次のデータまたは情報を利用することによって、例えば、パケット損失の回復力を改善するために、O：の表現を層に付加拡張情報（SEI）メッセージ、レイヤ表現の開始と終了に関する情報、及びインデックスを繰り返します最低の時間部分組。
Empty NAL units may be used to enable correct decoding order recovery in MST using the NI-T or NI-TC mode. NI-MTAP NAL units may be used to aggregate NAL units from multiple access units but without interleaving.
空のNALユニットは、NI-TまたはNI-TCモードを使用してMSTにおける正しい復号化順序の回復を可能にするために使用されてもよいです。 NI-MTAPのNALユニットは、複数のアクセスユニットからではなく、インターリーブなしNALユニットを集約するために使用することができます。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
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の値を割り当てることと同じです。ビットをクリアすると、そのビット0（オフ）の値を割り当てることと同じです。
This document uses the terms and definitions of [H.264]. Section 3.1.1 lists relevant definitions copied from [H.264] for convenience.
この文書では、[264]の用語と定義を使用しています。 3.1.1リストの関連する定義は便宜上、[H.264]からコピー。
When there is discrepancy, the definitions in [H.264] take precedence. Section 3.1.2 gives definitions specific to this memo. Some of the definitions in Section 3.1.2 are also present in [RFC6184] and copied here with slight adaptations as needed.
不一致がある場合は、[H.264]で定義が優先されます。 3.1.2はこのメモに固有の定義を示します。 3.1.2項の定義のいくつかは、[RFC6184]に存在し、必要に応じてわずかに適応してここにコピーされています。
access unit: A set of NAL units always containing exactly one primary coded picture. In addition to the primary coded picture, an access unit may also contain one or more redundant coded pictures, one auxiliary coded picture, 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ユニットを含んでいてもよいです。アクセスユニットの復号化は、常に復号画像が得られます。
base layer: A bitstream subset that contains all the NAL units with the nal_unit_type syntax element equal to 1 or 5 of the bitstream and does not contain any NAL unit with the nal_unit_type syntax element equal to 14, 15, or 20 and conforms to one or more of the profiles specified in Annex A of [H.264].
ベース層：ビットストリームの1又は5に等しいnal_unit_typeは構文要素を持つすべてのNALユニットを含有し、14に等しいnal_unit_typeは構文要素を有する任意のNALユニットが含まれていないビットストリームのサブセット、15、または20と一つに合致又は[264]の付録Aで指定されたプロファイルのより。
base quality layer representation: The layer representation of the target dependency representation of an access unit that is associated with the quality_id syntax element equal to 0.
ベース品質層の表現：0に等しいquality_id構文要素に関連付けられているアクセスユニットのターゲット依存表現の層表現。
coded video sequence: A sequence of access units that consists, in decoding order, of an 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アクセスユニットからなるアクセスユニットのシーケンス。
dependency representation: A subset of Video Coding Layer (VCL) NAL units within an access unit that are associated with the same value of the dependency_id syntax element, which is provided as part of the NAL unit header or by an associated prefix NAL unit. A dependency representation consists of one or more layer representations.
依存関係の表現：NALユニットヘッダの一部として、または関連する前置NALユニットによって提供されるのdependency_id構文要素の同じ値に関連付けられているアクセスユニット内のレイヤ（VCL）NALユニットを符号化ビデオのサブセット。依存関係の表現は、1つまたは複数のレイヤ表現から成ります。
IDR access unit: An access unit in which the primary coded picture is an IDR picture.
IDRアクセスユニット：主符号化ピクチャがIDRピクチャであるアクセスユニット。
IDR picture: Instantaneous decoding refresh picture. A coded picture in which all slices of the target dependency representation within the access unit are I or EI slices that causes the decoding process to mark all reference pictures as "unused for reference" immediately after decoding the IDR picture. 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. The first picture of each coded video sequence is an IDR picture.
IDRピクチャ：瞬時復号リフレッシュ絵。アクセスユニット内のターゲット依存表現のすべてのスライスがI又は直ちにIDRピクチャを復号した後、「参照のために使用されていない」として全ての参照ピクチャをマークするために復号プロセスを引き起こすEIスライスである符号化ピクチャました。 IDRピクチャの復号後、復号化順序で次のすべての符号化ピクチャは、IDRピクチャの前に復号された任意のピクチャからインター予測なしで復号することができます。各符号化されたビデオシーケンスの最初のピクチャはIDRピクチャです。
layer representation: A subset of VCL NAL units within an access unit that are associated with the same values of the dependency_id and quality_id syntax elements, which are provided as part of the VCL NAL unit header or by an associated prefix NAL unit. One or more layer representations represent a dependency representation.
レイヤ表現：VCL NALユニットヘッダの一部として、または関連する前置NALユニットによって提供されるのdependency_id及びquality_id構文要素の同じ値に関連付けられているアクセスユニット内のVCL NALユニットのサブセット。 1つまたは複数のレイヤ表現は、依存関係表現を表します。
prefix NAL unit: A NAL unit with nal_unit_type equal to 14 that immediately precedes in decoding order a NAL unit with nal_unit_type equal to 1, 5, or 12. The NAL unit that immediately succeeds in decoding order the prefix NAL unit is referred to as the associated NAL unit. The prefix NAL unit contains data associated with the associated NAL unit, which are considered to be part of the associated NAL unit.
プレフィックスNALユニット：直ちにプレフィックスNALユニットは、と呼ばれ、すぐに復号化順に成功した1,5、または12 NALユニットに等しいnal_unit_typeはで復号化順でNALユニットに先行する14に等しいnal_unit_typeは有するNALユニット関連するNALユニット。プレフィックスNALユニットは、関連NALユニットの一部であると考えられる関連するNALユニットに関連付けられたデータを含みます。
reference base picture: A reference picture that is obtained by decoding a base quality layer representation with the nal_ref_idc syntax element not equal to 0 and the store_ref_base_pic_flag syntax element equal to 1 of an access unit and all layer representations of the access unit that are referred to by inter-layer prediction of the base quality layer representation. A reference base picture is not an output of the decoding process, but the samples of a reference base picture may be used for inter prediction in the decoding process of subsequent pictures in decoding order. Reference base picture is a collective term for a reference base field or a reference base frame.
参照ベースピクチャ：0に等しくないnal_ref_idcを構文要素及びアクセスユニットの1に等しいstore_ref_base_pic_flag構文要素と呼ばれるアクセスユニットのすべての層の表現と基本品質レイヤ表現をデコードして得られた参照ピクチャベース品質層表現の層間予測によって。参照ベースピクチャは、復号化プロセスの出力ではなく、参照ベースピクチャのサンプルが復号化順で後続のピクチャの復号処理におけるインター予測のために使用することができます。参照ベースピクチャは基準基地フィールドまたは基準ベースフレームの総称です。
scalable bitstream: A bitstream with the property that one or more bitstream subsets that are not identical to the scalable bitstream form another bitstream that conforms to the SVC specification [H.264].
スケーラブルビットストリーム：スケーラブル・ビットストリームと同一ではないである1つ以上のビットストリームのサブセットはSVC仕様[264]に準拠して別のビットストリームを形成する特性を有するビットストリーム。
target dependency representation: The dependency representation of an access unit that is associated with the largest value of the dependency_id syntax element for all dependency representations of the access unit.
アクセスユニットのすべての依存関係の表現のためのdependency_id構文要素の最大値に関連付けられているアクセスユニットの依存性表現：依存関係の表現を標的とします。
target layer representation: The layer representation of the target dependency representation of an access unit that is associated with the largest value of the quality_id syntax element for all layer representations of the target dependency representation of the access unit.
アクセスユニットのターゲット依存表現のすべてのレイヤ表現のためquality_id構文要素の最大値に関連付けられているアクセスユニットのターゲット依存表現の層表現：層表現を標的とします。
anchor layer representation: An anchor layer representation is such a layer representation that, if decoding of the operation point corresponding to the layer starts from the access unit containing this layer representation, all the following layer representations of the layer, in output order, can be correctly decoded. The output order is defined in [H.264] as the order in which decoded pictures are output from the decoded picture buffer of the decoder. As H.264 does not specify the picture display process, this more general term is used instead of display order. An anchor layer representation is a random access point to the layer the anchor layer representation belongs. However, some layer representations, succeeding an anchor layer representation in decoding order but preceding the anchor layer representation in output order, may refer to earlier layer representations for inter prediction, and hence the decoding may be incorrect if random access is performed at the anchor layer representation.
アンカー層表現：アンカー層表現層に対応する操作点の復号は、この層の表現を含むアクセスユニットからの層の次のすべての層の表現を開始した場合、出力順にすることができる、ような層であります正しく復号。出力順序は、ピクチャは、デコーダの復号ピクチャバッファから出力された復号化順序として[264]で定義されています。 264は、画像表示処理が指定されていないとして、このより一般的な用語ではなく、表示順序を使用します。アンカー層表現は、アンカー層表現が属する層へのランダムアクセスポイントです。しかし、いくつかの層表現、復号順でアンカー層表現に続くが、出力順にアンカー層表現に先行する、インター予測のために、以前のレイヤ表現を指すことができる、とランダムアクセスがアンカー層で実行される場合、したがって復号が正しくない可能性があります表現。
AVC base layer: The subset of the SVC base layer in which all prefix NAL units (type 14) are removed. Note that this is equivalent to the term "base layer" as defined in Annex G of [H.264].
AVCベース層：すべてのプレフィックスNALユニット（タイプ14）が除去されたSVCベースレイヤのサブセット。これは、[264]の付属書Gで定義されるように、用語「ベース層」と等価であることに留意されたいです。
base RTP session: When multi-session transmission is used, the RTP session that carries the RTP stream containing the T0 AVC base layer or the T0 SVC base layer, and zero or more enhancement layers. This RTP session does not depend on any other RTP session as indicated by mechanisms defined in Section 7.2.3. The base RTP session may carry NAL units of NAL unit type equal to 14 and 15.
ベースRTPセッション：マルチセッション送信が使用され、T0 AVCベース層又はT0 SVCベース層、およびゼロ以上のエンハンスメントレイヤを含むRTPストリームを搬送するRTPセッション。 7.2.3項で定義されたメカニズムによって示されるように、このRTPセッションが他のRTPセッションに依存しません。ベースRTPセッションが14と15に等しいNALユニット型のNALユニットを運ぶことができます。
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. Note that this definition also exists in [RFC6184] in exactly the same form.
復号化順序番号（DON）：ペイロード構造内のフィールドまたはNALユニットの復号化順序を示す派生変数。 DONの値は、0〜65535の範囲内に含まれています。最大値に達した後、DONの値は、この定義にはまた、全く同じ形で、[RFC6184]に存在すること0注にラップアラウンド。
Empty NAL unit: A NAL unit with NAL unit type equal to 31 and sub-type equal to 1. An empty NAL unit consists of only the two-byte NAL unit header with an empty payload.
空のNALユニット：1に等しい31に等しいNALユニット・タイプとサブタイプを有するNALユニット空のNALユニットは、空のペイロードを持つ2つだけのバイトNALユニットヘッダから成ります。
enhancement RTP session: When multi-session transmission is used, an RTP session that is not the base RTP session. An enhancement RTP session typically contains an RTP stream that depends on at least one other RTP session as indicated by mechanisms defined in Section 7.2.3. A lower RTP session to an enhancement RTP session is an RTP session on which the enhancement RTP session depends. The lowest RTP session for a receiver is the RTP session that does not depend on any other RTP session received by the receiver. The highest RTP session for a receiver is the RTP session on which no other RTP session received by the receiver depends.
拡張RTPセッション：マルチセッション送信が使用され、ベースRTPセッションではないRTPセッション。拡張RTPセッションは、典型的には、7.2.3項で定義されたメカニズムによって示されるように少なくとも一つの他のRTPセッションに依存RTPストリームを含んでいます。拡張RTPセッションに低いRTPセッションが強調RTPセッションが依存するRTPセッションです。受信機のための最小RTPセッションが受信機によって受信された任意の他のRTPセッションに依存しないRTPセッションです。受信機のための最高のRTPセッションが受信機によって受信された他のRTPセッションが依存しないれたRTPセッションです。
cross-session decoding order number (CS-DON): A derived variable indicating NAL unit decoding order number over all NAL units within all the session-multiplexed RTP sessions that carry the same SVC bitstream.
クロスセッション復号順序番号（CS-DON）：同じSVCビットストリームを運ぶすべてのセッション多重RTPセッション内のすべてのNALユニット上NALユニットの復号化順序番号を示す派生変数。
default level: The level indicated by the profile-level-id parameter. In Session Description Protocol (SDP) Offer/Answer, the level is downgradable, i.e., the answer may either use the default level or a lower level. Note that this definition also exists in [RFC6184] in a slightly different form.
デフォルトレベル：プロファイルレベルIDパラメータによって示されるレベル。セッション記述プロトコル（SDP）オファー/アンサーでは、レベル、すなわち、回答がデフォルトレベルまたはより低いレベルを使用することができるいずれか、ダウングレードです。この定義はまた、わずかに異なる形で、[RFC6184]に存在することに留意されたいです。
default sub-profile: The subset of coding tools, which may be all coding tools of one profile or the common subset of coding tools of more than one profile, indicated by the profile-level-id parameter. In SDP Offer/Answer, the default sub-profile must be used in a symmetric manner, i.e., the answer must either use the same sub-profile as the offer or reject the offer. Note that this definition also exists in [RFC6184] in a slightly different form.
デフォルトサブプロファイル：つのプロファイルの全ての符号化ツールまたは複数のプロファイルの符号化ツールの共通サブセットとすることができるツールをコーディングのサブセット、プロファイルレベルIDパラメータによって示されます。 SDPオファー/アンサーでは、既定のサブプロファイルが対称に使用されなければならない、すなわち、答えが提供同じサブプロファイルを使用するか、または申し出を拒絶しなければならないのいずれか。この定義はまた、わずかに異なる形で、[RFC6184]に存在することに留意されたいです。
enhancement layer: A layer in which at least one of the values of dependency_id or quality_id is higher than 0, or a layer in which none of the NAL units is associated with the value of temporal_id equal to 0. An operation point constructed using the maximum temporal_id, dependency_id, and quality_id values associated with an enhancement layer may or may not conform to one or more of the profiles specified in Annex A of [H.264].
エンハンスメントレイヤ：のdependency_id又はquality_idの値の少なくとも一方が0よりも高いされた層、またはNALユニットのいずれも最大値を使用して構築動作点0に等しいtemporal_idの値に関連付けられていないされた層temporal_idは、エンハンスメントレイヤに関連付けられているのdependency_id、及びquality_id値または[264]の付録Aで指定されたプロファイルの1つ以上に準拠してもしなくてもよいです。
H.264/AVC compatible: The property of a bitstream subset of conforming to one or more of the profiles specified in Annex A of [H.264].
H.264 / AVC互換：[264]の付録Aで指定されたプロファイルの1つまたは複数に準拠のビットストリームサブセットの特性。
intra layer representation: A layer representation that contains only slices that use intra prediction, and hence do not refer to any earlier layer representation in decoding order in the same layer. Note that in SVC intra prediction includes intra-layer intra prediction as well as inter-layer intra prediction.
イントラレイヤ表現：同一層に復号化順に以前のレイヤ表現を参照しない、したがってイントラ予測を使用して、スライスのみを含む層表現。 SVCイントラ予測でイントラレイヤのイントラ予測、ならびにインターレイヤイントラ予測を含むことに留意されたいです。
layer: A bitstream subset in which all NAL units of type 1, 5, 12, 14, or 20 have the same values of dependency_id and quality_id, either directly through their NAL unit header (for NAL units of type 14 or 20) or through association to a prefix (type 14) NAL unit (for NAL unit type 1, 5, or 12). A layer may contain NAL units associated with more than one values of temporal_id.
層：タイプ1、5、12、14、または20の全てのNALユニットがのdependency_id及びquality_idの同じ値を有するビットストリームサブセット、直接的（タイプ14または20のNALユニットのため）、それらのNALユニットヘッダを介して、または貫通（NALユニット・タイプ1,5、または12）のプレフィックス（タイプ14）NALユニットに関連付け。層は、temporal_idの複数の値に関連する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 their contents. Note that this definition also exists in [RFC6184] in exactly the same form.
メディアアウェアネットワーク要素（MANE）：ネットワーク要素、例えばRTPペイロードヘッダやRTPペイロードの特定の側面を解析し、その内容に反応することができるミドルまたはアプリケーション層ゲートウェイとして。この定義はまた、全く同じ形で、[RFC6184]に存在することに留意されたいです。
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 Secure Real-time Transport Protocol (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 and remove those packets whose elimination produces the least adverse effect on the user experience. After dropping packets, MANEs must rewrite RTCP packets to match the changes to the RTP packet stream as specified in Section 7 of [RFC3550].
有益な注意：MANEの概念はMANEは、シグナリングを知っていなければならないという点で、通常のルータやゲートウェイを超えて（例えば、メディアストリームのペイロードタイプのマッピングについて学ぶために）、そしてその中でそれが時に信頼されなければならセキュアリアルタイム転送プロトコル（SRTP）での作業。マーネスを使用することの利点は、パケットがメディア符号化のニーズに応じてドロップすることを可能にするということです。 MANEは、特定のリンク上の混雑に起因するパケットを廃棄する必要がある場合たとえば、それは、その除去のユーザーエクスペリエンスに最も悪影響を生じ、それらのパケットを識別して削除することができます。パケットをドロップした後、マネスは、[RFC3550]のセクション7で指定されるようにRTPパケットストリームへの変更と一致するようにRTCPパケットを書き換えなければなりません。
multi-session transmission: The transmission mode in which the SVC stream is transmitted over multiple RTP sessions. Dependency between RTP sessions MUST be signaled according to Section 7.2.3 of this memo.
マルチセッション送信：SVCストリームは、複数のRTPセッションを介して送信される送信モード。 RTPセッションの間の依存関係は、このメモのセクション7.2.3に応じて合図しなければなりません。
NAL unit decoding order: A NAL unit order that conforms to the constraints on NAL unit order given in Section G.7.4.1.2 in [H.264]. Note that this definition also exists in [RFC6184] in a slightly different form.
NALユニットの復号化順序：[264]に、セクションG.7.4.1.2で与えられたNALユニットの順序の制約に準拠するNALユニットの順序。この定義はまた、わずかに異なる形で、[RFC6184]に存在することに留意されたいです。
NALU-time: The value that the RTP timestamp would have if the NAL unit would be transported in its own RTP packet. Note that this definition also exists in [RFC6184] in exactly the same form.
NALU - 時間：NALユニットは、独自のRTPパケットで輸送されるかどうRTPタイムスタンプを持っています値。この定義はまた、全く同じ形で、[RFC6184]に存在することに留意されたいです。
operation point: An operation point is identified by a set of values of temporal_id, dependency_id, and quality_id. A bitstream corresponding to an operation point can be constructed by removing all NAL units associated with a higher value of dependency_id, and all NAL units associated with the same value of dependency_id but higher values of quality_id or temporal_id. An operation point bitstream conforms to at least one of the profiles defined in Annex A or G of [H.264], and offers a representation of the original video signal at a certain fidelity.
動作点：動作点はtemporal_id、のdependency_id、及びquality_idの値のセットによって識別されます。動作点に対応するビットストリームのdependency_idの高い値とのdependency_idの同じ値が、quality_id又はtemporal_idの高い値に関連付けられたすべてのNALユニットに関連付けられたすべてのNALユニットを除去することによって構築することができます。動作点ビットストリームは、附属書A又はG [264]で定義されたプロファイルのうちの少なくとも一つに準拠し、そして特定の忠実度で元のビデオ信号の表現を提供します。
Informative note: Additional NAL units may be removed (with lower dependency_id or same dependency_id but lower quality_id) if they are not required for decoding the bitstream at the particular operation point. The resulting bitstream, however, may no longer conform to any of the profiles defined in Annex A or G of [H.264].
有益な注意：追加のNALユニットは、それらが特定の動作点でビットストリームをデコードするために必要とされない場合（下側のdependency_id又は同一のdependency_idより低いquality_idで）除去することができます。結果として得られるビットストリームは、しかし、もはや[264]の附属書A又はGで定義されたプロファイルのいずれかに準拠しなくてもよいです。
operation point representation: The set of all NAL units of an operation point within the same access unit.
動作点表現：同一のアクセスユニット内の動作点のすべてのNALユニットのセット。
RTP packet stream: A sequence of RTP packets with increasing sequence numbers (except for wrap-around), identical payload type and identical SSRC (Synchronization Source), carried in one RTP session. Within the scope of this memo, one RTP packet stream is utilized to transport one or more layers.
RTPパケットストリーム（ラップアラウンドを除く）増加するシーケンス番号を有するRTPパケットのシーケンス、1つのRTPセッションで運ば同じペイロードタイプと同じSSRC（同期ソース）。このメモの範囲内で、1つのRTPパケットストリームは、1つまたは複数の層を運搬するために利用されます。
single-session transmission: The transmission mode in which the SVC bitstream is transmitted over a single RTP session.
シングルセッション伝送：SVCビットストリームは、単一のRTPセッションを介して送信される送信モード。
SVC base layer: The layer that includes all NAL units associated with dependency_id and quality_id values both equal to 0, including prefix NAL units (NAL unit type 14).
SVCベース層：プレフィックスNALユニット（NALユニットタイプ14）を含む、0に等しいの両方のdependency_id及びquality_id値に関連付けられたすべてのNALユニットを含む層。
SVC enhancement layer: A layer in which at least one of the values of dependency_id or quality_id is higher than 0. An operation point constructed using the maximum dependency_id and quality_id values and any temporal_id value associated with an SVC enhancement layer does not conform to any of the profiles specified in Annex A of [H.264].
SVCエンハンスメントレイヤ：のdependency_id又はquality_idの値の少なくとも一方が最大のdependency_id及びquality_id値を使用して構築され動作点0より高く、SVCエンハンスメントレイヤに関連する任意のtemporal_id値のいずれにも適合しないれた層[264]の付録Aで指定プロファイル。
SVC NAL unit: A NAL unit of NAL unit type 14, 15, or 20 as specified in Annex G of [H.264].
SVC NALユニット：NALユニット・タイプ14、15、又は20のNALユニット[264]の付属書Gで指定されるように。
SVC NAL unit header: A four-byte header resulting from the addition of a three-byte SVC-specific header extension added in NAL unit types 14 and 20.
SVC NALユニットヘッダ：3バイトSVC固有のヘッダ拡張の添加に起因する4バイトのヘッダは、NALユニット・タイプ14と20に加えました。
SVC RTP session: Either the base RTP session or an enhancement RTP session.
SVC RTPセッションベースRTPセッションまたは拡張RTPセッションのいずれかです。
T0 AVC base layer: A subset of the AVC base layer constructed by removing all VCL NAL units associated with temporal_id values higher than 0 and non-VCL NAL units and SEI messages associated only with the VCL NAL units being removed.
T0 AVCベース層：temporal_idが0よりも高い値と非VCL NALユニットのみVCL NALユニットは除去されるに関連付けられたSEIメッセージに関連付けられたすべてのVCL NALユニットを除去することによって構築AVCベース層の部分集合。
T0 SVC base layer: A subset of the SVC base layer constructed by removing all VCL NAL units associated with temporal_id values higher than 0 as well as prefix NAL units, non-VCL NAL units, and SEI messages associated only with the VCL NAL units being removed.
T0 SVCベース層：temporal_id 0並びに前置NALユニット、非VCL NALユニット、及びだけであるVCL NALユニットに関連付けられたSEIメッセージよりも高い値に関連付けられたすべてのVCL NALユニットを除去することによって構築SVCベースレイヤのサブセット削除しました。
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. Note that this definition also exists in [RFC6184] in exactly the same form.
送信順序：（モジュロ演算で）RTPシーケンス番号の昇順にパケットの順序。集約パケット内に、NALユニットの送信順序は、パケット内のNALユニットの出現順序と同じです。この定義はまた、全く同じ形で、[RFC6184]に存在することに留意されたいです。
In addition to the abbreviations defined in [RFC6184], the following abbreviations are used in this memo.
[RFC6184]で定義された略語に加えて、以下の略語は、このメモで使用されています。
CGS: Coarse-Grain Scalability CS-DON: Cross-Session Decoding Order Number MGS: Medium-Grain Scalability MST: Multi-Session Transmission PACSI: Payload Content Scalability Information SST: Single-Session Transmission SNR: Signal-to-Noise Ratio SVC: Scalable Video Coding
CGS：粗粒スケーラビリティCS-DON：クロスセッション解読注文番号MGS：ミディアムグレインスケーラビリティMST：マルチセッション伝送PACSI：ペイロードコンテンツスケーラビリティ情報SST：単一セッション伝送SNR：信号対雑音比のSVC：スケーラブルビデオコーディング
In addition to Section 5.1 of [RFC6184], the following rules apply.
[RFC6184]のセクション5.1に加えて、次の規則が適用されます。
o Setting of the M bit:
Mビットの入出力設定：
The M bit of an RTP packet for which the packet payload is an NI-MTAP MUST be equal to 1 if the last NAL unit, in decoding order, of the access unit associated with the RTP timestamp is contained in the packet.
RTPタイムスタンプに関連付けられているアクセスユニットの復号順序における最後のNALユニットは、パケットに含まれている場合、RTPパケットのMビットはれるパケットペイロードは、NI-MTAPが1に等しくなければならないです。
o Setting of the RTP timestamp:
RTPタイムスタンプのO設定：
For an RTP packet for which the packet payload is an empty NAL unit, the RTP timestamp must be set according to Section 4.10.
パケットペイロードが空NALユニットされたRTPパケットを、RTPタイムスタンプは、4.10節に応じて設定されなければなりません。
For an RTP packet for which the packet payload is a PACSI NAL unit, the RTP timestamp MUST be equal to the NALU-time of the next non-PACSI NAL unit in transmission order. Recall that the NALU-time of a NAL unit in an MTAP is defined in [RFC6184] as the value that the RTP timestamp would have if that NAL unit would be transported in its own RTP packet.
パケットペイロードがPACSI NALユニットされたRTPパケットを、RTPタイムスタンプは、伝送順序における次の非PACSI NALユニットのNALUタイムに等しくなければなりません。 MTAPにおけるNALユニットのNALUタイムは、そのNALユニットは、自身のRTPパケットで輸送される場合、RTPタイムスタンプを有することが値として[RFC6184]で定義されていることを思い出してください。
o Setting of the SSRC:
SSRCのO設定：
For both SST and MST, the SSRC values MUST be set according to [RFC3550].
SSTとMSTの両方について、SSRC値は[RFC3550]に応じて設定しなければなりません。
This memo specifies a NAL unit extension mechanism to allow for introduction of new types of NAL units, beyond the three NAL unit types left undefined in [RFC6184] (i.e., 0, 30, and 31). The extension mechanism utilizes the NAL unit type value 31 and is specified as follows. When the NAL unit type value is equal to 31, the one-byte NAL unit header consisting of the F, NRI, and Type fields as specified in Section 1.1.3 is extended by one additional octet, which consists of a 5-bit field named Subtype and three 1-bit fields named J, K, and L, respectively. The additional octet is shown in the following figure.
3つのNALユニット・タイプは[RFC6184]（即ち、0、30、および31）に未定義のまま超えこのメモは、NALユニットの新しいタイプの導入を可能にするためにNALユニットの拡張機構を指定します。拡張機構は、NALユニット・タイプ値31を利用し、次のように指定されています。 NALユニット・タイプの値は31に等しい場合、F、NRI、そしてタイプフィールドからなる1バイトNALユニットヘッダはセクション1.1.3で指定されるように5ビットのフィールドで構成されて一つの追加のオクテットによって拡張されますサブタイプ名前と3つの1ビットのフィールドは、それぞれ、J、K、およびLと命名しました。追加のオクテットは、次の図に示します。
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
| Subtype |J|K|L|
+---------------+
The Subtype value determines the (extended) NAL unit type of this NAL unit. The interpretation of the fields J, K, and L depends on the Subtype. The semantics of the fields are as follows.
サブタイプ値は、このNALユニットの（拡張）NALユニット・タイプを決定します。フィールドの解釈J、K、およびLは、サブタイプに依存します。次のようにフィールドのセマンティクスがあります。
When Subtype is equal to 1, the NAL unit is an empty NAL unit as specified in Section 4.10. When Subtype is equal to 2, the NAL unit is an NI-MTAP NAL unit as specified in Section 4.7.1. All other values of Subtype (0, 3-31) are reserved for future extensions, and receivers MUST ignore the entire NAL unit when Subtype is equal to any of these reserved values.
サブタイプが1に等しい場合、NALユニットは、セクション4.10で指定されるように、空のNALユニットです。サブタイプが2に等しいとき、セクション4.7.1で指定されるように、NALユニットは、NI-MTAPのNALユニットです。サブタイプ（0、3-31）の他のすべての値は、将来の拡張のために予約されており、サブタイプはこれらの予約値のいずれかに等しいとき受信機は全体のNALユニットを無視しなければなりません。
The structure and semantics of the NAL unit header according to the H.264 specification [H.264] were introduced in Section 1.1.3. This section specifies the extended semantics of the NAL unit header fields F, NRI, I, PRID, DID, QID, TID, U, and D, according to this memo. When the Type field is equal to 31, the semantics of the fields in the extension NAL unit header were specified in Section 4.2.1.
H.264仕様に従って構造及びNALユニットヘッダの意味は[264]は、セクション1.1.3で導入されました。このセクションでは、このメモによれば、NALユニットヘッダフィールドF、NRI、I、PRID、DID、QID、TID、U、及びDの拡張セマンティクスを指定します。タイプフィールドが31に等しいとき、拡張NALユニットヘッダにおけるフィールドのセマンティクスはセクション4.2.1で指定されました。
The semantics of F specified in Section 5.3 of [RFC6184] also apply in this memo. That is, a value of 0 for F indicates that the NAL unit type octet and payload should not contain bit errors or other syntax violations, whereas a value of 1 for F indicates that the NAL unit type octet and payload may contain bit errors or other syntax violations. MANEs SHOULD set the F bit to indicate bit errors in the NAL unit.
[RFC6184]の5.3節で指定されたFの意味論も、このメモに適用されます。すなわち、F 0の値は、F 1の値は、NALユニットタイプオクテットペイロードは、ビットエラー又は他を含むことができることを示しているのに対し、NALユニットタイプオクテットペイロードは、ビットエラー又は他の構文違反を含むべきではないことを示しています構文違反。マネスは、NALユニット内のビットエラーを示すために、Fビットを設定する必要があります。
For NRI, for a bitstream conforming to one of the profiles defined in Annex A of [H.264] and transported using [RFC6184], the semantics specified in Section 5.3 of [RFC6184] apply, i.e., NRI also indicates the relative importance of NAL units. For a bitstream conforming to one of the profiles defined in Annex G of [H.264] and transported using this memo, in addition to the semantics specified in Annex G of [H.264], NRI also indicates the relative importance of NAL units within a layer.
NRIは、[264]及び[RFC6184]を使用して搬送の付属書Aに定義されたプロファイルのいずれかに準拠するビットストリームのために、[RFC6184]適用、すなわち、セクション5.3で指定されたセマンティクスは、NRIはまた、相対的な重要性を示していますNALユニット。 [264]このメモを使用して搬送の付属書Gで定義されたプロファイルのいずれかに準拠するビットストリームは、[264]の付属書Gで指定された意味論に加えて、NRIもNALユニットの相対的な重要性を示しています層内。
For I, in addition to the semantics specified in Annex G of [H.264], according to this memo, MANEs MAY use this information to protect NAL units with I equal to 1 better than NAL units with I equal to 0. MANEs MAY also utilize information of NAL units with I equal to 1 to decide when to forward more packets for an RTP packet stream. For example, when it is detected that spatial layer switching has happened such that the operation point has changed to a higher value of DID, MANEs MAY start to forward NAL units with the higher value of DID only after forwarding a NAL unit with I equal to 1 with the higher value of DID.
私がNALユニットよりも優れ1に等しいと私が0鬣に等しいと私のために、[264]の付属書Gで指定された意味論に加えて、このメモによると、マネスは、NALユニットを保護するためにこの情報を使用してもよいですIは、RTPパケットストリームのためのより多くのパケットを転送するタイミングを決定するために1に等しいともNALユニットの情報を利用します。空間レイヤスイッチング動作点がDIDの高い値に変更されているように起こっていることが検出された場合、例えば、マネスは、より高い値を有するNALユニットを転送するために開始することができるだけでNALユニットを転送した後、私は、に等しいDID DIDの高い値を持つ1。
Note that, in the context of this section, "protecting a NAL unit" means any RTP or network transport mechanism that could improve the probability of successful delivery of the packet conveying the NAL unit, including applying a Quality of Service (QoS) enabled network, Forward Error Correction (FEC), retransmissions, and advanced scheduling behavior, whenever possible.
「NALユニットを保護する」サービス品質（QoS）を適用することを含むNALユニットを、搬送パケットの配信成功の確率を向上させることができ、任意のRTPまたはネットワークトランスポート機構を意味し、このセクションの文脈において、なお、ネットワークを有効にし、前方誤り訂正（FEC）、再送信、および高度なスケジューリングの挙動、可能な限り。
For PRID, the semantics specified in Annex G of [H.264] apply. Note that MANEs implementing unequal error protection MAY use this information to protect NAL units with smaller PRID values better than those with larger PRID values, for example, by including only the more important NAL units in a FEC protection mechanism. The importance for the decoding process decreases as the PRID value increases.
PRIDは、[264]の付属書Gで指定された意味論を適用します。不均一誤り保護を実装マネスは、FEC保護メカニズムの唯一のより重要なNALユニットを含むことによって、例えば、より良い、より大きなPRID値を持つものよりも小さいPRID値でNALユニットを保護するために、この情報を使用することができることに注意してください。復号化処理のための重要性は、PRID値が増加するにつれて減少します。
For DID, QID, or TID, in addition to the semantics specified in Annex G of [H.264], according to this memo, values of DID, QID, or TID indicate the relative importance in their respective dimension. A lower value of DID, QID, or TID indicates a higher importance if the other two components are identical. MANEs MAY use this information to protect more important NAL units better than less important NAL units.
ため、QID、またはTIDは、[264]の付属書Gで指定された意味論に加えて、このメモによれば、DID、QID、またはTIDの値は、それぞれの次元における相対的な重要性を示しました。他の2つの成分が同一であれば、DIDの低い値は、QID、またはTIDは、より高い重要性を示しています。鬣はそれほど重要NALユニットよりも優れた多くの重要なNALユニットを保護するために、この情報を使用することができます。
For U, in addition to the semantics specified in Annex G of [H.264], according to this memo, MANEs MAY use this information to protect NAL units with U equal to 1 better than NAL units with U equal to 0.
Uは、[264]の付属書Gで指定された意味論に加えて、このメモによると、マネスは0に等しいU有するNALユニットよりも優れ1に等しいU有するNALユニットを保護するために、この情報を使用することができます。
For D, in addition to the semantics specified in Annex G of [H.264], according to this memo, MANEs MAY use this information to determine whether a given NAL unit is required for successfully decoding a certain Operation Point of the SVC bitstream, hence to decide whether to forward the NAL unit.
Dは、[264]の付属書Gで指定された意味論に加えて、このメモによると、マネスは、所与のNALユニットが正常SVCビットストリームの特定の動作ポイントをデコードするために必要とされるかどうかを決定するためにこの情報を使用することができますしたがって、NALユニットを転送するかどうかを決定します。
The NAL unit structure is central to H.264/AVC, [RFC6184], as well as SVC and this memo. In H.264/AVC and SVC, all coded bits for representing a video signal are encapsulated in NAL units. In [RFC6184], each RTP packet payload is structured as a NAL unit, which contains one or a part of one NAL unit specified in H.264/AVC, or aggregates one or more NAL units specified in H.264/AVC.
NALユニットの構造は、H.264 / AVC、[RFC6184]、並びにSVCこのメモの中心です。 H.264 / AVCおよびSVCにおいては、ビデオ信号を表現するすべての符号化ビットは、NALユニット内にカプセル化されています。 [RFC6184]で、各RTPパケットのペイロードは、一つが含まれているNALユニット、またはH.264 / AVCに指定さNALユニットの一部として構成、またはH.264 / AVCに指定された1つのまたはそれ以上のNALユニットを集約しています。
[RFC6184] specifies three basic payload structures (in Section 5.2 of [RFC6184]): single NAL unit packet, aggregation packet, fragmentation unit, and six new types (24 to 29) of NAL units. The value of the Type field of the RTP packet payload header (i.e., the first byte of the payload) may be equal to any value from 1 to 23 for a single NAL unit packet, any value from 24 to 27 for an aggregation packet, and 28 or 29 for a fragmentation unit.
[RFC6184]は三つの基本的なペイロード構造を指定する（セクション5.2 [RFC6184]）：単一NALユニットパケット、アグリゲーションパケット、断片化部、及びNALユニットの6つの新しいタイプ（24〜29）。 RTPパケットのペイロードヘッダ（即ち、ペイロードの最初のバイト）のTypeフィールドの値は、単一NALユニットパケットのために1から23に集約パケット24から27までの任意の値の任意の値に等しくてもよいです、および断片化ユニット28または29。
In addition to the NAL unit types defined originally for H.264/AVC, SVC defines three new NAL unit types specifically for SVC: coded slice in scalable extension NAL units (type 20), prefix NAL units (type 14), and subset sequence parameter set NAL units (type 15), as described in Section 1.1.
スケーラブル拡張NALユニット（タイプ20）、前置NALユニット（タイプ14）、及びサブセットシーケンスで符号化されたスライス：H.264 / AVCのために最初に定義NALユニット・タイプに加えて、SVCは、SVCのために特別つの新しいNALユニットタイプを定義しますパラメータセットNALユニットのセクション1.1に記載されているように（タイプ15）。
This memo further introduces three new types of NAL units, PACSI NAL unit (NAL unit type 30) as specified in Section 4.9, empty NAL unit (type 31, subtype 1) as specified in Section 4.10, and NI-MTAP NAL unit (type 31, subtype 2) as specified in Section 4.7.1.
セクション4.9、空のNALユニット（タイプ31、サブタイプ1）で指定されるように4.10、およびNI-MTAPのNALユニットで指定されるように、このメモは、さらにタイプ（NALユニットの三の新しいタイプ、PACSI NALユニット（NALユニットタイプ30）を導入します31、セクション4.7.1で指定されるように、サブタイプ2）。
The RTP packet payload structure in [RFC6184] is maintained with slight extensions in this memo, as follows. Each RTP packet payload is still structured as a NAL unit, which contains one or a part of one NAL unit specified in H.264/AVC and SVC, or contains one PACSI NAL unit or one empty NAL unit, or aggregates zero or more NAL units specified in H.264/AVC and SVC, zero or one PACSI NAL unit, and zero or more empty NAL units.
次のように[RFC6184]でRTPパケットのペイロードの構造は、このメモがわずかに拡張して維持されます。各RTPパケットのペイロードは、依然として一つまたはH.264 / AVCとSVCで指定NALユニットの一部を含む、または1つのPACSI NALユニットまたは1つの空のNALユニットが含まれ、またはゼロ以上のNALを集約NALユニットとして構成されていますH.264 / AVCとSVC、0または1つのPACSI NALユニット、およびゼロまたはそれ以上の空のNAL単位で指定された単位。
In this memo, one of the three basic payload structures, fragmentation unit, remains the same as in [RFC6184], and the other two, single NAL unit packet and aggregation packet, are extended as follows. The value of the Type field of the payload header may be equal to any value from 1 to 23, inclusive, and 30 to 31, inclusive, for a single NAL unit packet, and any value from 24 to 27, inclusive, and 31, for an aggregation packet. When the Type field of the payload header is equal to 31 and the Subtype field of the payload header is equal to 2, the packet is an aggregation packet (containing an NI-MTAP NAL unit). When the Type field of the payload header is equal to 31 and the Subtype field of the payload header is equal to 1, the packet is a single NAL unit packet (containing an empty NAL unit).
次のように、このメモでは、三つの基本的なペイロード構造体、断片化部、[RFC6184]の場合と同じままであり、他の二つの、単一NALユニットパケットとアグリゲーションパケットの一つは、拡張されます。ペイロードヘッダのTypeフィールドの値は、1から23までの任意の値に等しく包含、及び31から30、包括的、単一NALユニットパケットのために、24から27までの任意の値、包括的、及び31とすることができます集合パケットのために。ペイロードヘッダのタイプフィールドが31に等しく、ペイロードヘッダのサブタイプフィールドが2に等しい場合、パケットは、（NI-MTAPのNALユニットを含む）を集約パケットです。ペイロードヘッダのタイプフィールドが31に等しく、ペイロードヘッダのサブタイプフィールドが1に等しい場合、パケットが（空のNALユニットを含む）単一NALユニットパケットです。
Note that, in this memo, the length of the payload header varies depending on the value of the Type field in the first byte of the RTP packet payload. If the value is equal to 14, 20, or 30, the first four bytes of the packet payload form the payload header; otherwise, if the value is equal to 31, the first two bytes of the payload form the payload header; otherwise, the payload header is the first byte of the packet payload.
なお、このメモでは、ペイロードヘッダの長さは、RTPパケットペイロードの最初のバイトにおけるタイプフィールドの値に依存して変化します。値は14、20、または30に等しい場合、パケットペイロードの最初の4つのバイトは、ペイロードヘッダを形成します。値が31に等しい場合、ペイロードの最初の2つのバイトは、ペイロードヘッダを形成します。そうでない場合は、ペイロードヘッダは、パケットペイロードの最初のバイトです。
Table 1 lists the NAL unit types introduced in SVC and this memo and where they are described in this memo. Table 2 summarizes the basic payload structure types for all NAL unit types when they are directly used as RTP packet payloads according to this memo. Table 3 summarizes the NAL unit types allowed to be aggregated (i.e., used as aggregation units in aggregation packets) or fragmented (i.e., carried in fragmentation units) according to this memo.
表1は、それらがこのメモに記載されているSVCに導入NALユニットの種類と、このメモと。表2は、それらが直接このメモに係るRTPパケットのペイロードとして使用されているすべてのNALユニット・タイプの基本的なペイロード構造タイプをまとめたものです。表3に集約させNALユニットの種類をまとめたもの（すなわち、集約パケットに集約単位として使用される）または断片（すなわち、断片化単位で運ば）このメモに記載の方法。
Table 1. NAL unit types introduced in SVC and this memo
SVCこのメモに導入表1 NALユニットタイプ
Type Subtype NAL Unit Name Section Numbers
-----------------------------------------------------------
14 - Prefix NAL unit 1.1
15 - Subset sequence parameter set 1.1
20 - Coded slice in scalable extension 1.1
30 - PACSI NAL unit 4.9
31 0 reserved 4.2.1
31 1 Empty NAL unit 4.10
31 2 NI-MTAP 4.7.1
31 3-31 reserved 4.2.1
Table 2. Basic payload structure types for all NAL unit types when they are directly used as RTP packet payloads
表それらは直接RTPパケットのペイロードとして使用されている全てのNALユニットの種類2.基本的なペイロード構造タイプ
Type Subtype Basic Payload Structure
------------------------------------------
0 - reserved
1-23 - Single NAL Unit Packet
24-27 - Aggregation Packet
28-29 - Fragmentation Unit
30 - Single NAL Unit Packet
31 0 reserved
31 1 Single NAL Unit Packet
31 2 Aggregation Packet
31 3-31 reserved
Table 3. Summary of the NAL unit types allowed to be aggregated or fragmented (yes = allowed, no = disallowed, - = not applicable/not specified)
（ - =該当しない/指定されていない= YESせ、いいえ=禁止）凝集または断片化させNALユニット・タイプの表3に要約
Type Subtype STAP-A STAP-B MTAP16 MTAP24 FU-A FU-B NI-MTAP
-------------------------------------------------------------
0 - - - - - - - -
1-23 - yes yes yes yes yes yes yes
24-29 - no no no no no no no
30 - yes yes yes yes no no yes
31 0 - - - - - - -
31 1 yes no no no no no yes
31 2 no no no no no no no
31 3-31 - - - - - - -
This memo enables transmission of an SVC bitstream over one or more RTP sessions. If only one RTP session is used for transmission of the SVC bitstream, the transmission mode is referred to as single-session transmission (SST); otherwise (more than one RTP session is used for transmission of the SVC bitstream), the transmission mode is referred to as multi-session transmission (MST).
このメモは、一つ以上のRTPセッションに対して、SVCビットストリームの伝送を可能にします。唯一のRTPセッションがSVCビットストリームの送信に使用される場合、伝送モードはシングルセッション送信（SST）と呼ばれます。そうでない場合は（複数のRTPセッションがSVCビットストリームの伝送のために使用される）、伝送モードがマルチセッション送信（MST）と呼ばれます。
SST SHOULD be used for point-to-point unicast scenarios, while MST SHOULD be used for point-to-multipoint multicast scenarios where different receivers requires different operation points of the same SVC bitstream, to improve bandwidth utilizing efficiency.
MSTは、異なる受信機は、帯域幅利用効率を改善するために、同じSVCビットストリームの異なる動作点を必要とするポイント・ツー・マルチポイントのマルチキャストシナリオのために使用されるべきであるSSTは、ポイントツーポイントのユニキャストのシナリオのために使用されるべきです。
If the OPTIONAL mst-mode media type parameter (see Section 7.1) is not present, SST MUST be used; otherwise (mst-mode is present), MST MUST be used.
OPTIONAL MSTモードメディアタイプパラメータが（7.1節を参照）が存在しない場合、SSTを使用しなければなりません。そうでない場合（MSTモードが存在する）、MSTを使用しなければなりません。
When SST is in use, Section 5.4 of [RFC6184] applies with the following extensions.
SSTを使用している場合は、[RFC6184]の5.4節には、以下の拡張子を持つ適用されます。
The packetization modes specified in Section 5.4 of [RFC6184], namely, single NAL unit mode, non-interleaved mode, and interleaved mode, are also referred to as session packetization modes. Table 4 summarizes the allowed session packetization modes for SST.
[RFC6184]、すなわち、単一NALユニットモード、非インタリーブモード、およびインターリーブモードのセクション5.4で指定されたパケット化モードは、また、セッションのパケット化モードと呼ばれます。表4は、SSTのために許可されたセッションのパケット化モードをまとめたものです。
Table 4. Summary of allowed session packetization modes (denoted as "Session Mode" for simplicity) for SST (yes = allowed, no = disallowed)
SSTのため許可されたセッションのパケット化モードの表4.まとめ（簡略化のため、「セッションモード」と表記）（はい=許可、無=禁止）
Session Mode Allowed
-------------------------------------
Single NAL Unit Mode yes
Non-Interleaved Mode yes
Interleaved Mode yes
For NAL unit types in the range of 0 to 29, inclusive, the NAL unit types allowed to be directly used as packet payloads for each session packetization mode are the same as specified in Section 5.4 of [RFC6184]. For other NAL unit types, which are newly introduced in this memo, the NAL unit types allowed to be directly used as packet payloads for each session packetization mode are summarized in Table 5.
[RFC6184]のセクション5.4で指定されるように0〜29の範囲内のNALユニット・タイプのために、包括的な、NALユニット・タイプは直接セッションパケット化モードのパケットペイロードとして使用する同じであることができました。新たにこのメモで導入される他のNALユニット・タイプのために、NALユニット・タイプは、各セッションのパケット化モードのためのパケットペイロードは、表5に要約されているように直接使用することができました。
Table 5. New NAL unit types allowed to be directly used as packet payloads for each session packetization mode (yes = allowed, no = disallowed, - = not applicable/not specified)
テーブル直接セッションパケット化モードのパケットペイロードとして使用することを許可5.新しいNALユニットタイプ（= YESせ、いいえ=禁止、 - =該当しない/指定されていません）
Type Subtype Single NAL Non-Interleaved Interleaved
Unit Mode Mode Mode
-------------------------------------------------------------
30 - yes no no
31 0 - - -
31 1 yes yes no
31 2 no yes no
31 3-31 - - -
For MST, this memo specifies four MST packetization modes:
MSTのために、このメモは4つのMSTのパケット化モードを指定します。
o Non-interleaved timestamp based mode (NI-T);
O非インターリーブタイムスタンプベースモード（NI-T）。
o Non-interleaved cross-session decoding order number (CS-DON) based mode (NI-C);
O非インターリーブクロスセッション復号順序番号（CS-DON）ベースモード（NI-C）。
o Non-interleaved combined timestamp and CS-DON mode (NI-TC); and
O非インターリーブ合成タイムスタンプとCS-DONモード（NI-TC）。そして
o Interleaved CS-DON (I-C) mode.
OインターリーブCS-DON（I-C）モード。
These four modes differ in two ways. First, they differ in terms of whether NAL units are required to be transmitted within each RTP session in decoding order (i.e., non-interleaved), or they are allowed to be transmitted in a different order (i.e., interleaved).
これらの4つのモードは、2つの方法が異なります。まず、それらはNALユニットは復号順序（すなわち、非インターリーブ）における各RTPセッション内で送信する必要があるかどうかの点で異なる、またはそれらは異なる順序で送信されることが許可されている（即ち、インターリーブ）。
Second, they differ in the mechanisms they provide in order to recover the correct decoding order of the NAL units across all RTP sessions involved.
第二に、彼らが関与するすべてのRTPセッション間NALユニットの正しい復号化順序を回復するために提供するメカニズムが異なります。
The NI-T, NI-C, and NI-TC modes do not allow interleaving, and are thus targeted for systems that require relatively low end-to-end latency, e.g., conversational systems. The I-C mode allows interleaving and is thus targeted for systems that do not require very low end-to-end latency. The benefits of interleaving are the same as that of the interleaved mode specified in [RFC6184].
NI-T、NI-C、およびNI-TCモードは、インターリービングを許可しないので、比較的低いエンドツーエンド待ち時間を必要とするシステム、例えば、会話システムのために標的化されます。 I-Cモードでは、インターリーブすることができますので、非常に低いエンドツーエンドのレイテンシを必要としないシステムを対象としています。インターリービングの利点は[RFC6184]で指定されたインターリーブモードのものと同じです。
The NI-T mode uses timestamps to recover the decoding order of NAL units, whereas the NI-C and I-C modes both use the CS-DON mechanism (explained later) to do so. The NI-TC mode provides both timestamps and the CS-DON method; receivers in this case may choose to use either method for performing decoding order recovery. The MST packetization mode in use MUST be signaled by the value of the OPTIONAL mst-mode media type parameter. The used MST packetization mode governs which session packetization modes are allowed in the associated RTP sessions, which in turn govern which NAL unit types are allowed to be directly used as RTP packet payloads.
NI-Tモードは、NI-Cに対し、NALユニットの復号化順序を回復するためにタイムスタンプを使用して、I-Cの両方のモードそうする（後述）CS-DONメカニズムを使用します。 NI-TCモードは、タイムスタンプおよびCS-DON方法の両方を提供します。この場合、受信機は、復号順序の回復を実行するための方法のいずれかを使用することもできます。使用中のMSTパケット化モードは、オプションのMST-モードメディアタイプパラメータの値によってシグナリングされなければなりません。使用MSTパケット化モードは、パケット化モードが順番にNALユニットタイプを直接RTPパケットのペイロードとして使用することが許可されている支配関連するRTPセッションに許可されているセッションを管理します。
Table 6 summarizes the allowed session packetization modes for NI-T, NI-C, and NI-TC. Table 7 summarizes the allowed session packetization modes for I-C.
表6は、NI-T、NI-C、およびNI-TCの許容セッションパケット化モードをまとめたものです。表7は、I-Cのために許可されたセッションのパケット化モードをまとめたものです。
Table 6. Summary of allowed session packetization modes (denoted as "Session Mode" for simplicity) for NI-T, NI-C, and NI-TC (yes = allowed, no = disallowed)
NI-T、NI-C、およびNI-TC（= YESせ、なし=禁止）のために（簡単にするために "セッションモード" と表記）許容セッションパケット化モードの表6.概要
Session Mode Base Session Enhancement Session
-----------------------------------------------------------
Single NAL Unit Mode yes no
Non-Interleaved Mode yes yes
Interleaved Mode no no
Table 7. Summary of allowed session packetization modes (denoted as "Session Mode" for simplicity) for I-C (yes = allowed, no = disallowed)
I-C（= yesと認め、なし=禁止）のために（簡単にするために、「セッションモード」と表記）許可セッションパケット化モードの表7.まとめ
Session Mode Base Session Enhancement Session
-----------------------------------------------------------
Single NAL Unit Mode no no
Non-Interleaved Mode no no
Interleaved Mode yes yes
For NAL unit types in the range of 0 to 29, inclusive, the NAL unit types allowed to be directly used as packet payloads for each session packetization mode are the same as specified in Section 5.4 of [RFC6184]. For other NAL unit types, which are newly introduced in this memo, the NAL unit types allowed to be directly used as packet payloads for each allowed session packetization mode for NI-T, NI-C, NI-TC, and I-C are summarized in Tables 8, 9, 10, and 11, respectively.
[RFC6184]のセクション5.4で指定されるように0〜29の範囲内のNALユニット・タイプのために、包括的な、NALユニット・タイプは直接セッションパケット化モードのパケットペイロードとして使用する同じであることができました。新たにこのメモで導入される他のNALユニット・タイプのために、NALユニット・タイプは、NI-T、NI-C、NI-TC、およびICの各許容セッションパケット化モードのパケットペイロードをに要約されているように直接使用することを許可しますそれぞれ表8、9、10、11、。
Table 8. New NAL unit types allowed to be directly used as packet payloads for each allowed session packetization mode when NI-T is in use (yes = allowed, no = disallowed, - = not applicable/not specified)
表NI-Tの使用時に直接許可セッションパケット化モードのパケットペイロードとして使用することを許可8.新しいNALユニットタイプ（= YESせ、いいえ=禁止、 - =該当しない/指定されていません）
Type Subtype Single NAL Non-Interleaved
Unit Mode Mode
---------------------------------------------------
30 - yes no
31 0 - -
31 1 yes yes
31 2 no yes
31 3-31 - -
Table 9. New NAL unit types allowed to be directly used as packet payloads for each allowed session packetization mode when NI-C is in use (yes = allowed, no = disallowed, - = not applicable/not specified)
表NI-Cが使用されているときに直接許可セッションパケット化モードのパケットペイロードとして使用することを許可9.新しいNALユニットタイプ（= YESせ、いいえ=禁止、 - =該当しない/指定されていません）
Type Subtype Single NAL Non-Interleaved
Unit Mode Mode
---------------------------------------------------
30 - yes yes
31 0 - -
31 1 no no
31 2 no yes
31 3-31 - -
Table 10. New NAL unit types allowed to be directly used as packet payloads for each allowed session packetization mode when NI-TC is in use (yes = allowed, no = disallowed, - = not applicable/not specified)
表NI-TCが使用されているときに直接許可セッションパケット化モードのパケットペイロードとして使用することを許可10.新しいNALユニットタイプ（= YESせ、いいえ=禁止、 - =該当しない/指定されていません）
Type Subtype Single NAL Non-Interleaved
Unit Mode Mode
---------------------------------------------------
30 - yes yes
31 0 - -
31 1 yes yes
31 2 no yes
31 3-31 - -
Table 11. New NAL unit types allowed to be directly used as packet payloads for the allowed session packetization mode when I-C is in use (yes = allowed, no = disallowed, - = not applicable/not specified)
表I-Cを使用しているときに直接許可セッションパケット化モードのパケットペイロードとして使用することを許可11.新しいNALユニットタイプ（= YESせ、いいえ=禁止、 - =該当しない/指定されていません）
Type Subtype Interleaved Mode
------------------------------------
30 - no
31 0 -
31 1 no
31 2 no
31 3-31 -
When MST is in use and the MST packetization mode in use is NI-C, empty NAL units (type 31, subtype 1) MUST NOT be used, i.e., no RTP packet is allowed to contain one or more empty NAL units.
MSTが使用され、使用中MSTパケット化モードは、NI-Cである場合、空のNALユニット（タイプ31、サブタイプ1）を使用してはいけません、すなわち、何のRTPパケットは、一個の以上の空のNALユニットを含むことが許されません。
When MST is in use and the MST packetization mode in use is I-C, both empty NAL units (type 31, subtype 1) and NI-MTAP NAL units (type 31, subtype 2) MUST NOT be used, i.e., no RTP packet is allowed to contain one or more empty NAL units or an NI-MTAP NAL unit.
MSTが使用され、使用中MSTパケット化モードを使用してはいけませんIC、両方の空のNALユニット（タイプ31、サブタイプ1）とNI-MTAPのNALユニット（タイプ31、サブタイプ2）、すなわちである場合、何のRTPパケットではありません一の以上の空のNALユニットまたはNI-MTAPのNALユニットを含有させます。
Section 5.6 of [RFC6184] applies with the following extensions.
[RFC6184]のセクション5.6には、以下の拡張子を持つ適用されます。
The payload of a single NAL unit packet MAY be a PACSI NAL unit (Type 30) or an empty NAL unit (Type 31 and Subtype 1), in addition to a NAL unit with NAL unit type equal to any value from 1 to 23, inclusive.
単一NALユニットパケットのペイロードがPACSI NALユニット（タイプ30）または空のNALユニット（タイプ31およびサブタイプ1）であってもよい、1から23までの任意の値に等しいNALユニット・タイプを有するNALユニットに加えて、包括的。
If the Type field of the first byte of the payload is not equal to 31, the payload header is the first byte of the payload. Otherwise, (the Type field of the first byte of the payload is equal to 31), the payload header is the first two bytes of the payload.
ペイロードの最初のバイトのタイプフィールドが31に等しくない場合、ペイロードヘッダはペイロードの最初のバイトです。そうでない場合は、（ペイロードの最初のバイトのタイプフィールドが31に等しい）、ペイロードヘッダはペイロードの最初の2バイトです。
In addition to Section 5.7 of [RFC6184], the following applies in this memo.
[RFC6184]のセクション5.7に加えて、以下はこのメモに当てはまります。
One new NAL unit type introduced in this memo is the non-interleaved multi-time aggregation packet (NI-MTAP). An NI-MTAP consists of one or more non-interleaved multi-time aggregation units.
このメモで導入された1つの新しいNALユニット型は、非インターリーブマルチタイム集約パケット（NI-MTAP）です。 NI-MTAPは、1つ以上の非インターリーブマルチタイム・アグリゲーションユニットから構成される。
The NAL units contained in NI-MTAPs MUST be aggregated in decoding order.
NI-MTAPsに含まれるNALユニット復号順序に集約されなければなりません。
A non-interleaved multi-time aggregation unit for the NI-MTAP consists of 16 bits of unsigned size information of the following NAL unit (in network byte order), and 16 bits (in network byte order) of timestamp offset (TS offset) for the NAL unit. The structure is presented in Figure 1. The starting or ending position of an aggregation unit within a packet may or may not be on a 32-bit word boundary. The NAL units in the NI-MTAP are ordered in NAL unit decoding order.
NI-MTAP用非インターリーブマルチタイム集約ユニットは、（ネットワークバイト順で）（ネットワーク・バイト順で）次のNALユニットの符号なしサイズ情報の16ビット、および16ビットで構成されたタイムスタンプのオフセット（TSオフセット） NALユニットのために。構造は図1に提示されている起動や32ビットワード境界上であってもなくてもよいパケット内に集約ユニットの終了位置。 NI-MTAP内のNALユニットはNALユニットの復号化順に順序付けられます。
The Type field of the NI-MTAP MUST be set equal to "31".
NI-MTAPのTypeフィールドを「31」に等しく設定されなければなりません。
The F bit MUST be set to 0 if all the F bits of the aggregated NAL units are zero; otherwise, it MUST be set to 1.
凝集したNALユニットの全てのFビットがゼロである場合、Fビットが0に設定しなければなりません。それ以外の場合は、1に設定しなければなりません。
The value of NRI MUST be the maximum value of NRI across all NAL units carried in the NI-MTAP packet.
NRIの値は、NI-MTAPパケットで運ばれるすべてのNALユニットにわたってNRIの最大値である必要があります。
The field Subtype MUST be equal to 2.
フィールドのサブタイプは、2に等しくなければなりません。
If the field J is equal to 1, the optional DON field MUST be present for each of the non-interleaved multi-time aggregation units. For SST, the J field MUST be equal to 0. For MST, in the NI-T mode the J field MUST be equal to 0, whereas in the NI-C or NI-TC mode the J field MUST be equal to 1. When the NI-C or NI-TC mode is in use, the DON field, when present, MUST represent the CS-DON value for the particular NAL unit as defined in Section 6.2.2.
フィールドJが1に等しい場合、任意DONフィールドが非インターリーブマルチタイム・アグリゲーションユニットの各々のために存在していなければなりません。 SSTは、Jフィールドは、NI-CまたはNI-TCモードでJフィールドが1に等しくなければならないのに対し、NI-TモードでJフィールドは、0に等しくなければならない、MSTについて0に等しくなければなりません。 NI-CまたはNI-TCモードが使用されている場合、セクション6.2.2で定義されるように、DONフィールドが、存在する場合、特定のNALユニットのためのCS-DON値を表現しなければなりません。
The fields K and L MUST be both equal to 0.
フィールドは、K及びLは0に等しいの両方でなければなりません。
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 | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DON (optional) | |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Non-interleaved multi-time aggregation unit for NI-MTAP
NI-MTAP図1.非インターリーブマルチタイム集約ユニット
Let TS be the RTP timestamp of the packet carrying the NAL unit. Recall that the NALU-time of a NAL unit in an MTAP is defined in [RFC6184] as the value that the RTP timestamp would have if that NAL unit would be transported in its own RTP packet. The timestamp offset field MUST be set to a value equal to the value of the following formula:
TSは、NALユニットを運ぶパケットのRTPタイムスタンプとします。 MTAPにおけるNALユニットのNALUタイムは、そのNALユニットは、自身のRTPパケットで輸送される場合、RTPタイムスタンプを有することが値として[RFC6184]で定義されていることを思い出してください。タイムスタンプオフセットフィールドは、次式の値に等しい値に設定する必要があります。
if NALU-time >= TS, TS offset = NALU-time - TS else, TS offset = NALU-time + (2^32 - TS)
NALU-時間が> = TS、TS = NALUタイムをオフセットた場合 - 他のTS、= NALUタイム+オフセットTS（2 ^ 32 - TS）
For the "earliest" multi-time aggregation unit in an NI-MTAP, the timestamp offset MUST be zero. Hence, the RTP timestamp of the NI-MTAP itself is identical to the earliest NALU-time.
NI-MTAPにおける「最古」マルチタイム・アグリゲーションユニットについて、オフセットタイムスタンプがゼロでなければなりません。したがって、NI-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 NI-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 or may not be the first one in the order in which the aggregation units are encapsulated in an NI-MTAP. The "earliest" NAL unit need not be the same as the first NAL unit in the NAL unit decoding order either.
有益注：「最古の」マルチタイム集約ユニットは、集約ユニットは、単一NALユニットパケットにカプセル化された場合、NI-MTAPのすべての集約ユニットのうち最小の拡張RTPタイムスタンプを有することになるものです。拡張されたタイムスタンプは32ビット以上を有し、したがって、タイムスタンプがラップ場合は最小値を決定するために1つを可能にする、タイムスタンプフィールドの回り込みをカウントすることができるタイムスタンプです。そのような「最古の」集合部又は集合単位がNI-MTAP中に封入されている順序で最初のものであってもなくてもよいです。 「最古」NALユニットは、いずれかのNALユニット復号順序における最初のNALユニットと同じである必要はありません。
Figure 2 presents an example of an RTP packet that contains an NI-MTAP that contains two non-interleaved multi-time aggregation units, labeled as 1 and 2 in the figure.
図2は、図1及び2のように標識された二つの非インターリーブマルチタイム・アグリゲーションユニットを含み、NI-MTAPを含有する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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| Type | Subtype |J|K|L| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Non-interleaved multi-time aggregation unit #1 |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Non-interleaved multi-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| aggregation unit #2 |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. An RTP packet including an NI-MTAP containing two non-interleaved multi-time aggregation units
二つの非インターリーブマルチタイム・アグリゲーションユニットを含むNI-MTAP含む、図2のアンRTPパケット
Section 5.8 of [RFC6184] applies.
[RFC6184]のセクション5.8が適用されます。
Informative note: In case a NAL unit with the four-byte SVC NAL unit header is fragmented, the three-byte SVC-specific header extension is considered as part of the NAL unit payload. That is, the three-byte SVC-specific header extension is only available in the first fragment of the fragmented NAL unit.
有益な注意：4バイトSVC NALユニットヘッダを有するNALユニットが断片化されている場合には、3バイトSVC固有ヘッダ拡張は、NALユニットペイロードの一部として考えられます。すなわち、3バイトSVC固有ヘッダ拡張は、断片化NALユニットの最初のフラグメントでのみ利用可能です。
Another new type of NAL unit specified in this memo is the payload content scalability information (PACSI) NAL unit. The Type field of PACSI NAL units MUST be equal to 30 (a NAL unit type value left unspecified in [H.264] and [RFC6184]). A PACSI NAL unit MAY be carried in a single NAL unit packet or an aggregation packet, and MUST NOT be fragmented.
このメモで指定されたNALユニットの別の新しいタイプは、ペイロードコンテンツスケーラビリティ情報（PACSI）NALユニットです。 PACSI NALユニットのタイプフィールドが30に等しくなければならない（NALユニットタイプ値は[264]と[RFC6184]で指定しません）。 PACSI NALユニットは、単一NALユニットパケット、または集合パケットに実施することができる、断片化されてはいけません。
PACSI NAL units may be used for the following purposes:
PACSI NALユニットは、次の目的のために使用することができます。
o To enable MANEs to decide whether to forward, process, or discard aggregation packets, by checking in PACSI NAL units the scalability information and other characteristics of the aggregated NAL units, rather than looking into the aggregated NAL units themselves, which are defined by the video coding specification;
oはPACSI NAL単位で集約NALユニットのスケーラビリティ情報および他の特性を調べるのではなく、によって定義される凝集NALユニット自体に調べることによって、集合パケットを転送するプロセス、または廃棄するかを決定するマネスを有効にします仕様ビデオコーディング。
o To enable correct decoding order recovery in MST using the NI-C or NI-TC mode, with the help of the CS-DON information included in PACSI NAL units; and
oはPACSI NALユニットに含まれるCS-DON情報の助けを借りて、NI-CまたはNI-TCモードを使用して、MSTに正しい復号化順序の回復を有効にします。そして
o To improve resilience to packet losses, e.g., by utilizing the following data or information included in PACSI NAL units: repeated Supplemental Enhancement Information (SEI) messages, information regarding the start and end of layer representations, and the indices to layer representations of the lowest temporal subset.
PACSI NALユニットに含まれる次のデータまたは情報を利用することによって、例えば、パケット損失の回復力を改善するために、O：の表現を層に付加拡張情報（SEI）メッセージ、レイヤ表現の開始と終了に関する情報、及びインデックスを繰り返します最低の時間部分組。
PACSI NAL units MAY be ignored in the NI-T mode without affecting the decoding order recovery process.
PACSI NALユニット復号順序回復処理に影響を与えることなく、NI-Tモードでは無視することができます。
When a PACSI NAL unit is present in an aggregation packet, the following applies.
PACSI NALユニットは、集約パケット内に存在する場合、以下が適用されます。
o The PACSI NAL unit MUST be the first aggregated NAL unit in the aggregation packet.
O PACSI NALユニットは、集約パケット内の最初の集約されたNALユニットでなければなりません。
o There MUST be at least one additional aggregated NAL unit in the aggregation packet.
O集約パケット内の少なくとも1つの追加の集約NALユニットが存在していなければなりません。
o The RTP header fields and the payload header fields of the aggregation packet are set as if the PACSI NAL unit was not included in the aggregation packet.
PACSI NALユニットが集約パケットに含まれていなかったかのようにO RTPヘッダフィールドと集約パケットのペイロードヘッダフィールドが設定されています。
o If the aggregation packet is an MTAP16, MTAP24, or NI-MTAP with the J field equal to 1, the decoding order number (DON) for the PACSI NAL unit MUST be set to indicate that the PACSI NAL unit has an identical DON to the first NAL unit in decoding order among the remaining NAL units in the aggregation packet.
アグリゲーションパケットは1に等しいJフィールドとMTAP16、MTAP24、またはNI-MTAP場合、O、PACSI NALユニットの復号化順序番号（DON）はPACSI NALユニットは同じDONにしたことを示すために設定しなければなりません集約パケット内の残りのNALユニットのうち復号化順序で最初のNALユニット。
When a PACSI NAL unit is included in a single NAL unit packet, it is associated with the next non-PACSI NAL unit in transmission order, and the RTP header fields of the packet are set as if the next non-PACSI NAL unit in transmission order was included in a single NAL unit packet.
PACSI NALユニットが単一NALユニットパケットに含まれている場合には、伝送順序における次の非PACSI NALユニットに関連付けられ、かつパケットのRTPヘッダフィールドが設定されているように、伝送における次の非PACSI NALユニット順序は、単一のNALユニットパケットに含まれていました。
The PACSI NAL unit structure is as follows. The first four octets are exactly the same as the four-byte SVC NAL unit header discussed in Section 1.1.3. They are followed by one octet containing several flags, then five optional octets, and finally zero or more SEI NAL units. Each SEI NAL unit is preceded by a 16-bit unsigned size field (in network byte order) that indicates the size of the following NAL unit in bytes (excluding these two octets, but including the NAL unit header octet of the SEI NAL unit). Figure 3 illustrates the PACSI NAL unit structure and an example of a PACSI NAL unit containing two SEI NAL units.
次のようにPACSI NALユニット構造です。最初の4つのオクテットは、セクション1.1.3で説明した4バイトSVC NALユニットヘッダとまったく同じです。そして、彼らはいくつかのフラグ、5つのオプションオクテット、そして最終的にゼロ以上のSEI NALユニットを含む1つのオクテットが続いています。各SEI NALユニットは、（これら2つのオクテットを除くが、SEI NALユニットのNALユニット・ヘッダ・オクテットを含む）をバイト単位で以下NALユニットのサイズを示す（ネットワークバイト順に）16ビット符号なしサイズフィールドが先行します。図3は、PACSI NALユニット構造二つSEI NALユニットを含むPACSI NALユニットの一例を示す図です。
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 |R|I| PRID |N| DID | QID | TID |U|D|O| RR|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|Y|T|A|P|C|S|E| TL0PICIDX (o) | IDRPICID (o) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DONC (o) | NAL unit size 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SEI NAL unit 1 |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NAL unit size 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| SEI NAL unit 2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. PACSI NAL unit structure. Fields suffixed by "(o)" are OPTIONAL.
3. PACSI NALユニットの構造図。 「（O）」で接尾辞のフィールドはオプションです。
The bits A, P, and C are specified only if the bit X is equal to 1. The bits S and E are specified, and the fields TL0PICIDX and IDRPICID are present, only if the bit Y is equal to 1. The field DONC is present only if the bit T is equal to 1. The field T MUST be equal to 0 if the PACSI NAL unit is contained in an STAP-B, MTAP16, MTAP24, or NI-MTAP with the J field equal to 1.
ビットA、P、及びCは、ビットXは、指定された1ビットSとEに等しい場合にのみ指定され、フィールドTL0PICIDXとIDRPICIDビットYは、1フィールドDONCに等しい場合にのみ、存在していますPACSI NALユニットが1に等しいJフィールドとSTAP-B、MTAP16、MTAP24、またはNI-MTAPに含まれている場合、ビットTフィールドTが0に等しくなければならない1に等しい場合にのみ存在します。
The values of the fields in PACSI NAL unit MUST be set as follows.
次のようにPACSI NALユニット内のフィールドの値を設定しなければなりません。
o The F bit MUST be set to 1 if the F bit in at least one of the remaining NAL units in the aggregation packet is equal to 1 (when the PACSI NAL unit is included in an aggregation packet) or if the next non-PACSI NAL unit in transmission order has the F bit equal to 1 (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the F bit MUST be set to 0.
集約パケット内の残りのNALユニットの少なくとも1つでFビットが1に等しい場合、Fビットを1に設定しなければなりませんO（PACSI NALユニットが集約パケットに含まれている場合）又は次の非PACSI場合伝送順序におけるNALユニットは、1に等しいFビット（PACSI NALユニットが単一NALユニットパケットに含まれる場合）を有します。それ以外の場合は、Fビットが0に設定しなければなりません。
o The NRI field MUST be set to the highest value of NRI field among all the remaining NAL units in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or the value of the NRI field of the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet).
NRIフィールドは、集約パケット内の残りのすべてのNALユニット間NRIフィールドの最高値（PACSI NALユニットが集約パケットに含まれている場合）又は次の非PACSIのNRIフィールドの値に設定しなければなりませんoを伝送順序におけるNALユニット（PACSI NALユニットが単一NALユニットパケットに含まれている場合）。
o The Type field MUST be set to 30.
O型フィールドは30に設定しなければなりません。
o The R bit MUST be set to 1. Receivers MUST ignore the value of R.
O RビットはRの値を無視しなければなりません1レシーバに設定しなければなりません
o The I bit MUST be set to 1 if the I bit of at least one of the remaining NAL units in the aggregation packet is equal to 1 (when the PACSI NAL unit is included in an aggregation packet) or if the I bit of the next non-PACSI NAL unit in transmission order is equal to 1 (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the I bit MUST be set to 0.
集約パケット内の残りのNALユニットの少なくとも一つのIビットのIビット1（PACSI NALユニットが集約パケットに含まれている場合）、またはもし等しい場合、Iビットが1に設定しなければなりませんoを伝送順序における次の非PACSI NALユニット（PACSI NALユニットが単一NALユニットパケットに含まれる）1に等しいです。それ以外の場合は、Iビットが0に設定しなければなりません。
o The PRID field MUST be set to the lowest value of the PRID values of the remaining NAL units in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or the PRID value of the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet).
O PRIDフィールドは（PACSI NALユニットが集約パケットに含まれる）集約パケット内の残りのNALユニットのPRID値の最小値または次の非PACSI NALユニットのPRID値のに設定しなければなりません送信順序（PACSI NALユニットが単一NALユニットパケットに含まれている場合）。
o The N bit MUST be set to 1 if the N bit of all the remaining NAL units in the aggregation packet is equal to 1 (when the PACSI NAL unit is included in an aggregation packet) or if the N bit of the next non-PACSI NAL unit in transmission order is equal to 1 (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the N bit MUST be set to 0.
Nビットを1に設定しなければなりませんoを集約パケット内の残りのすべてのNALユニットのNビット（PACSI NALユニットが集約パケットに含まれる）1に等しいか、または次のNビット以外の場合であれば（PACSI NALユニットが単一NALユニットパケットに含まれている場合）は、送信順にPACSI NALユニットは、1に等しいです。そうでなければ、Nビットが0に設定しなければなりません。
o The DID field MUST be set to the lowest value of the DID values of the remaining NAL units in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or the DID value of the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet).
OザDIDフィールドは、集約パケット内の残りのNALユニットのDID値（PACSI NALユニットが集約パケットに含まれている場合）又はにおける次の非PACSI NALユニットのDID値の最低値に設定しなければなりません送信順序（PACSI NALユニットが単一NALユニットパケットに含まれている場合）。
o The QID field MUST be set to the lowest value of the QID values of the remaining NAL units with the lowest value of DID in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or the QID value of the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet).
QIDフィールドは、集約パケット（PACSI NALユニットが集約パケットに含まれている場合）又は次のQID値のDIDの最小値と残りのNALユニットのQID値の最小値に設定しなければならないoを送信のために、非PACSI NALユニット（PACSI NALユニットが単一NALユニットパケットに含まれている場合）。
o The TID field MUST be set to the lowest value of the TID values of the remaining NAL units with the lowest value of DID in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or the TID value of the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet).
TIDフィールドは、集約パケット（PACSI NALユニットが集約パケットに含まれている場合）又は次のTID値のDIDの最小値と残りのNALユニットのTID値の最小値に設定しなければならないoを送信のために、非PACSI NALユニット（PACSI NALユニットが単一NALユニットパケットに含まれている場合）。
o The U bit MUST be set to 1 if the U bit of at least one of the remaining NAL units in the aggregation packet is equal to 1 (when the PACSI NAL unit is included in an aggregation packet) or if the U bit of the next non-PACSI NAL unit in transmission order is equal to 1 (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the U bit MUST be set to 0.
Uビットが1に設定しなければなりませんoを集約パケット内の残りのNALユニットの少なくとも1つのUビット（PACSI NALユニットが集約パケットに含まれる）1に等しい場合、またはある場合のUビット伝送順序における次の非PACSI NALユニット（PACSI NALユニットが単一NALユニットパケットに含まれる）1に等しいです。そうでなければ、Uビットが0に設定しなければなりません。
o The D bit MUST be set to 1 if the D value of all the remaining NAL units in the aggregation packet is equal to 1 (when the PACSI NAL unit is included in an aggregation packet) or if the D bit of the next non-PACSI NAL unit in transmission order is equal to 1 (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the D bit MUST be set to 0.
集約パケット内の残りのすべてのNALユニットのD値に等しい場合、O Dビットが1に設定しなければなりません（PACSI NALユニットが集約パケットに含まれる）1又はもし次以外のDビット（PACSI NALユニットが単一NALユニットパケットに含まれている場合）は、送信順にPACSI NALユニットは、1に等しいです。そうでない場合、Dビットが0に設定しなければなりません。
o The O bit MUST be set to 1 if the O bit of at least one of the remaining NAL units in the aggregation packet is equal to 1 (when the PACSI NAL unit is included in an aggregation packet) or if the O bit of the next non-PACSI NAL unit in transmission order is equal to 1 (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the O bit MUST be set to 0.
O Oビットは集約パケット内の残りのNALユニットの少なくとも一つのOビット（PACSI NALユニットが集約パケットに含まれる）1に等しい場合1に設定又は場合なければならないのOビット伝送順序における次の非PACSI NALユニット（PACSI NALユニットが単一NALユニットパケットに含まれる）1に等しいです。それ以外の場合は、Oビットは0に設定しなければなりません。
o The RR field MUST be set to "11" (in binary form). Receivers MUST ignore the value of RR.
RRフィールドO（バイナリ形式で）「11」に設定しなければなりません。レシーバはRRの値を無視しなければなりません。
o If the X bit is equal to 1, the bits A, P, and C are specified as below. Otherwise, the bits A, P, and C are unspecified, and receivers MUST ignore the values of these bits. The X bit SHOULD be identical for all the PACSI NAL units in all the RTP sessions carrying the same SVC bitstream.
Xビットが1に等しい場合、O、ビットA、P、及びCは、以下のように規定されています。そうでない場合は、ビットA、P、及びCは未指定であり、受信機は、これらのビットの値を無視しなければなりません。 Xビットが同じSVCビットストリームを運ぶすべてのRTPセッション内のすべてのPACSI NALユニットについて同一であるべきです。
o If the Y bit is equal to 1, the OPTIONAL fields TL0PICIDX and IDRPICID MUST be present and specified as below, and the bits S and E are also specified as below. Otherwise, the fields TL0PICIDX and IDRPICID MUST NOT be present, while the S and E bits are unspecified and receivers MUST ignore the values of these bits. The Y bit MUST be identical for all the PACSI NAL units in all the RTP sessions carrying the same SVC bitstream. The Y bit MUST be equal to 0 when the parameter packetization-mode is equal to 2.
Yビットが1に等しい場合、O、オプションフィールドTL0PICIDXとIDRPICIDが存在し、以下のように指定する必要があり、かつビットSとEはまた、以下のように規定されています。 S及びEビットが不特定であり、受信機は、これらのビットの値を無視しなければならないがそれ以外の場合は、フィールドTL0PICIDXとIDRPICIDは、存在してはなりません。 Yビットは、同じSVCビットストリームを運ぶすべてのRTPセッション内のすべてのPACSI NALユニットに対して同一でなければなりません。パラメータパケットモードが2に等しいときYビットが0に等しくなければなりません。
o If the T bit is equal to 1, the OPTIONAL field DONC MUST be present and specified as below. Otherwise, the field DONC MUST NOT be present. The field T MUST be equal to 0 if the PACSI NAL unit is contained in an STAP-B, MTAP16, MTAP24, or NI-MTAP.
Tビットが1に等しい場合、O、オプションフィールドDONCが存在し、以下のように指定しなければなりません。それ以外の場合は、フィールドDONCは存在してはなりません。 PACSI NALユニットがSTAP-B、MTAP16、MTAP24、またはNI-MTAPに含まれている場合、フィールドTは0に等しくなければなりません。
o The A bit MUST be set to 1 if at least one of the remaining NAL units in the aggregation packet belongs to an anchor layer representation (when the PACSI NAL unit is included in an aggregation packet) or if the next non-PACSI NAL unit in transmission order belongs to an anchor layer representation (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the A bit MUST be set to 0.
集約パケット内の残りのNALユニットの少なくとも一つが（PACSI NALユニットが集約パケットに含まれる）アンカー層表現に又は次の非PACSI NALユニット場合に属する場合、ビットは1に設定しなければなりませんO （PACSI NALユニットが単一NALユニットパケットに含まれている場合）は、送信順にアンカー層表現に属します。そうでない場合は、Aビットが0に設定しなければなりません。
Informative note: The A bit indicates whether CGS or spatial layer switching at a non-IDR layer representation (a layer representation with nal_unit_type not equal to 5 and idr_flag not equal to 1) can be performed. With some picture coding structures a non-IDR intra layer representation can be used for random access. Compared to using only IDR layer representations, higher coding efficiency can be achieved. The H.264/AVC or SVC solution to indicate the random accessibility of a non-IDR intra layer representation is using a recovery point SEI message. The A bit offers direct access to this information, without having to parse the recovery point SEI message, which may be buried deeply in an SEI NAL unit. Furthermore, the SEI message may or may not be present in the bitstream.
有益な注：ビットは、非IDRレイヤ表現（idr_flag等しくない1〜5に等しくなく、nal_unit_typeは有するレイヤ表現）でのCGS又は空間レイヤスイッチングを行うことができるかどうかを示します。いくつかの画像符号化構造と非IDR内レイヤ表現は、ランダムアクセスのために使用することができます。のみIDR層表現を使用する場合に比べ、より高い符号化効率を達成することができます。 H.264 / AVCまたはSVCソリューション非IDRイントラ層表現のランダムアクセスリカバリポイントSEIメッセージを使用して示すことができます。 Aビットは、SEI NALユニット内に深く埋設することができる回復ポイントSEIメッセージを解析することなく、この情報への直接アクセスを提供しています。さらに、SEIメッセージは、または、ビットストリーム中に存在してもしなくてもよいです。
o The P bit MUST be set to 1 if all the remaining NAL units in the aggregation packet have redundant_pic_cnt greater than 0 (when the PACSI NAL unit is included in an aggregation packet) or the next non-PACSI NAL unit in transmission order has redundant_pic_cnt greater than 0 (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the P bit MUST be set to 0.
送信順序で（PACSI NALユニットが集約パケットに含まれている場合）集約パケット内の残りのすべてのNALユニットが0より大きいredundant_pic_cntた場合にPビットを1に設定しなければなりませんOまたは次の非PACSI NALユニットは、redundant_pic_cntを有します0より大きい（PACSI NALユニットが単一NALユニットパケットに含まれます）。そうでなければ、Pビットが0に設定しなければなりません。
Informative note: The P bit indicates whether a packet can be discarded because it contains only redundant slice NAL units. Without this bit, the corresponding information can be obtained from the syntax element redundant_pic_cnt, which is contained in the variable-length coded slice header.
有益な注意：Pビットは、それだけ冗長スライスNALユニットが含まれているため、パケットは廃棄することができるかどうかを示します。このビットなしで、対応する情報が可変長符号化されたスライスヘッダに含まれるシンタックス要素redundant_pic_cntから得ることができます。
o The C bit MUST be set to 1 if at least one of the remaining NAL units in the aggregation packet belongs to an intra layer representation (when the PACSI NAL unit is included in an aggregation packet) or if the next non-PACSI NAL unit in transmission order belongs to an intra layer representation (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the C bit MUST be set to 0.
集約パケット内の残りのNALユニットの少なくとも一つが（PACSI NALユニットが集約パケットに含まれる）イントラレイヤ表現に又は次の非PACSI NALユニット場合に属する場合にCビットが1に設定しなければなりませんoを（PACSI NALユニットが単一NALユニットパケットに含まれている場合）は、送信順にイントラレイヤ表現に属します。そうでない場合は、Cビットが0に設定しなければなりません。
Informative note: The C bit indicates whether a packet contains intra slices, which may be the only packets to be forwarded, e.g., when the network conditions are particularly adverse.
有益な注意：ネットワーク条件は特に有害である場合Cビットは、例えば、転送されるパケットのみであってもよい、パケットがイントラスライスが含まれているかどうかを示します。
o The S bit MUST be set to 1, if the first NAL unit following the PACSI NAL unit in an aggregation packet is the first VCL NAL unit, in decoding order, of a layer representation (when the PACSI NAL unit is included in an aggregation packet) or if the next non-PACSI NAL unit in transmission order is the first VCL NAL unit, in decoding order, of a layer representation(when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the S bit MUST be set to 0.
PACSI NALユニットが集合に含まれている場合、集約パケット内PACSI NALユニットの後の最初のNALユニットは、（レイヤ表現の、復号順に、第一のVCL NALユニットである場合にO Sビットは、1に設定しなければなりません伝送順序におけるパケット）場合、または次の非PACSI NALユニットは、PACSI NALユニットが単一NALユニットパケットに含まれるレイヤ表現（）から、復号順に、第一のVCL NALユニットです。それ以外の場合は、Sビットが0に設定しなければなりません。
o The E bit MUST be set to 1, if the last NAL unit following the PACSI NAL unit in an aggregation packet is the last VCL NAL unit, in decoding order, of a layer representation (when the PACSI NAL unit is included in an aggregation packet) or if the next non-PACSI NAL unit in transmission order is the last VCL NAL unit, in decoding order, of a layer representation (when the PACSI NAL unit is included in a single NAL unit packet). Otherwise, the E bit MUST be set to 0.
PACSI NALユニットが集合に含まれている場合、集約パケット内PACSI NALユニット次の最後のNALユニットは、（レイヤ表現の、復号順に、最後のVCL NALユニットである場合、O Eビットは、1に設定しなければなりません伝送順序におけるパケット）場合、または次の非PACSI NALユニットは、PACSI NALユニットが単一NALユニットパケットに含まれるレイヤ表現（）から、復号順に、最後のVCL NALユニットです。それ以外の場合は、Eビットが0に設定しなければなりません。
Informative note: In an aggregation packet it is always possible to detect the beginning or end of a layer representation by detecting changes in the values of dependency_id, quality_id, and temporal_id in NAL unit headers, except from the first and last NAL units of a packet. The S or E bits are used to provide this information, for both single NAL unit and aggregation packets, so that previous or following packets do not have to be examined. This enables MANEs to detect slice loss and take proper action such as requesting a retransmission as soon as possible, as well as to allow efficient playout buffer handling similarly to the M bit present in the RTP header. The M bit in the RTP header still indicates the end of an access unit, not the end of a layer representation.
有益な注：集約パケットでは、パケットの最初と最後のNALユニットから除き、NALユニットヘッダ内のdependency_id、quality_idの値の変化、およびtemporal_idを検出することにより、レイヤ表現の先頭または末尾を検出することが常に可能です。前または次のパケットが検査される必要がないようにSまたはEビットは、単一のNALユニットと集約パケットの両方のために、この情報を提供するために使用されます。これは、スライス損失を検出し、そのようなRTPヘッダ内に存在するMビットに同様に処理効率的な再生バッファを可能にするために、できるだけ早く再送を要求、ならびにとして適切な行動を取ることマネスを可能にします。 RTPヘッダ内のMビットは依然としてアクセスユニットではなく、レイヤ表現の終わりの終わりを示します。
o When present, the TL0PICIDX field MUST be set to equal to tl0_dep_rep_idx as specified in Annex G of [H.264] for the layer representation containing the first NAL unit following the PACSI NAL unit in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or containing the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet).
[264] PACSI NALユニットがある集約パケット内PACSI NALユニット（以下最初のNALユニットを含有する層表現のための付属書Gで指定されるように存在する場合、O、TL0PICIDXフィールドがtl0_dep_rep_idxする同じに設定しなければなりません集約パケットに含まれる）、またはPACSI NALユニットが単一NALユニットパケットに含まれる送信順序（）の次の非PACSI NALユニットを含みます。
o When present, the IDRPICID field MUST be set to equal to effective_idr_pic_id as specified in Annex G of [H.264] for the layer representation containing the first NAL unit following the PACSI NAL unit in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or containing the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet).
[264]の付属書Gで指定されるように存在する場合、O、IDRPICIDフィールドはeffective_idr_pic_idする同じに設定しなければなりませんPACSI NALユニットがある集約パケット内PACSI NALユニット（以下最初のNALユニットを含有する層表現のため集約パケットに含まれる）、またはPACSI NALユニットが単一NALユニットパケットに含まれる送信順序（）の次の非PACSI NALユニットを含みます。
Informative note: The TL0PICIDX and IDRPICID fields enable the detection of the loss of layer representations in the most important temporal layer (with temporal_id equal to 0) by receivers as well as MANEs. SVC provides a solution that uses SEI messages, which are harder to parse and may or may not be present in the bitstream. When the PACSI NAL unit is part of an NI-MTAP packet, it is possible to infer the correct values of tl0_dep_rep_idx and idr_pic_id for all layer representations contained in the NI-MTAP by following the rules that specify how these parameters are set as given in Annex G of [H.264] and by detecting the different layer representations contained in the NI-MTAP packet by detecting changes in the values of dependency_id_, quality_id, and temporal_id in the NAL unit headers as well as using the S and E flags. The only exception is if NAL units of an IDR picture are present in the NI-MTAP in a position other than the first NAL unit following the PACSI NAL unit, in which case the value of idr_pic_id cannot be inferred. In this case the NAL unit has to be partially parsed to obtain the idr_pic_id. Note that, due to the large size of IDR pictures, their inclusion in an NI-MTAP, and especially in a position other than the first NAL unit following the PACSI NAL unit, may be neither practical nor useful.
有益な注意：TL0PICIDXとIDRPICIDフィールドは受信機だけでなく、マネスによって（0に等しいtemporal_idと）最も重要な時間レイヤのレイヤ表現の損失の検出を可能にします。 SVCは、解析が困難であり、又はビットストリーム内に存在してもしなくてもよいSEIメッセージを使用するソリューションを提供します。 PACSI NALユニットは、NI-MTAPパケットの一部である場合、で与えられたように、これらのパラメータが設定されている方法を指定するルールに従うことにより、NI-MTAPに含まれる全てのレイヤ表現のためtl0_dep_rep_idxとidr_pic_idの値の正しい値を推測することが可能です[264]の及びNALユニットヘッダにdependency_id_、quality_id、およびtemporal_idの値の変化を検出するだけでなく、S及びEのフラグを使用して、NI-MTAPパケットに含まれる異なる層表現を検出することにより、附属書G。 IDRピクチャのNALユニットは、idr_pic_idの値の値を推定することができない場合にはPACSI NALユニットの後の最初のNALユニット以外の位置におけるNI-MTAP内に存在する場合は例外です。この場合、NALユニットは、部分的にidr_pic_idの値を取得するために解析されなければなりません。 NI-MTAPにおけるそれらの包含に起因IDRピクチャのサイズが大きいため、なお、特にPACSI NALユニットに続く最初のNALユニット以外の位置では、実用的にも有用でもないかもしれません。
o When present, the field DONC indicates the cross-session decoding order number (CS-DON) for the first of the remaining NAL units in the aggregation packet (when the PACSI NAL unit is included in an aggregation packet) or the CS-DON of the next non-PACSI NAL unit in transmission order (when the PACSI NAL unit is included in a single NAL unit packet). CS-DON is further discussed in Section 4.11.
Oが存在する場合、フィールドDONC集約パケット内の残りのNALユニットの最初のクロスセッション復号順序番号（CS-DON）（PACSI NALユニットが集約パケットに含まれている場合）、またはCS-DONを示し（PACSI NALユニットが単一NALユニットパケットに含まれている）送信順序における次の非PACSI NALユニット。 CS-DONはさらに4.11項で説明されています。
The PACSI NAL unit MAY include a subset of the SEI NAL units associated with the access unit to which the first non-PACSI NAL unit in the aggregation packet belongs, and MUST NOT contain SEI NAL units associated with any other access unit.
PACSI NALユニットは、集約パケット内の最初の非PACSI NALユニットが属し、他のアクセスユニットに関連付けられたSEI NALユニットが含まれていなければならないのアクセスユニットに関連付けられたSEI NALユニットのサブセットを含むかもしれません。
Informative note: In H.264/AVC and SVC, within each access unit, SEI NAL units must appear before any VCL NAL unit in decoding order. Therefore, without using PACSI NAL units, SEI messages are typically only conveyed in the first of the packets carrying an access unit. Senders may repeat SEI NAL units in PACSI NAL units, so that they are repeated in more than one packet and thus increase robustness against packet losses. Receivers may use the repeated SEI messages in place of missing SEI messages.
有益な注意：H.264 / AVCおよびSVCにおいて、各アクセスユニット内で、SEI NALユニットが復号順に任意のVCL NALユニットの前に現れなければなりません。したがって、PACSI NALユニットを使用せずに、SEIメッセージは、典型的にのみアクセスユニットを運ぶパケットの最初に搬送されます。送信者は、彼らが複数のパケットに繰り返されるように、PACSI NALユニットにSEI NALユニットを繰り返し、したがって、パケット損失に対するロバスト性を向上させることができます。レシーバは、SEIメッセージを行方不明の代わりに繰り返されるSEIメッセージを使用することができます。
For a PACSI NAL unit included in an aggregation packet, an SEI message SHOULD NOT be included in the PACSI NAL unit and also included in one of the remaining NAL units contained in the same aggregation packet.
集約パケットに含まPACSI NALユニットに対して、SEIメッセージは、PACSI NALユニットに含まれるべきではなく、また、同じ集約パケットに含まれる残りのNALユニットの一つに含まれます。
An empty NAL unit MAY be included in a single NAL unit packet, an STAP-A or an NI-MTAP packet. Empty NAL units MUST have an RTP timestamp (when transported in a single NAL unit packet) or NALU-time (when transported in an aggregation packet) that is associated with an access unit for which there exists at least one NAL unit of type 1, 5, or 20. When MST is used, the type 1, 5, or 20 NAL unit may be in a different RTP session. Empty NAL units may be used in the decoding order recovery process of the NI-T mode as described in Section 5.2.1.
空のNALユニットは、単一NALユニットパケット、STAP-AまたはNI-MTAPパケットに含まれるかもしれません。空のNALユニットは、RTPタイムスタンプ（単一NALユニットパケットで輸送する場合）又は1型の少なくとも一つのNALユニットが存在するため、アクセスユニットに関連付けられている（集約パケットに運ば）NALUタイムを持たなければなりませんMSTを使用する場合は5、又は20は、タイプ1,5、または20 NALユニットは、異なるRTPセッションであってもよいです。セクション5.2.1に記載したように、空のNALユニットは、NI-Tモードの復号化順序の回復プロセスで使用することができます。
The packet structure is shown in the following figure.
パケット構造を次の図に示されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| Type | Subtype |J|K|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Empty NAL unit structure.
4.空のNALユニットの構造図。
The fields MUST be set as follows:
次のようにフィールドを設定する必要があります。
F MUST be equal to 0 NRI MUST be equal to 3 Type MUST be equal to 31 Subtype MUST be equal to 1 J MUST be equal to 0 K MUST be equal to 0 L MUST be equal to 0
Fは0に等しくなければならない0 Lに等しくなければならない0 Kに等しくなければならない1 Jに等しくなければならない31サブタイプに等しくなければならない3種類に等しくなければならない0 NRIに等しくなければなりません
The DON concept is introduced in [RFC6184] and is used to recover the decoding order when interleaving is used within a single session. Section 5.5 of [RFC6184] applies when using SST.
DONの概念は、[RFC6184]に導入され、インターリービングは、単一のセッション内で使用される場合、復号化順序を回復するために使用されます。 SSTを使用している場合、[RFC6184]の5.5節が適用されます。
When using MST, it is necessary to recover the decoding order across the various RTP sessions regardless if interleaving is used or not. In addition to the timestamp mechanism described later, the CS-DON mechanism is an extension of the DON facility that can be used for this purpose, and is defined in the following section.
MSTを使用する場合は、インターリービングが使用されているかどうかにかかわらず、様々なRTPセッション間復号化順序を回復する必要があります。後述するタイムスタンプ機構に加えて、CS-DON機構は、この目的のために使用することができるDON施設の拡張であり、次のセクションで定義されています。
The cross-session decoding order number (CS-DON) is a number that indicates the decoding order of NAL units across all RTP sessions involved in MST. It is similar to the DON concept in [RFC6184], but contrary to [RFC6184] where the DON was used only for interleaved
クロスセッション復号順序番号（CS-DON）は、MSTに関与する全てのRTPセッション間NALユニットの復号化順序を示す番号です。これは、[RFC6184]でDONの概念に似てますが、DONだけのインターリーブのために使用された[RFC6184]に反しています
packetization, in this memo it is used not only in the interleaved MST mode (I-C) but also in two of the non-interleaved MST modes (NI-C and NI-TC).
パケットは、このメモでは、インターリーブされたMSTモード（I-C）にも非インタリーブMSTモード（NI-C及びNI-TC）の二つにのみならず、使用されています。
When the NI-C or NI-TC MST modes are in use, the packetization of each session MUST be as specified in Section 5.2.2. In PACSI NAL units the CS-DON value is explicitly coded in the field DONC. For non-PACSI NAL units the CS-DON value is derived as follows. Let SN indicate the RTP sequence number of a packet.
NI-CまたはNI-TC MSTモードが使用されている場合、各セッションのパケットは、セクション5.2.2に指定されなければなりません。 PACSI NAL単位でCS-DON値は、明示的フィールドDONCで符号化されます。次のように非PACSI NALユニットのためのCS-DON値が導出されます。 SNは、パケットのRTPシーケンス番号を示してみましょう。
o For each non-PACSI NAL unit carried in a session using the single NAL unit session packetization mode, the CS-DON value of the NAL unit is equal to (DONC_prev_PACSI + SN_diff - 1) % 65536, wherein "%" is the modulo operation, DONC_prev_PACSI is the DONC value of the previous PACSI NAL unit with the same NALU-time as the current NAL unit, and SN_diff is calculated as follows:
OシングルNALユニット・セッション・パケット化モードを使用してセッションで運ば各非PACSI NALユニットは、NALユニットのCS-DON値はに等しい（DONC_prev_PACSI + SN_diff - 1）％65536、「％」はモジュロであります動作は、DONC_prev_PACSI現在のNALユニットと同一のNALUタイムを有する前PACSI NALユニットのDONC値であり、次のようにSN_diffが計算されます。
if SN1 > SN2, SN_diff = SN1 - SN2
else SN_diff = SN2 + 65536 - SN1
where SN1 and SN2 are the SNs of the current NAL unit and the previous PACSI NAL unit with the same NALU-time, respectively.
SN1およびSN2は、それぞれ、現在のNALユニットと同一のNALUタイムを有する前PACSI NALユニットのSNをどこにいます。
o For non-PACSI NAL units carried in a session using the non-interleaved session packetization mode, the CS-DON value of each non-PACSI NAL unit is derived as follows.
次のように非インターリーブセッションパケット化モードを使用してセッションで運ば非PACSI NALユニットについてoは、それぞれ非PACSI NALユニットのCS-DON値が導出されます。
For a non-PACSI NAL unit in a single NAL unit packet, the
following applies.
If the previous PACSI NAL unit is contained in a single NAL unit packet, the CS-DON value of the NAL unit is calculated as above;
前PACSI NALユニットが単一NALユニットパケットに含まれている場合、NALユニットのCS-DON値は、上記のように計算されます。
otherwise (the previous PACSI NAL unit is contained in an STAP-A packet), the CS-DON value of the NAL unit is calculated as above, with DONC_prev_PACSI being replaced by the CS-DON value of the previous non-PACSI NAL unit in decoding order (i.e., the CS-DON value of the last NAL unit of the STAP-A packet).
そうでない場合は（前PACSI NALユニットがSTAPパケットに含まれる）、NALユニットのCS-DON値は、前の非PACSI NALユニットのCS-DON値に置き換えられるDONC_prev_PACSIと、上記のように計算されます復号順序（すなわち、STAPパケットの最後のNALユニットのCS-DON値）。
For a non-PACSI NAL unit in an STAP-A packet, the following applies.
STAPパケット内の非PACSI NALユニットについて、以下が適用されます。
If the non-PACSI NAL unit is the first non-PACSI NAL unit in the STAP-A packet, the CS-DON value of the NAL unit is equal to DONC of the PACSI NAL unit in the STAP-A packet;
非PACSI NALユニットがSTAPパケット内の最初の非PACSI NALユニットである場合、NALユニットのCS-DON値は、STAPパケットでPACSI NALユニットのDONCに等しいです。
otherwise (the non-PACSI NAL unit is not the first non-PACSI NAL unit in the STAP-A packet), the CS-DON value of the NAL unit is equal to: (the CS-DON value of the previous non-PACSI NAL unit in decoding order + 1) % 65536, wherein "%" is the modulo operation.
以前非PACSIの（CS-DON値：そうでなければ（非PACSI NALユニットがSTAPパケット内の最初の非PACSI NALユニットではない）、NALユニットのCS-DON値は、に等しいです。 「％」はモジュロ演算であることを特徴とする請求+ 1）％65536、復号順でNALユニット。
For a non-PACSI NAL unit in a number of FU-A packets, the CS-DON value of the NAL unit is calculated the same way as when the single NAL unit session packetization mode is in use, with SN1 being the SN value of the first FU-A packet.
FU-Aパケットの数で非PACSI NALユニットは、NALユニットのCS-DON値は、単一のNALユニット・セッション・パケット化モードがSN1でのSN値であると、使用されているときと同じように計算されます最初FU-パケット。
For a non-PACSI NAL unit in an NI-MTAP packet, the CS-DON value is equal to the value of the DON field of the non-interleaved multi-time aggregation unit.
NI-MTAPパケットにおける非PACSI NALユニットに対して、CS-DON値は、非インターリーブマルチタイム集約ユニットのDONフィールドの値に等しいです。
When the I-C MST packetization mode is in use, the DON values derived according to [RFC6184] for all the NAL units in each of the RTP sessions MUST indicate CS-DON values.
I-C MSTパケット化モードが使用されている場合、RTPセッションの各々における全てのNALユニットの[RFC6184]に従って導出さDON値は、CS-DON値を示さなければなりません。
Section 6 of [RFC6184] applies in this memo, with the following additions.
[RFC6184]のセクション6は、以下の追加で、このメモに適用されます。
All receivers MUST support the single NAL unit packetization mode to provide backward compatibility to endpoints supporting only the single NAL unit mode of [RFC6184]. However, the use of single NAL unit packetization mode (packetization-mode equal to 0) SHOULD be avoided whenever possible, because encapsulating NAL units of small sizes in their own packets (e.g., small NAL units containing parameter sets, prefix NAL units, or SEI messages) is less efficient due to the packet header overhead.
すべての受信機は、[RFC6184]の単一NALユニットモードをサポートするエンドポイントに後方互換性を提供するために、単一NALユニットパケット化モードをサポートしなければなりません。しかし、単一NALユニットパケット化モード（0に等しいパケットモード）の使用は、可能な限り避けなければならないため（自分のパケットに小さいサイズのNALユニットをカプセル化し、例えば、パラメータセットを含む小さなNALユニット、プレフィックスNALユニット、又はSEIメッセージ）によりパケットヘッダのオーバーヘッドをあまり効率的です。
All receivers MUST support the non-interleaved mode.
すべての受信機は、非インターリーブモードをサポートしなければなりません。
Informative note: The non-interleaved mode of [RFC6184] does allow an application to encapsulate a single NAL unit in a single RTP packet. Historically, the single NAL unit mode has been included in [RFC6184] only for compatibility with ITU-T Rec. H.241 Annex A [H.241]. There is no point in carrying this historic ballast towards a new application space such as the one provided with SVC. The implementation complexity increase for supporting the additional mechanisms of the non-interleaved mode (namely, STAP-A and FU-A) is minor, whereas the benefits are significant. As a result, the support of STAP-A and FU-A is required. Additionally, support for two of the three NAL unit types defined in this memo, namely, empty NAL units and NI-MTAP is needed, as specified in Section 4.5.1.
有益な注意：[RFC6184]の非インターリーブモードは、アプリケーションが単一のRTPパケットに単一のNALユニットをカプセル化することができません。歴史的には、単一NALユニットモードは、ITU-T勧告との互換性のために[RFC6184]に含まれています。 H.241附属書A [H.241]。このようSVCで提供される一つとして、新しいアプリケーション空間に向けたこの歴史的なバラストを運ぶにはポイントがありません。利点は重要であるのに対し、非インタリーブモード（すなわち、STAP-A、およびFU-A）の追加のメカニズムを支持するための実装の複雑さの増加は、マイナーです。結果として、STAP-A、およびFU-Aのサポートが必要です。セクション4.5.1で指定され、さらに、このメモで定義された三のNALユニットタイプ二の支持体、すなわち、空のNALユニットとNI-MTAPは、必要とされます。
A NAL unit of small size SHOULD be encapsulated in an aggregation packet together with one or more other NAL units. For example, non-VCL NAL units such as access unit delimiters, parameter sets, or SEI NAL units are typically small.
小型のNALユニットは、1つのまたは複数の他のNALユニットと一緒に集約パケット内にカプセル化されるべきです。例えば、そのようなアクセスユニットデリミタ、パラメータセット、又はSEI NALユニットのような非VCL NALユニットは、典型的には小さいです。
A prefix NAL unit and the NAL unit with which it is associated, and which follows the prefix NAL unit in decoding order, SHOULD be included in the same aggregation packet whenever an aggregation packet is used for the associated NAL unit, unless this would violate session MTU constraints or if fragmentation units are used for the associated NAL unit.
デコード順で前置NALユニットを次のプレフィックスNALユニットと、それが関連付けられているNALユニットとは、このセッションに違反しない限り、集約パケットは、関連NALユニットのために使用されるたびに同じ集約パケット内に含まれるべきですMTUの制約または断片化ユニットは、関連NALユニットのために使用されている場合。
Informative note: Although the prefix NAL unit is ignored by an H.264/AVC decoder, it is necessary in the SVC decoding process.
有益注：プレフィックスNALユニットは、H.264 / AVCデコーダによって無視されるが、それは、SVC復号処理に必要です。
Given the small size of the prefix NAL unit, it is best if it is transported in the same RTP packet as its associated NAL unit.
それはその関連NALユニットと同じRTPパケットで輸送されている場合、プレフィックスNALユニットの小型サイズを考えると、それがベストです。
When only an H.264/AVC compatible subset of the SVC base layer is transmitted in an RTP session, the subset MUST be encapsulated according to [RFC6184]. This way, an [RFC6184] receiver will be able to receive the H.264/AVC compatible bitstream subset.
SVCベースレイヤのみをH.264 / AVC互換のサブセットがRTPセッションで送信される場合、サブセットは、[RFC6184]に記載のカプセル化されなければなりません。この方法は、[RFC6184]受信機は、H.264 / AVC互換性のあるビットストリームのサブセットを受信することができるであろう。
When a set of layers including one or more SVC enhancement layers is transmitted in an RTP session, the set SHOULD be carried in one RTP stream that SHOULD be encapsulated according to this memo.
一つ以上のSVC向上層を含む層のセットがRTPセッションで送信される場合、セットは、このメモに従ってカプセル化されるべきである1つのRTPストリーム内で実施すべきです。
When MST is used, the packetization rules specified in Section 5.1 still apply. In addition, the following packetization rules MUST be followed, to ensure that decoding order of NAL units carried in the sessions can be correctly recovered for each of the MST packetization modes using the de-packetization process specified in Section 6.2.
MSTを使用する場合は、セクション5.1で指定されたパケット化規則が適用されます。加えて、以下のパケット化規則が正しくセクション6.2で指定されたデパケット化プロセスを使用して、MSTパケット化モードの各々のために回収することができるセッションで搬送NALユニットの復号化順序を保証するために、従わなければなりません。
The NI-T and NI-TC modes both use timestamps to recover the decoding order. In order to be able to do so, it is necessary for the RTP packet stream to contain data for all sampling instances of a given RTP session in all enhancement RTP sessions that depend on the given RTP session. The NI-C and I-C modes do not have this limitation, and use the CS-DON values as a means to explicitly indicate decoding order, either directly coded in PACSI NAL units, or inferred from them using the packetization rules. It is noted that the NI-TC mode offers both alternatives and it is up to the receiver to select which one to use.
NI-TおよびNI-TCモードの両方の復号化順序を回復するためにタイムスタンプを使用します。そうすることができるようにするためには、与えられたRTPセッションに依存するすべての拡張RTPセッション内の指定されたRTPセッションの全てのサンプリングインスタンスのためのデータを格納するためのRTPパケットストリームのために必要です。 NI-CおよびI-Cのモードは、この制限を持っており、明示的に直接PACSI NAL単位で符号化された、またはパケット化規則を使用してそれらから推測、復号化順序を示すための手段として、CS-DON値を使用しません。 NI-TCモードは両方の選択肢を提供し、それを使用するかを選択するために、受信機まであることに留意されたいです。
When using the NI-T mode and a PACSI NAL unit is present, the T bit MUST be equal to 0, i.e., the DONC field MUST NOT be present.
NI-Tモードを使用し、PACSI NALユニットが存在する場合、Tビットが0に等しくなければならない、即ち、DONCフィールドが存在してはなりません。
When using the NI-T mode, the optional parameters sprop-mst-remux-buf-size, sprop-remux-buf-req, remux-buf-cap, sprop-remux-init-buf-time, sprop-mst-max-don-diff MUST NOT be present.
NI-Tモードを使用して、オプションのパラメータのsprop-MST-リマックス-BUFサイズ、のsprop-リマックス-BUF-REQ、リマックス-BUF-キャップのsprop-リマックス-INIT-BUF-時間のsprop-MST-MAX -don-diffは存在してはなりません。
When the NI-T or NI-TC MST mode is in use, the following applies.
NI-TまたはNI-TC MSTモードが使用中である場合、以下が適用されます。
If one or more NAL units of an access unit of sampling time instance t is present in RTP session A, then one or more NAL units of the same access unit MUST be present in any enhancement RTP session that depends on RTP session A.
サンプリング時間インスタンスtのアクセスユニットの一つ以上のNALユニットをRTPセッションAに存在する場合、同じアクセスユニットの一つ以上のNALユニットは、RTPセッションA.に依存する任意の拡張RTPセッションに存在していなければなりません
Informative note: The mapping between RTP and NTP format timestamps is conveyed in RTCP SR packets. In addition, the mechanisms for faster media timestamp synchronization discussed in [RFC6051] may be used to speed up the acquisition of the RTP-to-wall-clock mapping.
有益な注意：RTPとNTP形式のタイムスタンプとの間のマッピングは、RTCP SRパケットで搬送されます。また、[RFC6051]で説明した高速メディアタイムスタンプ同期のためのメカニズムは、RTPツーウォールクロックマッピングの取得を高速化するために使用されてもよいです。
Informative note: The rule above may require the insertion of NAL units, typically when temporal scalability is used, i.e., an enhancement RTP session does not contain any NAL units for an access unit with a particular NTP timestamp (media timestamp), which, however, is present in a lower enhancement RTP session or the base RTP session. There are two ways to insert additional NAL units in order to satisfy this rule:
有益注：上記のルールは、時間スケーラビリティが使用される場合、すなわち、拡張RTPセッションがどのしかし、特定のNTPタイムスタンプ（メディアタイムスタンプ）を有するアクセスユニットのいずれかのNALユニットを含まず、典型的には、NALユニットの挿入を必要とするかもしれません下部拡張RTPセッションまたはベースRTPセッションに存在します。このルールを満たすために、追加のNALユニットを挿入する方法は2つあります。
- One option for adding additional NAL units is to use empty NAL units (defined in Section 4.10), which can be used by the process described in Section 6.2.1 for the access unit reordering process.
- 追加のNALユニットを追加するための1つのオプションは、アクセスユニットの並び替え処理については、セクション6.2.1に記載された方法で使用することができる空のNALユニット（セクション4.10に定義されている）を使用することです。
- Additional NAL units may also be added by the encoder itself, for example, by transmitting coded data that simply instruct the decoder to repeat the previous picture. This option, however, may be difficult to use with pre-encoded content.
- その他のNALユニットはまた、例えば、単純に前の画像を繰り返すようにデコーダに指示する符号化データを送信することにより、エンコーダ単独で添加してもよいです。このオプションは、しかし、事前に符号化されたコンテンツを使用することは困難かもしれません。
If a packet must be inserted in order to satisfy the above rule, e.g., in case of a MANE generating multiple RTP streams out of a single RTP stream, the inserted packet must have an RTP timestamp that maps to the same wall-clock time (in NTP format) as the one of the RTP timestamp of any packet of the access unit present in any lower enhancement RTP session or the base RTP session. This is easy to accomplish if the NAL unit or the packet can be inserted at the time of the RTP stream generation, since the media timestamp (NTP timestamp) must be the same for the inserted packet and the packet of the corresponding access unit. If there is no knowledge of the media time at RTP stream generation or if the RTP streams are not generated at the same instance, this can be also applied later in the transmission process. In this case the NTP timestamp of the inserted packet can be calculated as follows.
複数のRTPを生成MANEの場合には、例えば、上記のルールを満たすために挿入されなければならないパケットは、単一のRTPストリームからストリーム場合、挿入されたパケットは、（同じ壁時計時間にマッピングRTPタイムスタンプを持つ必要があります任意下部強調RTPセッションまたはベースRTPセッションに存在するアクセスユニットの任意のパケットのRTPタイムスタンプの一つとしてNTPフォーマット）です。これは、メディアタイムスタンプ（NTPタイムスタンプ）が挿入されたパケットと、対応するアクセスユニットのパケットに対して同一でなければならないので、NALユニットまたはパケットは、RTPストリーム生成時に挿入することができる場合に達成するのは容易です。 RTPストリーム生成におけるメディア時間の知識がない場合、RTPストリームは同じインスタンスで生成されていない場合、または、これは、送信プロセスの後半で適用することができます。この場合、以下のように挿入されたパケットのNTPタイムスタンプを計算することができます。
Assume that a packet A2 of an access unit with RTP timestamp TS_A2 is present in base RTP session A, and that no packet of that access unit is present in enhancement RTP session B, as shown in Figure 5. Thus, a packet B2 must be inserted into session B following the rule above. The most recent RTCP sender report in session A carries NTP timestamp NTP_A and the RTP timestamp TS_A. The sender report in session B with a lower NTP timestamp than NTP_A is NTP_B, and carries the RTP timestamp TS_B.
RTPタイムスタンプTS_A2有するアクセスユニットのパケットA2は、基地RTPセッションAに存在し、したがって、図5に示すように、アクセスユニットのないパケットは、エンハンスメントRTPセッションBに存在しないこと、パケットB2がなければならないことを前提と上記ルール次のセッションBに挿入されます。セッションAの中で最も最近のRTCP送信者レポートは、NTPタイムスタンプNTP_AとRTPタイムスタンプTS_Aを運びます。 NTP_Aより低いNTPタイムスタンプとセッションBでの送信者レポートはNTP_Bで、RTPタイムスタンプTS_Bを運びます。
RTP session B:..B0........B1........(B2)......................
RTCP session B:.....SR(NTP_B,TS_B).............................
RTP session A:..A0........A1........A2........................
RTCP session A:..................SR(NTP_A,TS_A)................
-----------------|--x------|-----x---|------------------------>
NTP time
--------------------+<---------->+<->+------------------------>
t1 t2 RTP TS(B) time
Figure 5. Example calculation of RTP timestamp for packet insertion in an enhancement layer RTP session
エンハンスメントレイヤRTPセッションにおけるパケットの挿入のためのRTPタイムスタンプの図5の例計算
The vertical bars ("|")in the NTP time line in the figure above indicate that access unit data is present in at least one of the sessions. The "x" marks indicate the times of the sender reports. The RTP timestamp time line for session B, shown right below the NTP time line, indicates two time segments, t1 and t2. t1 is the time difference between the sender reports between the two sessions, expressed in RTP timestamp clock ticks, and t2 is the time difference from the session A sender report to the A2 packet, again expressed in RTP timestamp clock ticks. The sum of these differences is added to the RTP timestamp of the session report from session B in order to derive the correct RTP timestamp for the inserted packet B2. In other words:
垂直バー（「|」）上図のNTPタイムラインでは、アクセスユニットのデータは、セッションの少なくとも一つに存在することを示しています。 「×」印は、送信者レポートの時間を示します。右NTPタイムラインの下に示さセッションBのRTPタイムスタンプタイムラインは、2つの時間セグメント、T1およびT2を示しています。 t1はタイムスタンプクロックティックRTPで表され、二つのセッションの間に、送信者レポート間の時間差であり、T2はA2パケットの送信者レポートセッションから時間差で、再びRTPタイムスタンプのクロックでティック表明しました。これらの違いの合計が挿入されたパケットB2の正しいRTPタイムスタンプを導出するために、セッションBからのセッションのレポートのRTPタイムスタンプに追加されます。言い換えると：
TS_B2 = TS_B + t1 + t2
TS_B2 = TS_B + T1 + T2
Let toRTP() be a function that calculates the RTP time difference (in clock ticks of the used clock) given an NTP timestamp difference, and effRTPdiff() be a function that calculates the effective difference between two timestamps, including wraparounds:
ラップアラウンドを含む二タイムスタンプの間の有効差が計算する関数である）（toRTP（）はNTPタイムスタンプの差所与RTP時間差を算出する（クロックに使用されるクロックの刻み）機能、及びeffRTPdiffとします。
effRTPdiff( ts1, ts2 ):
effRTPdiff（TS1、TS2）：
if( ts1 <= ts2 ) then effRTPdiff := ts1-ts2 else effRTPDiff := (4294967296 + ts2) - ts1 We have:
もし（TS1 <= TS2）、その後effRTPdiff：= TS1-TS2他effRTPDiff：=（4294967296 + TS2） - TS1我々は持っています：
t1 = toRTP(NTP_A - NTP_B) and t2 = effRTPdiff(TS_A2, TS_A)
T1 = toRTP（NTP_A - NTP_B）とt2 = effRTPdiff（TS_A2、TS_A）
Hence in order to generate the RTP timestamp TS_B2 for the inserted packet B2, the RTP timestamp for packet B2 TS_B2 can be calculated as follows.
次のようによって挿入パケットB2用のRTPタイムスタンプTS_B2を生成するために、パケットB2のTS_B2用のRTPタイムスタンプを計算することができます。
TS_B2 = TS_B + toRTP(NTP_A - NTP_B) + effRTPdiff(TS_A2, TS_A)
TS_B2 = TS_B + toRTP（NTP_A - NTP_B）+ effRTPdiff（TS_A2、TS_A）
When the NI-C or NI-TC MST mode is in use, the following applies for each of the RTP sessions.
NI-CまたはNI-TC MSTモードが使用中である場合、以下がRTPセッションのそれぞれに適用されます。
o For each single NAL unit packet containing a non-PACSI NAL unit, the previous packet, if present, MUST have the same RTP timestamp as the single NAL unit packet, and the following applies.
O非PACSI NALユニット、前のパケットを含む各単一NALユニットパケットのために、存在する場合、単一NALユニットパケットと同じRTPタイムスタンプを有しており、以下が適用されなければなりません。
o If the NALU-time of the non-PACSI NAL unit is not equal to the NALU-time of the previous non-PACSI NAL unit in decoding order, the previous packet MUST contain a PACSI NAL unit containing the DONC field.
非PACSI NALユニットのNALUタイムが復号化順で前の非PACSI NALユニットのNALUタイムに等しくない場合、O、前のパケットはDONCフィールドを含むPACSI NALユニットを含まなければなりません。
o In an STAP-A packet the first NAL unit in the STAP-A packet MUST be a PACSI NAL unit containing the DONC field.
O STAPパケットでSTAPパケット内の最初のNALユニットはDONCフィールドを含むPACSI NALユニットでなければなりません。
o For an FU-A packet the previous packet MUST have the same RTP timestamp as the FU-A packet, and the following applies.
O FUパケットの以前のパケットは、FU-パケットと同じRTPタイムスタンプが必要であり、以下が適用されます。
o If the FU-A packet is the start of the fragmented NAL unit, the following applies.
FU-パケットが分割NALユニットの開始である場合、O、以下が適用されます。
o If the NALU-time of the fragmented NAL unit is not equal to the NALU-time of the previous non-PACSI NAL unit in decoding order, the previous packet MUST contain a PACSI NAL unit containing the DONC field;
断片化されたNALユニットのNALUタイムを復号化順に前回非PACSI NALユニットのNALUタイムに等しくない場合、O、前のパケットはDONCフィールドを含むPACSI NALユニットを含まなければなりません。
o Otherwise, (the NALU-time of the fragmented NAL unit is equal to the NALU-time of the previous non-PACSI NAL unit in decoding order), the previous packet MAY contain a PACSI NAL unit containing the DONC field.
Oそれ以外の場合は、前のパケットがDONCフィールドを含むPACSI NALユニットを含んでいてもよく、（断片化NALユニットのNALUタイムは、復号化順で前の非PACSI NALユニットのNALUタイムに等しいです）。
o Otherwise, if the FU-A packet is the end of the fragmented NAL unit, the following applies.
FU-パケットが分割NALユニットの最後である場合、Oそうでない場合、以下が適用されます。
o If the next non-PACSI NAL unit in decoding order has NALU-time equal to the NALU-time of the fragmented NAL unit, and is carried in a number of FU-A packets or a single NAL unit packet, the next packet MUST be a single NAL unit packet containing a PACSI NAL unit containing the DONC field.
O復号化順で次の非PACSI NALユニット場合は必須断片化NALユニットのNALUタイムに等しいNALUタイムを有し、FU-Aパケットの数又は単一NALユニットパケットで運ばれ、次のパケットDONCフィールドを含むPACSI NALユニットを含む単一NALユニットパケットです。
o Otherwise (the FU-A packet is neither the start nor the end of the fragmented NAL unit), the previous packet MUST be a FU-A packet.
Oそうでない場合（FU-パケットがスタートも断片化NALユニットの末端でもない）、前のパケットは、FU-パケットでなければなりません。
o For each single NAL unit packet containing a PACSI NAL unit, if present, the PACSI NAL unit MUST contain the DONC field.
存在する場合にO PACSI NALユニットを含む各単一NALユニットパケットのために、PACSI NALユニットはDONCフィールドを含まなければなりません。
o When the optional media type parameter sprop-mst-csdon-always-present is equal to 1, the session packetization mode in use MUST be the non-interleaved mode, and only STAP-A and NI-MTAP packets can be used.
オプションのメディアタイプパラメータのsprop-MST-csdon-常に現在は1に等しいとき、O、使用中のセッションのパケット化モードは非インタリーブモードでなければなりません、とだけSTAP-A、およびNI-MTAPパケットを使用することができます。
When the I-C MST packetization mode is in use, the following applies.
I-C MSTのパケット化モードが使用されている場合には、以下が適用されます。
o When a PACSI NAL unit is present, the T bit MUST be equal to 0, i.e., the DONC field is not present, and the Y bit MUST be equal to 0, i.e., the TL0PICIDX and IDRPICID are not present.
PACSI NALユニットが存在する場合にO、Tビットが0に等しくなければならない、即ち、DONCフィールドが存在せず、Yのビットが0に等しくなければならない、即ち、TL0PICIDXとIDRPICIDは存在しません。
NAL units that do not directly encode video slices are known in H.264 as non-VCL NAL units. Non-VCL units that are only used by, or only relevant to, enhancement RTP sessions SHOULD be sent in the lowest session to which they are relevant.
直接ビデオスライスをコードしないNALユニットは非VCL NALユニットとしてH.264で知られています。のみによって使用される、または拡張RTPセッションにのみ関連している非VCLユニットは、それらが関連しているため、最低のセッションで送信されるべきです。
Some senders, however, such as those sending pre-encoded data, may be unable to easily determine which non-VCL units are relevant to which session. Thus, non-VCL NAL units MAY, instead, be sent in a session on which the session using these non-VCL NAL units depends (e.g., the base RTP session).
一部の送信者は、しかし、事前符号化データを送信するもののような、容易にそのセッションに関連した非VCLユニットを決定することができません。したがって、非VCL NALユニットは、代わりに、これらの非VCL NALユニットを使用してセッションが依存しているセッション（例えば、基地RTPセッション）で送られてもよいです。
If a non-VCL unit is relevant to more than one RTP session, neither of which depends on the other(s), the NAL unit MAY be sent in another session on which all these sessions depend.
非VCLユニット（s）は他に依存どちらも複数のRTPセッションに関連している場合は、NALユニットは、これらすべてのセッションが依存している別のセッションで送信することができます。
Section 5.1 of this memo applies, with the following addition. If the base layer is sent in a base RTP session using [RFC6184], prefix NAL units MAY be sent in the lowest enhancement RTP session rather than in the base RTP session.
このメモのセクション5.1には、次のように加えて、適用されます。ベース層は[RFC6184]を使用してベースRTPセッションで送信される場合、プレフィックスNALユニットは、最も低いエンハンスメントRTPセッションではなく、ベースRTPセッションで送られてもよいです。
For single-session transmission, where a single RTP session is used, the de-packetization process specified in Section 7 of [RFC6184] applies.
シングルRTPセッションが使用されているシングルセッション伝送については、[RFC6184]のセクション7で指定されたデパケット化処理が適用されます。
For multi-session transmission, where more than one RTP session is used to receive data from the same SVC bitstream, the de-packetization process is specified as follows.
次のように複数のRTPセッションが同じSVCビットストリームからデータを受信するために使用されるマルチセッション伝送のために、脱パケット化処理が指定されています。
As for a single RTP session, the general concept behind the de-packetization process is to reorder NAL units from transmission order to the NAL unit decoding order.
シングルRTPセッションのためとして、脱パケット化プロセスの背後にある一般概念は、NALユニットの復号化順に送信順序からNALユニットの順序を変更することです。
The sessions to be received MUST be identified by mechanisms specified in Section 7.2.3. An enhancement RTP session typically contains an RTP stream that depends on at least one other RTP session, as indicated by mechanisms defined in Section 7.2.3. A lower RTP session to an enhancement RTP session is an RTP session on which the enhancement RTP session depends. The lowest RTP session for a receiver is the base RTP session, which does not depend on any other RTP session received by the receiver. The highest RTP session for a receiver is the RTP session on which no other RTP session received by the receiver depends.
受信されるセッションは、7.2.3項で指定されたメカニズムによって識別されなければなりません。 7.2.3項で定義されたメカニズムによって示されるように強調RTPセッションは、典型的には、少なくとも一つの他のRTPセッションに依存RTPストリームを含んでいます。拡張RTPセッションに低いRTPセッションが強調RTPセッションが依存するRTPセッションです。受信機のための最小RTPセッションが受信機によって受信された任意の他のRTPセッションに依存しないベースRTPセッションです。受信機のための最高のRTPセッションが受信機によって受信された他のRTPセッションが依存しないれたRTPセッションです。
For each of the RTP sessions, the RTP reception process as specified in RFC 3550 is applied. Then the received packets are passed into the payload de-packetization process as defined in this memo.
RTPセッションのそれぞれについて、RFC 3550で指定されるようにRTP受信処理が適用されます。このメモで定義されるように、受信したパケットは、ペイロードデパケット化プロセスに渡されます。
The decoding order of the NAL units carried in all the associated RTP sessions is then recovered by applying one of the following subsections, depending on which of the MST packetization modes is in use.
関連するすべてのRTPセッションで運ばNALユニットの復号化順序は、その後使用されているMSTパケット化モードのどちらに応じて、以下のサブセクションのいずれかを適用することによって回収されます。
The following process MUST be applied when the NI-T packetization mode is in use. The following process MAY be applied when the NI-TC packetization mode is in use.
-T NIパケット化モードが使用されている場合は、次のプロセスが適用されなければなりません。 NI-TCパケット化モードが使用されている場合は、次のプロセスが適用されてもよいです。
The process is based on RTP session dependency signaling, RTP sequence numbers, and timestamps.
プロセスは、RTPセッション依存性シグナリング、RTPシーケンス番号、タイムスタンプに基づいています。
The decoding order of NAL units within an RTP packet stream in RTP session is given by the ordering of sequence numbers SN of the RTP packets that contain the NAL units, and the order of appearance of NAL units within a packet.
RTPセッションにおけるRTPパケットストリーム内のNALユニットの復号化順序は、NALユニットを含むRTPパケットのシーケンス番号SNの順序、およびパケット内のNALユニットの出現の順序で与えられます。
Timing information according to the media timestamp TS, i.e., the NTP timestamp as derived from the RTP timestamp of an RTP packet, is associated with all NAL units contained in the same RTP packet received in an RTP session.
メディアタイムスタンプTS、RTPパケットのRTPタイムスタンプから導出される、すなわち、NTPタイムスタンプに応じてタイミング情報を、RTPセッションで受信した同一のRTPパケットに含まれる全てのNALユニットに関連付けられています。
For NI-MTAP packets the NALU-time is derived for each contained NAL unit by using the "TS offset" value in the NI-MTAP packet as defined in Section 4.10, and is used instead of the RTP packet timestamp to derive the media timestamp, e.g., using the NTP wall clock as provided via RTCP sender reports. NAL units contained in fragmentation packets are handled as defragmented, entire NAL units with their own media timestamps. All NAL units associated with the same value of media timestamp TS are part of the same access unit AU(TS). Any empty NAL units SHOULD be kept as, effectively, access unit indicators in the reordering process. Empty NAL units and PACSI NAL units SHOULD be removed before passing access unit data to the decoder.
NI-MTAPがNALUタイムがそれぞれに対して導出されるパケットは、セクション4.10で定義されるようにNI-MTAPパケット内の値を「オフセットTS」を用いて、NALユニットを含んでいて、メディアタイムスタンプを導出するRTPパケットのタイムスタンプの代わりに使用されています例えば、RTCP送信者レポートを経由して提供されるNTPの壁時計を使って。フラグメントパケットに含まれるNALユニットは、独自のメディアタイムスタンプとデフラグ、全体NAL単位として扱われます。メディアタイムスタンプTSの同じ値に関連付けられたすべてのNALユニットは、同一のアクセスユニットAU（TS）の一部です。空のNALユニットがリオーダリングプロセスにおいて、効果的に、アクセスユニット指標として維持されるべきです。空のNALユニットとPACSI NALユニットがデコーダへのアクセス単位データを渡す前に除去されるべきです。
Informative note: These empty NAL units are used to associate NAL units present in other RTP sessions with RTP sessions not containing any data for an access unit of a particular time instance. They act as access unit indicators in sessions that would otherwise contain no data for the particular access unit. The presence of these NAL units is ensured by the packetization rules in Section 5.2.1.
有益注：これらの空のNALユニットは、RTPセッションが特定の時間インスタンスのアクセスユニットの任意のデータを含んでいないと、他のRTPセッションに存在するNALユニットを関連付けるために使用されます。彼らは、そうでない場合は、特定のアクセスユニットのためのデータを含まないだろうセッションでアクセスユニットの指標としての役割を果たす。これらのNALユニットの存在は、5.2.1項でパケット化規則によって確保されています。
It is assumed that the receiver has established an operation point (DID, QID, and TID values), and has identified the highest enhancement RTP session for this operation point. The decoding order of NAL units from multiple RTP streams in multiple RTP sessions MUST be recovered into a single sequence of NAL units, grouped into access units, by performing any process equivalent to the following steps. The general process is described in Section 4.2 of [RFC6051]. For convenience the instructions of [RFC6051] are repeated and applied to NAL units rather than to full RTP packets. Additionally, SVC-specific extensions to the procedure in Section 4.2. of [RFC6051] are presented in the following list:
受信機が動作点を確立しているものとする（QID、およびTID値をDID）、この動作点の最高拡張RTPセッションを識別しました。複数のRTPからのNALユニットの復号化順序は、複数のRTPセッション内のストリームは、次の手順に任意のプロセス等価を行うことにより、アクセスユニットにグループ分け、NALユニットの単一シーケンスに回収しなければなりません。一般的なプロセスは、[RFC6051]のセクション4.2に記載されています。便宜のために[RFC6051]の命令が繰り返され、NALユニットに対してではなく、完全なRTPパケットに適用されます。 4.2節の手順に加えて、SVC固有の拡張機能。 [RFC6051]は、以下のリストに表示されています。
o The process should be started with the NAL units received in the highest RTP session with the first media timestamp TS (in NTP format) available in the session's (de-jittering) buffer. It is assumed that packets in the de-jittering buffer are already stored in RTP sequence number order.
Oプロセスは、セッションの（デジッタ）バッファで利用可能な（NTPフォーマットで）最初のメディアタイムスタンプTSと最高RTPセッションで受信したNALユニットで開始されるべきです。デジッタバッファ内のパケットが既にRTPシーケンス番号順に格納されているものとします。
o Collect all NAL units associated with the same value of media timestamp TS, starting from the highest RTP session, from all the (de-jittering) buffers of the received RTP sessions. The collected NAL units will be those associated with the access unit AU(TS).
O受信したRTPセッションの全ての（デジッタ）バッファから、最高のRTPセッションから出発して、メディアタイムスタンプTSの同じ値に関連付けられたすべてのNALユニットを収集します。収集NALユニットは、アクセスユニットAU（TS）に関連するものであろう。
o Place the collected NAL units in the order of session dependency as derived by the dependency indication as specified in Section 7.2.3, starting from the lowest RTP session.
最低のRTPセッションから出発して、セクション7.2.3で指定された依存関係表示によって誘導されるようにOセッション依存性のために収集したNALユニットを置き。
o Place the session ordered NAL units in decoding order within the particular access unit by satisfying the NAL unit ordering rules for SVC access units, as described in the informative algorithm provided in Section 6.2.1.1.
Oセッションを置き、セクション6.2.1.1に設けられた有益なアルゴリズムで説明したように、SVCアクセスユニットのNALユニットの順序規則を満足することにより、特定のアクセスユニット内の復号化順にNALユニットを注文。
o Remove NI-MTAP and any PACSI NAL units from the access unit AU(TS).
O NI-MTAP及びアクセスユニットAU（TS）から任意PACSI NALユニットを取り外します。
o The access units can then be transferred to the decoder. Access units AU(TS) are transferred to the decoder in the order of appearance (given by the order of RTP sequence numbers) of media timestamp values TS in the highest RTP session associated with access unit AU(TS).
Oアクセスユニットは、復号器に転送することができます。アクセスユニットAU（TS）は、アクセスユニットAU（TS）に関連付けられた最高のRTPセッションにおけるメディアタイムスタンプ値TSの（RTPシーケンス番号の順序で与えられる）出現順にデコーダに転送されます。
Informative note: Due to packet loss it is possible that not
all sessions may have NAL units present for the media
timestamp value TS present in the highest RTP session. In
such a case, an algorithm may: a) proceed to the next
complete access unit with NAL units present in all the
received RTP sessions; or b) consider a new highest RTP session, the highest RTP session for which the access unit
is complete, and apply the process above. The algorithm may
return to the original highest RTP session when a complete
and error-free access unit that contains NAL units in all
the sessions is received.
The following gives an informative example.
以下は参考例を示します。
The example shown in Figure 6 refers to three RTP sessions A, B, and C containing an SVC bitstream transmitted as 3 sources. In the example, the dependency signaling (described in Section 7.2.3) indicates that session A is the base RTP session, B is the first enhancement RTP session and depends on A, and C is the second enhancement RTP session and depends on A and B. A hierarchical picture coding prediction structure is used, in which session A has the lowest frame rate and sessions B and C have the same but higher frame rate.
図6に示す例では、3つのRTPセッションA、Bを意味し、Cは3枚の源として送信SVCビットストリームを含みます。一例では、（セクション7.2.3を参照）依存性シグナリングは、セッションAがベースRTPセッションであり、Bは、第一エンハンスメントRTPセッションであり、Aに依存することを示し、Cは、第2拡張RTPセッションであり、Aに依存し予測構造をコーディングB. A階層画像は、セッションAは、BとCは同じであるが、より高いフレームレートを有する最低フレームレートとセッションを有している、使用されています。
The figure shows NAL units contained in RTP packets that are stored in the de-jittering buffer at the receiver for session de-packetization. The NAL units are already reordered according to their RTP sequence number order and, if within an aggregation packet, according to the order of their appearance within the aggregation packet. The figure indicates for the received NAL units the decoding order within the sessions, as well as the associated media (NTP) timestamps ("TS[..]"). NAL units of the same access unit within a session are grouped by "(.,.)" and share the same media timestamp TS, which is shown at the bottom of the figure. Note that the timestamps are not in increasing order since, in this example, the decoding order is different from the output/display order.
図は、セッションデパケット化のために受信機において、デジッタバッファに格納されたRTPパケットに含まれるNALユニットを示します。集約パケット内の場合NALユニットは既に集約パケット内のそれらの出現の順序に従って、それらのRTPシーケンス番号の順序に従って並べ替えとされます。図は、受信されたNALユニットのためにセッション内の復号化順序、ならびに関連するメディア（NTP）タイムスタンプ（「TSを[..]」）を示しています。セッション内の同一のアクセスユニットのNALユニットは、図の下部に示されている同一のメディアタイムスタンプTSを、「（。、。）」によってグループ化され、共有されています。タイムスタンプは、以降昇順でないことに注意してください、この例では、復号化順序は出力/表示順序と異なります。
The process first proceeds to the NAL units associated with the first media timestamp TS[1] present in the highest session C and removes/ignores all preceding (in decoding order) NAL units to NAL units with TS[1] in each of the de-jittering buffers of RTP sessions A, B, and C. Then, starting from session C, the first media timestamp available in decoding order (TS[1]) is selected and NAL units starting from RTP session A, and sessions B and C are placed in order of the RTP session dependency as required by Section 7.2.3 of this memo (in the example for TS[1]: first session B and then session C) into the access unit AU(TS[1]) associated with media timestamp TS[1]. Then the next media timestamp TS[3] in order of appearance in the highest RTP session C is processed and the process described above is repeated. Note that there may be access units with no NAL units present, e.g., in the lowest RTP session A (see, e.g., TS[1]). With TS[8], the first access unit with NAL units present in all the RTP sessions appears in the buffers.
プロセスは、まず、第1のメディアのタイムスタンプに関連付けられているNALユニットに移行TS [1]最も高いセッションCに存在し、削除/無視し、すべてのデの各々におけるTS [1]を有するNALユニットにNALユニット（復号順で）前のセッションCから出発し、そしてRTPセッションのA、B、およびCのバッファを-jittering、復号順で利用可能な最初のメディアタイムスタンプ（TS [1]）が選択され、NALユニットは、RTPセッションAから開始し、セッションのBとCこのメモのセクション7.2.3によって必要とされるRTPセッション依存性の順に配置されている（TSのための実施例[1]：第1のセッションB、次いでセッションC）アクセスユニットAUに（TS [1]）と関連メディアタイムスタンプTS [1]。次いで、次のメディアのタイムスタンプTS [3]は最高RTPセッションCにおける出現の順序では処理され、上述の処理が繰り返されます。存在しないNALユニットとアクセスユニットが存在し得ることに留意されたい、例えば、最低のRTPセッションでA（例えば、TS [1]参照）。 TSでは、[8]、すべてのRTPセッションに存在するNALユニットとの最初のアクセスユニットがバッファで表示されます。
C: ------------(1,2)-(3,4)--(5)---(6)---(7,8)(9,10)-(11)--(12)----
| | | | | | | | | |
B: -(1,2)-(3,4)-(5)---(6)--(7,8)-(9,10)-(11)-(12)--(13,14)(15,15)-
| | | | | |
A: -------(1)---------------(2)---(3)---------------(4)----(5)----
---------------------------------------------------decoding order-->
TS: [4] [2] [1] [3] [8] [6] [5] [7] [12] [10]
TS：[4] [2] [1]〜[3] [8] [6] [5] [7] [12] [10]
Key: A, B, C - RTP sessions Integer values in "()" - NAL unit decoding order within RTP session "( )" - groups the NAL units of an access unit in an RTP session "|" - indicates corresponding NAL units of the same access unit AU(TS[..]) in the RTP sessions Integer values in "[]" - media timestamp TS, sampling time as derived, e.g., from NTP timestamp associated with the access unit AU(TS[..]), consisting of NAL units in the sessions above each TS value.
キー：A、B、C - RTPセッション整数値の「（）」 - RTPセッション内のNALユニットの復号化順「（）」 - RTPセッションでグループアクセスユニットのNALユニットを「|」 - アクセスユニットAUに関連付けられたNTPタイムスタンプから、メディアタイムスタンプTS、誘導されたように、時間サンプリング、例えば - 「[]」でRTPセッション整数の値が同じアクセスユニットAU（TS [..]）の対応するNALユニットを示します（TS [..]）、各TS値を上記セッションにおけるNAL単位からなります。
Figure 6. Example of decoding order recovery in multi-source transmission.
多元送信における復号順序回復の6例を図。
6.2.1.1. Informative Algorithm for NI-T Decoding Order Recovery within an Access Unit
6.2.1.1。アクセスユニット内のNI-Tデコード受注回復のための参考アルゴリズム
Within an access unit, the [H.264] specification (Sections 7.4.1.2.3 and G.7.4.1.2.3) constrains the valid decoding order of NAL units.
アクセスユニット内、[264]の仕様（セクション7.4.1.2.3及びG.7.4.1.2.3）は、NALユニットの有効な復号順序を制約します。
These constraints make it possible to reconstruct a valid decoding order for the NAL units of an access unit based only on the order of NAL units in each session, the NAL unit headers, and Supplemental Enhancement Information message headers.
これらの制約は、各セッションにおけるNALユニットの順序に基づいて、アクセスユニット、NALユニットヘッダ、及び付加拡張情報メッセージヘッダーのNALユニットに有効な復号化順序を再構築することを可能にします。
This section specifies an informative algorithm to reconstruct a valid decoding order for NAL units within an access unit. Other NAL unit orderings may also be valid; however, any compliant NAL unit ordering will describe the same video stream and ancillary data as the one produced by this algorithm.
このセクションでは、アクセスユニット内のNALユニットのための有効な復号順序を再構築するために有益なアルゴリズムを指定します。その他のNALユニットの順序も有効です。しかし、いずれの対応のNALユニットの順序は、このアルゴリズムによって製造されたものと同一のビデオストリームと補助データを記述します。
An actual implementation, of course, needs only to behave "as if" this reordering is done. In particular, NAL units that are discarded by an implementation's decoding process do not need to be reordered.
実際の実装は、当然のことながら、この並べ替えが行われている「あるかのように」のみ動作する必要があります。具体的には、実装の復号処理により破棄されるNALユニットを並べ替えする必要はありません。
In this algorithm, NAL units within an access unit are first ordered by NAL unit type, in the order specified in Table 12 below, except from NAL unit type 14, which is handled specially as described in the table. NAL units of the same type are then ordered as specified for the type, if necessary.
このアルゴリズムでは、アクセスユニット内のNALユニットは、最初の表に記載されるように特別に処理されたNALユニット・タイプ14、から除き、以下の表12で指定された順序で、NALユニット・タイプによって順序付けられます。必要に応じて、タイプに指定されたものと同じタイプのNALユニットは、その後、順序付けられます。
For the purposes of this algorithm, "session order" is the order of NAL units implied by their transmission order within an RTP session. For the non-interleaved and single NAL unit modes, this is the RTP sequence number order coupled with the order of NAL units within an aggregation unit.
このアルゴリズムの目的のために、「セッション順序は」RTPセッション内でそれらの送信順序によって暗黙NALユニットの順序です。非インタリーブおよび単一NALユニットモードのために、これは凝集ユニット内のNALユニットの順に結合されたRTPシーケンス番号順です。
Table 12. Ordering of NAL unit types within an Access Unit
アクセスユニット内のNALユニット・タイプの表12の発注
Type Description / Comments
-----------------------------------------------------------
9 Access unit delimiter
7 Sequence parameter set
7シーケンスパラメータセット
13 Sequence parameter set extension
13シーケンスパラメータセットの拡張
15 Subset sequence parameter set
15サブセットシーケンスパラメータセット
8 Picture parameter set
8ピクチャパラメータセット
16-18 Reserved
予約済み16-18
6 Supplemental enhancement information (SEI) If an SEI message with a first payload of 0 (Buffering Period) is present, it must be the first SEI message.
6補足エンハンスメント情報（SEI）0（バッファリング期間）の最初のペイロードとSEIメッセージが存在する場合、それは最初のSEIメッセージでなければなりません。
If SEI messages with a Scalable Nesting (30) payload and
a nested payload of 0 (Buffering Period) are present,
these then follow the first SEI message. Such an SEI
message with the all_layer_representations_in_au_flag
equal to 1 is placed first, followed by any others,
sorted in increasing order of DQId.
All other SEI messages follow in any order.
他のすべてのSEIメッセージは、任意の順序で従ってください。
14 Prefix NAL unit in scalable extension 1 Coded slice of a non-IDR picture 5 Coded slice of an IDR picture
IDRピクチャの非IDRピクチャ5符号化スライスのスケーラブル拡張1符号化スライスで14プレフィックスNALユニット
NAL units of type 1 or 5 will be sent within only a
single session for any given access unit. They are
placed in session order. (Note: Any given access unit
will contain only NAL units of type 1 or type 5, not
both.)
If NAL units of type 14 are present, every NAL unit of type 1 or 5 is prefixed by a NAL unit of type 14. (Note: Within an access unit, every NAL unit of type 14 is identical, so correlation of type 14 NAL units with the other NAL units is not necessary.)
タイプ14のNALユニットが存在する場合、タイプ1又は5のすべてのNALユニットは、タイプ14のNALユニットによって付けられ（注：アクセスユニット内、タイプ14のすべてのNALユニットはNAL同一であるので、相関型14の他のNALユニットとユニットは不要です。）
12 Filler data
12フィラーデータ
The only restriction of filler data NAL units within an
access unit is that they shall not precede the first VCL
NAL unit with the same access unit.
19 Coded slice of an auxiliary coded picture without partitioning
分割せずに補助符号化ピクチャの符号化スライス19
These NAL units will be sent within only a single
session for any given access unit, and are placed in
session order.
20 Coded slice in scalable extension 21-23 Reserved
予約スケーラブル拡張21-23で20符号化スライス
Type 20 NAL units are placed in increasing order of DQId.
Within each DQId value, they are placed in session order.
(Note: SVC slices with a given DQId value will be sent within only a single session for any given access unit.)
（注：所与DQId値を有するSVCスライスは、任意のアクセスユニットのための単一のセッション内で送信されます。）
Type 21-23 NAL units are placed immediately following the non-reserved-type VCL NAL unit they follow in session order.
21-23 NALユニットに入力し、それらがセッションのために、以下の非予約型VCL NALユニットの直後に配置されています。
10 End of sequence
シーケンスの10エンド
11 End of stream
ストリームの終わり11
The following process MUST be used when either the NI-C or I-C MST packetization mode is in use. The following process MAY be applied when the NI-TC MST packetization mode is in use.
NI-C又はI-C MSTパケット化モードのいずれかが使用中である場合。以下の方法を使用しなければなりませんNI-TC MSTパケット化モードが使用されている場合は、次のプロセスが適用されてもよいです。
The RTP packets output from the RTP-level reception processing for each session are placed into a re-multiplexing buffer.
各セッションのRTPレベルの受信処理からRTPパケット出力は、再多重化バッファに置かれます。
It is RECOMMENDED to set the size of the re-multiplexing buffer (in bytes) equal to or greater than the value of the sprop-remux-buf-req media type parameter of the highest RTP session the receiver receives.
受信機が受信した最高のRTPセッションのsprop-リマックス-BUF-REQメディアタイプパラメータの値以上（バイト数）を再多重化バッファのサイズを設定することが推奨されます。
The CS-DON value is calculated and stored for each NAL unit.
CS-DON値は、各NALユニットについて計算されて記憶されます。
Informative note: The CS-DON value of a NAL unit may rely on information carried in another packet than the packet containing the NAL unit. This happens, e.g., when the CS-DON values need to be derived for non-PACSI NAL units contained in single NAL unit packets, as the single NAL unit packets themselves do not contain CS-DON information. In this case, when no packet containing required CS-DON information is received for a NAL unit, this NAL unit has to be discarded by the receiver as it cannot be fed to the decoder in the correct order. When the optional media type parameter sprop-mst-csdon-always-present is equal to 1, no such dependency exists, i.e., the CS-DON value of any particular NAL unit can be derived solely according to information in the packet containing the NAL unit, and therefore, the receiver does not need to discard any received NAL units.
有益な注意：NALユニットのCS-DON値は、NALユニットを含むパケットとは別のパケットで運ばれた情報に依存してもよいです。 CS-DON値は、単一NALユニットパケットとして自身がCS-DON情報が含まれていない、単一NALユニットパケットに含まれる非PACSI NALユニットに由来する必要がある場合、これは、例えば、起こります。必要CS-DON情報を含む全くパケットがNALユニットのために受信されていない場合この場合には、このNALユニットは、それが正しい順序でデコーダに供給することができないように、受信機によって廃棄されなければなりません。オプションのメディアタイプパラメータのsprop-MST-csdon-常に存在するが1に等しい場合、そのような依存関係が存在しない、すなわち、任意の特定のNALユニットのCS-DON値は、NALを含むパケット内の情報に応じて単独で導出することができますユニット、したがって、受信機は、任意の受信されたNALユニットを廃棄する必要がありません。
The receiver operation is described below with the help of the following functions and constants:
受信動作は以下の関数と定数の助けを借りて以下に説明します。
o Function AbsDON is specified in Section 8.1 of [RFC6184].
O機能AbsDONは、[RFC6184]のセクション8.1で指定されています。
o Function don_diff is specified in Section 5.5 of [RFC6184].
O機能don_diffは、[RFC6184]の5.5節で指定されています。
o Constant N is the value of the OPTIONAL sprop-mst-remux-buf-size media type parameter of the highest RTP session incremented by 1.
O定数Nが1だけインクリメント最高RTPセッションのOPTIONALのsprop-MST-リマックス-BUFサイズ、メディアタイプパラメータの値です。
Initial buffering lasts until one of the following conditions is fulfilled:
次のいずれかの条件が満たされるまで、初期バッファリングが続きます：
o There are N or more VCL NAL units in the re-multiplexing buffer.
O N以上のVCL NALユニットは、再多重化バッファです。
o If sprop-mst-max-don-diff of the highest RTP session is present, don_diff(m,n) is greater than the value of sprop-mst-max-don-diff of the highest RTP session, where n corresponds to the NAL unit having the greatest value of AbsDON among the received NAL units and m corresponds to the NAL unit having the smallest value of AbsDON among the received NAL units.
最高のRTPセッションのsprop-MST-MAX-ドン-diffが存在する場合にO、don_diff（m、n）は、nはに対応する最高のRTPセッションのsprop-MST-MAX-ドン差分の値よりも大きいです受信されたNALユニットとMの間でAbsDONの最大値を有するNALユニットは、受信したNALユニットのうち、AbsDONの最小値を有するNALユニットに相当します。
o Initial buffering has lasted for the duration equal to or greater than the value of the OPTIONAL sprop-remux-init-buf-time media type parameter of the highest RTP session.
O初期バッファリングは、等しい又は最高のRTPセッションのOPTIONALのsprop-リマックス-INIT-BUFタイムメディアタイプパラメータの値よりも大きい期間にわたって続きました。
The NAL units to be removed from the re-multiplexing buffer are determined as follows:
次のように再多重化バッファから除去されるNALユニットが決定されます。
o If the re-multiplexing buffer contains at least N VCL NAL units, NAL units are removed from the re-multiplexing buffer and passed to the decoder in the order specified below until the buffer contains N-1 VCL NAL units.
再多重化バッファが少なくともN個のVCL NALユニットで含まれている場合は、O、NALユニットは、再多重化バッファから除去され、バッファがN-1個のVCL NALユニットを含むまで以下に指定された順序でデコーダに渡されます。
o If sprop-mst-max-don-diff of the highest RTP session is present, all NAL units m for which don_diff(m,n) is greater than sprop-max-don-diff of the highest RTP session are removed from the re-multiplexing buffer and passed to the decoder in the order specified below. Herein, n corresponds to the NAL unit having the greatest value of AbsDON among the NAL units in the re-multiplexing buffer.
最高のRTPセッションのsprop-MST-MAX-ドン-diffが存在する場合、O、（M、N）は、最高のRTPセッションのsprop-MAX-ドン差分よりも大きいdon_diffのすべてのNALユニットmがから削除され再多重化バッファと下指定された順序でデコーダに渡されます。ここで、Nは、再多重化バッファにおけるNALユニットのうち、AbsDONの最大値を有するNALユニットに相当します。
The order in which NAL units are passed to the decoder is specified as follows:
次のようにNALユニットがデコーダに渡される順序は指定されています。
o Let PDON be a variable that is initialized to 0 at the beginning of the RTP sessions.
O PDONは、RTPセッションの開始時に0に初期化されている変数とします。
o For each NAL unit associated with a value of CS-DON, a CS-DON distance is calculated as follows. If the value of CS-DON of the NAL unit is larger than the value of PDON, the CS-DON distance is equal to CS-DON - PDON. Otherwise, the CS-DON distance is equal to 65535 - PDON + CS-DON + 1.
次のようにCS-DONの値に関連付けられた各NALユニットのOは、CS-DON距離が算出されます。 PDON - NALユニットのCS-DONの値がPDONの値よりも大きい場合、CS-DON距離は、CS-DONに等しいです。そうでなければ、CS-DON距離は65535に等しい - PDON + CS-DON + 1。
o NAL units are delivered to the decoder in increasing order of CS-DON distance. If several NAL units share the same value of CS-DON distance, they can be passed to the decoder in any order.
O NALユニットはCS-DON間隔の昇順でデコーダに配信されます。いくつかのNALユニットがCS-DON距離の同じ値を共有する場合、それらは任意の順序でデコーダに渡すことができます。
o When a desired number of NAL units have been passed to the decoder, the value of PDON is set to the value of CS-DON for the last NAL unit passed to the decoder.
NALユニットの所望の数がデコーダに渡されたときにO、PDONの値がデコーダに渡される最後のNALユニットのためのCS-DONの値に設定されています。
This section specifies the parameters that MAY be used to select optional features of the payload format and certain features of the bitstream. The parameters are specified here as part of the media type registration for the SVC codec. A mapping of the parameters into the Session Description Protocol (SDP) [RFC4566] is also
このセクションは、ペイロード形式とビットストリームの特定の機能のオプション機能を選択するために使用できるパラメータを指定します。パラメータは、SVCコーデックのメディアタイプ登録の一環として、ここで指定されています。セッション記述プロトコル（SDP）[RFC4566]にパラメータのマッピングでもあります
provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP.
SDPを使用するアプリケーションのために提供。等価パラメータは、SDPを使用していない制御プロトコルで使用するために他の場所で定義することができます。
Some parameters provide a receiver with the properties of the stream that will be sent. The names of all these parameters start with "sprop" for stream properties. Some of these "sprop" parameters are limited by other payload or codec configuration parameters. For example, the sprop-parameter-sets parameter is constrained by the profile-level-id parameter. The media sender selects all "sprop" parameters rather than the receiver. This uncommon characteristic of the "sprop" parameters may be incompatible with some signaling protocol concepts, in which case the use of these parameters SHOULD be avoided.
いくつかのパラメータは送信されますストリームの性質を持つ受信機を提供します。これらすべてのパラメータの名前は、ストリームのプロパティの「のsprop」で始まります。これらの「のsprop」パラメータのいくつかは、他のペイロードやコーデックの設定パラメータによって制限されています。例えば、のspropパラメータセットパラメータは、プロファイルレベルIDパラメータによって制約されます。メディア送信者は、すべての「のsprop」パラメータではなく、受信機を選択します。 「のsprop」パラメータのこの珍しい特徴は、これらのパラメータの使用を回避すべき場合には、いくつかのシグナリングプロトコルの概念、と互換性があってもよいです。
The media subtype for the SVC codec has been allocated from the IETF tree.
SVCコーデックのメディアサブタイプは、IETF木から割り当てられています。
The receiver MUST ignore any unspecified parameter.
受信機は、任意の不特定のパラメータを無視しなければなりません。
Informative note: Requiring that the receiver ignore unspecified parameters allows for backward compatibility of future extensions. For example, if a future specification that is backward compatible to this specification specifies some new parameters, then a receiver according to this specification is capable of receiving data per the new payload but ignoring those parameters newly specified in the new payload specification. This provision is also present in [RFC6184].
有益な注意：必要と受信機が未指定のパラメータを無視することは、将来の拡張の下位互換性を維持することができます。本明細書に下位互換性があり、将来の仕様は、いくつかの新しいパラメータを指定している場合、例えば、この明細書によれば、受信機は新しいペイロード当たりのデータを受信するが、新たに新しいペイロード仕様で指定されたパラメータを無視することが可能です。この規定は、[RFC6184]にも存在します。
Media Type name: video
メディアタイプ名：ビデオ
Media subtype name: H264-SVC
メディアサブタイプ名：H264-SVC
Required parameters: none
必須パラメータ：なし
OPTIONAL parameters:
オプションのパラメータ：
In the following definitions of parameters, "the stream" or "the NAL unit stream" refers to all NAL units conveyed in the current RTP session in SST, and all NAL units conveyed in the current RTP session and all NAL units conveyed in other RTP sessions that the current RTP session depends on in MST.
パラメータの以下の定義では、「ストリーム」または「NALユニットストリームは、」他のRTPに搬送SSTにおける現在のRTPセッションにおいて伝達すべてのNALユニット、及び現在のRTPセッションにおいて伝達すべてのNALユニットと全てのNALユニットを指し現在のRTPセッションがMSTに依存するセッション。
profile-level-id: A base16 [RFC4648] (hexadecimal) representation of the following three bytes in the sequence parameter set or subset sequence parameter set NAL unit specified in [H.264]: 1) profile_idc; 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits, in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [H.264], but other values for it may be specified in the future by ITU-T or ISO/IEC.
プロファイルレベルID：base16 [RFC4648]（16進数）シーケンスパラメータセット又は[264]で指定されたサブセットシーケンスパラメータセットNALユニット内の次の3バイトの表現：1）profile_idc。 2）バイトは、本明細書に最上位ビットから開始して、ビット・シグニフィカンス順に、constraint_set0_flag、constraint_set1_flag、constraint_set2_flag、constraint_set3_flag、constraint_set4_flag、constraint_set5_flag、及びreserved_zero_2bitsの値で構成される、プロファイルIOPと呼ばれ、3）level_idc 。 reserved_zero_2bitsが[264]で0に等しいことが必要であることに注意し、それに対する他の値は、ITU-TやISO / IECによる将来に指定されてもよいです。
The profile-level-id parameter indicates the default sub-profile, i.e., the subset of coding tools that may have been used to generate the stream or that the receiver supports, and the default level of the stream or the one that the receiver supports.
プロファイルレベルIDパラメータは、すなわち、ストリームを生成または受信機がサポートするために使用されていてもよいツールコーディングのサブセットをデフォルトのサブプロファイルを示し、ストリームのデフォルトレベルまたは受信機サポートするもの。
The default sub-profile is indicated collectively by the profile_idc byte and some fields in the profile-iop byte. Depending on the values of the fields in the profile-iop byte, the default sub-profile may be the same set of coding tools supported by one profile, or a common subset of coding tools of multiple profiles, as specified in Subsection G.7.4.2.1.1 of [H.264]. The default level is indicated by the level_idc byte, and, when profile_idc is equal to 66, 77, or 88 (the Baseline, Main, or Extended profile) and level_idc is equal to 11, additionally by bit 4 (constraint_set3_flag) of the profile-iop byte. When profile_idc is equal to 66, 77, or 88 (the Baseline, Main, or Extended profile) and level_idc is equal to 11, and bit 4 (constraint_set3_flag) of the profile-iop byte is equal to 1, the default level is Level 1b.
デフォルトサブプロファイルはprofile_idcバイトとプロファイルIOPバイトの一部のフィールドによって一括して示されています。サブセクションG.7.4で指定されたプロファイル-IOPバイトのフィールドの値に応じて、既定のサブプロファイルは、つのプロファイルによってサポートされる符号化ツールの同じセット、又は複数のプロファイルの符号化ツールの共通のサブセットであり得ます[264]の.2.1.1。デフォルトレベルはlevel_idcバイトで示す、及び、profile_idcが66、77、または88に等しい（ベースライン、メイン、または拡張プロファイル）とlevel_idcは11に等しく、さらに、ビット4（constraint_set3_flag）によってプロファイルされています-iopバイト。 profile_idcは、77、または88（ベースライン、主な、またはプロファイル拡張）およびlevel_idcは11に等しく、プロファイルIOPバイトのビット4（constraint_set3_flag）が1に等しく、デフォルトのレベルがレベルである66に等しい場合図1b。
Table 13 lists all profiles defined in Annexes A and G of [H.264] and, for each of the profiles, the possible combinations of profile_idc and profile-iop that represent the same sub-profile.
表13のすべてのプロファイル[264]の附属書A及びGで定義され、プロファイルの各々について、同一のサブプロファイルを表すprofile_idcとプロファイルIOPの可能な組み合わせ。
Table 13. Combinations of profile_idc and profile-iop representing the same sub-profile corresponding to the full set of coding tools supported by one profile. In the following, x may be either 0 or 1, while the profile names are indicated as follows. CB: Constrained Baseline profile, B: Baseline profile, M: Main profile, E: Extended profile, H: High profile, H10: High 10 profile, H42: High 4:2:2 profile, H44: High 4:4:4 Predictive profile, H10I: High 10 Intra profile, H42I: High
テーブルprofile_idcとつのプロファイルによってサポートされる符号化ツールの完全なセットに対応する同一のサブプロファイルを示すプロファイルIOPの13の組み合わせ。以下では、Xは、以下のようにプロファイル名が表示されている間、0または1のいずれであってもよいです。 CB：制約ベースラインプロファイル、B：ベースラインプロファイル、M：メインプロファイル、E：拡張プロファイル、H：ハイプロファイル、H10：ハイ10プロファイル、H42：ハイ4：2：2プロファイル、H44：高4：4：4予測プロファイル、H10I：高10イントラプロファイル、H42I：高
4:2:2 Intra profile, H44I: High 4:4:4 Intra profile, C44I: CAVLC 4:4:4 Intra profile, SB: Scalable Baseline profile, SH: Scalable High profile, and SHI: Scalable High Intra profile.
4：2：2イントラプロファイル、H44I：ハイ4：4：4イントラプロファイル、C44I：CAVLC 4：4：4イントラプロファイル、SB：スケーラブルベースラインプロファイル、SH：スケーラブルなハイプロファイル、およびSHI：スケーラブル高イントラプロファイル。
Profile profile_idc profile-iop (hexadecimal) (binary)
（バイナリ）profile_idcプロファイルIOP（16進数）プロフィール
CB 42 (B) x1xx0000
same as: 4D (M) 1xxx0000
same as: 58 (E) 11xx0000
B 42 (B) x0xx0000
same as: 58 (E) 10xx0000
M 4D (M) 0x0x0000
E 58 00xx0000
H 64 00000000
H10 6E 00000000
H42 7A 00000000
H44 F4 00000000
H10I 6E 00010000
H42I 7A 00010000
H44I F4 00010000
C44I 2C 00010000
SB 53 x0000000
SH 56 0x000000
SHI 56 0x010000
For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 13) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles.
例えば、上記の表に、58（拡張）に等しいプロファイルIOP 11xx0000に等しい42（ベースライン）に等しいprofile_idcに対応する同一のサブプロファイルを示しているとprofile_idcプロファイルIOP x1xx0000に等しいです。 profile_idcとプロファイルIOPの他の組み合わせは、（表13に記載されていない）ことに注意する複数のプロファイルのためのツールをコーディングの共通サブセットにサブプロファイル等価を表すことができます。特定のプロファイルに準拠するデコーダが他のプロファイルに準拠したビットストリームを復号することができるかもしれないことにも留意されたいです。
If profile-level-id is used to indicate stream properties, it indicates that, to decode the stream, the minimum subset of coding tools a decoder has to support is the default sub-profile, and the lowest level the decoder has to support is the default level.
プロファイルレベルIDがストリームのプロパティを示すために使用される場合、それはストリーム、デコーダがサポートしなければならないツールを符号化する最小のサブセットを復号する、ことを示しているデフォルトのサブプロファイルであり、デコーダがサポートしなければならない最低レベルでありますデフォルトレベル。
If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. If max-recv-level is not present, the default level from profile-level-id indicates the highest level the codec wishes to support. If max-recv-level is present, it indicates the highest level the codec supports for receiving. For either receiving or sending, all levels that are lower than the highest level supported MUST also be supported.
プロファイルレベル-idパラメータは、能力交換、またはセッションセットアップのために使用されている場合は、コーデックが、受信と送信の両方のためにサポートされている、既定のサブプロファイルに等しく、符号化ツールのサブセットを示します。 MAX-RECVレベルが存在しない場合、プロファイル・レベル-IDからデフォルトのレベルはコーデックがサポートすることを希望する最高レベルを示します。 MAX-RECVレベルが存在する場合、それはコーデックを受信するためにサポートしている最高レベルを示しています。受信または送信のいずれかのために、サポートされている最高レベルよりも低いすべてのレベルもサポートしなければなりません。
Informative note: Capability exchange and session setup procedures should provide means to list the capabilities for each supported sub-profile separately. For example, the one-of-N codec selection procedure of the SDP Offer/Answer model can be used (Section 10.2 of [RFC3264]). The one-of-N codec selection procedure may also be used to provide different combinations of profile_idc and profile-iop that represent the same sub-profile. When there are many different combinations of profile_idc and profile-iop that represent the same sub-profile, using the one-of-N codec selection procedure may result in a fairly large SDP message. Therefore, a receiver should understand the different equivalent combinations of profile_idc and profile-iop that represent the same sub-profile, and be ready to accept an offer using any of the equivalent combinations.
有益な注意：能力交換とセッションセットアップ手順は、個別にサポートされている各サブプロファイルの機能を一覧表示するための手段を提供する必要があります。例えば、SDPオファー/アンサーモデルの一の-Nコーデック選択手順は、（[RFC3264]のセクション10.2）を使用することができます。一の-Nコーデック選択手順はまた、同じサブプロファイルを表すprofile_idcとプロファイルIOPの異なる組み合わせを提供するために使用され得ます。同じサブプロファイルを表すprofile_idcとプロファイルIOPの多くの異なる組み合わせがある場合、一の-Nコーデック選択手順を使用すると、かなり大きなSDPメッセージをもたらすことができます。したがって、受信機は、同じサブプロファイルを表すprofile_idcとプロファイルIOPの異なる等価な組み合わせを理解し、同等の組み合わせのいずれかを使用してオファーを受け入れる準備ができなければなりません。
If no profile-level-id is present, the Baseline Profile without additional constraints at Level 1 MUST be implied.
何プロファイルレベルIDが存在しない場合、レベル1での追加の制約なしのベースラインプロファイルを暗示しなければなりません。
max-recv-level: This parameter MAY be used to indicate the highest level a receiver supports when the highest level is higher than the default level (the level indicated by profile-level-id). The value of max-recv-level is a base16 (hexadecimal) representation of the two bytes after the syntax element profile_idc in the sequence parameter set NAL unit specified in [H.264]: profile-iop (as defined above) and level_idc. If (the level_idc byte of max-recv-level is equal to 11 and bit 4 of the profile-iop byte of max-recv-level is equal to 1) or (the level_idc byte of max-recv-level is equal to 9 and bit 4 of the profile-iop byte of max-recv-level is equal to 0), the highest level the receiver supports is Level 1b. Otherwise, the highest level the receiver supports is equal to the level_idc byte of max-recv-level divided by 10.
MAX-recvをレベル：このパラメータは、最高レベルが既定レベル（プロファイルレベルIDが示すレベル）よりも高い場合、受信機がサポートする最高レベルを示すために使用され得ます。 （上記で定義した）プロファイルIOPおよびlevel_idc：MAX-RECVレベルの値は、base16（16進数）[264]で指定されたシーケンスパラメータセットNALユニット内の構文要素profile_idc後の2バイトの表現です。場合（MAX-RECVレベルのlevel_idcバイトが11とMAX-RECVレベルのプロファイルIOPバイトのビット4に等しい1に等しい）又は（MAX-RECVレベルのlevel_idcバイトが9に等しいです。そしてMAX-RECVレベルのプロファイルIOPバイトのビット4は、受信機がサポートする最高レベルはレベル1Bある）0に等しいです。そうでなければ、受信機がサポートする最高レベルは10で割ったMAX-RECVレベルのlevel_idcバイトに等しいです。
max-recv-level MUST NOT be present if the highest level the receiver supports is not higher than the default level.
受信機がサポートする最高レベルがデフォルトレベルよりも高くない場合のmax-recvのレベルが存在してはなりません。
max-recv-base-level: This parameter MAY be used to indicate the highest level a receiver supports for the base layer when negotiating an SVC stream. The value of max-recv-base-level is a base16 (hexadecimal) representation of the two bytes after the syntax element profile_idc in the sequence parameter set NAL unit specified in [H.264]: profile-iop (as defined above) and level_idc. If (the level_idc byte of max-recv-level is equal to 11 and bit 4 of the profile-iop byte of max-recv-level is equal to 1) or (the level_idc byte of max-recv-level is equal to 9 and bit 4 of the profile-iop byte of max-recv-level is equal to 0), the highest level the receiver supports for the base layer is Level 1b. Otherwise, the highest level the receiver supports for the base layer is equal to the level_idc byte of max-recv-level divided by 10.
MAX-recvをベースレベル：このパラメータは、SVCストリームを交渉する際、受信機がベース層のためにサポートし、最高レベルを示すために使用されるかもしれません。 MAX-RECVベース・レベルの値が[264]で指定されたシーケンスパラメータセットNALユニット内の構文要素profile_idc後の2バイトのbase16（16進数）である：プロファイルIOPを（上記で定義した通り）とlevel_idc。場合（MAX-RECVレベルのlevel_idcバイトが11とMAX-RECVレベルのプロファイルIOPバイトのビット4に等しい1に等しい）又は（MAX-RECVレベルのlevel_idcバイトが9に等しいです。そしてMAX-RECVレベルのプロファイルIOPバイトのビット4は、受信機は、ベース層のための支持体の最高レベルはレベル1Bである）0に等しいです。そうでなければ、受信機は、ベース層のための支持体の最高レベルは10で割ったMAX-RECVレベルのlevel_idcバイトに等しいです。
max-mbps, max-fs, max-cpb, max-dpb, and max-br: The common properties of these parameters are specified in [RFC6184].
MAX-Mbpsの、MAX-FS、MAX-CPB、MAX-DPB、およびMAX-BR：これらのパラメータの共通の特性は[RFC6184]で指定されています。
max-mbps: This parameter is as specified in [RFC6184].
MAX-Mbpsの：[RFC6184]で指定したように、このパラメータがあります。
max-fs: This parameter is as specified in [RFC6184].
MAX-FS：[RFC6184]で指定したように、このパラメータがあります。
max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 of [H.264]). The max-cpb parameter signals that the receiver has more memory than the minimum amount of coded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-cpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxCPB value in Table A-1 of [H.264] for the signaled highest level is replaced with the value of max-cpb (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed). The value of max-cpb (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed) MUST be greater than or equal to the value of MaxCPB given in Table A-1 of [H.264] for the highest level. Senders MAY use this knowledge to construct coded video streams with greater variation of bitrate than can be achieved with the MaxCPB value in Table A-1 of [H.264].
MAX-CPB：MAX-CPBの値は、VCL HRDパラメータの1000ビットの単位とNAL HRDパラメータ1200ビット単位で最大符号化ピクチャバッファサイズを示す整数です。このパラメータはcpbBrVclFactorとcpbBrNALFactorの単位を使用しないことに注意してください（表A-1 [264]を参照）。受信機は、プロファイルレベルIDパラメータまたはMAX-RECVレベルパラメータの値に搬送シグナリング最高レベルで必要とされる符号化ピクチャバッファメモリの最小量よりも多くのメモリを有しているMAX-CPBパラメータ信号。 MAX-CPBが通知されたとき、受信機は、表A-1 [264]合図最高レベルが交換されるための内MaxCPB値ことを除いて、シグナリング最高レベルに適合NALユニットストリームをデコードできなければなりません（必要なときに考慮cpbBrVclFactorとcpbBrNALFactorを取った後）MAX-CPBの値を持ちます。 （必要なときに考慮cpbBrVclFactorとcpbBrNALFactor服用後）MAX-CPBの値は、最高レベルのために、表A-1 [264]の中で与えられたMaxCPBの値より大きいか等しくなければなりません。送信者は、表A-1 [264]の中MaxCPB値で達成できるよりもビットレートの大きな変化に符号化されたビデオストリームを構築するためにこの知識を使用するかもしれません。
Informative note: The coded picture buffer is used in the
Hypothetical Reference Decoder (HRD, Annex C) of [H.264].
The use of the HRD is recommended in SVC encoders to verify
that the produced bitstream conforms to the standard and to
control the output bitrate. Thus, the coded picture buffer
is conceptually independent of any other potential buffers
in the receiver, including de-interleaving, re-multiplexing,
and de-jitter buffers. The coded picture buffer need not be
implemented in decoders as specified in Annex C of [H.264];
standard-compliant decoders can have any buffering
arrangements provided that they can decode standard-
compliant bitstreams. Thus, in practice, the input buffer
for video decoder can be integrated with the de-
interleaving, re-multiplexing, and de-jitter buffers of the
receiver.
max-dpb: This parameter is as specified in [RFC6184].
MAX-DPB：[RFC6184]で指定したように、このパラメータです。
max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 of [H.264]).
MAX-BR：MAX-BRの値は、VCL HRDパラメータおよびNAL HRDパラメータの毎秒1200ビットの単位で毎秒1000ビットの単位での最大ビデオビットレートを示す整数です。このパラメータはcpbBrVclFactorとcpbBrNALFactorの単位を使用しないことに注意してください（表A-1 [264]を参照）。
The max-br parameter signals that the video decoder of the receiver is capable of decoding video at a higher bitrate than is required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter.
受信機のビデオデコーダは、プロファイルレベルIDパラメータまたはMAX-RECVレベルパラメータの値に搬送シグナリング最高レベルで必要とされるよりも高いビットレートで復号ビデオが可能なMAX-BRパラメータ信号。
When max-br is signaled, the video codec of the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the following exceptions in the limits specified by the highest level:
MAX-BRが通知された場合に、受信機のビデオコーデックは、最高レベルで指定された限界に以下の例外を除いて、シグナリング最高レベルに適合NALユニットストリームをデコードできなければなりません。
o The value of max-br (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed) replaces the MaxBR value in Table A-1 of [H.264] for the highest level.
MAX-BRの値O（必要なときに考慮cpbBrVclFactorとcpbBrNALFactorを取った後）最高レベルについて表A-1 [264]の中MaxBR値を置き換えます。
o When the max-cpb parameter is not present, the result of the following formula replaces the value of MaxCPB in Table A-1 of [H.264]: (MaxCPB of the signaled level) * max-br / (MaxBR of the signaled highest level).
MAX-CPBパラメータが存在しない場合、O、次式の結果を表にMaxCPBの値を置き換えA-1 [264]の（シグナリングレベルのMaxCPB）の* MAX-BR /（MaxBR合図最高レベル）。
For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000).
MAX-BR 1550等しいメインプロファイルレベル1.2の受信信号能力たとえば、これは、NAL HRDパラメータのVCL HRDパラメータ1550人のキロビット/秒の最大ビデオビットレート、1860人のキロビット/秒の最大ビデオビットレートを示します、および4036458ビットのCPBサイズ（384000分の1550000×1000×1000）。
The value of max-br (after taking cpbBrVclFactor and cpbBrNALFactor into consideration when needed) MUST be greater than or equal to the value MaxBR given in Table A-1 of [H.264] for the signaled highest level.
（必要なときに考慮cpbBrVclFactorとcpbBrNALFactor服用後）MAX-BRの値が通知最高レベルは、表A-1 [264]の中で与えられた値MaxBRより大きいか等しくなければなりません。
Senders MAY use this knowledge to send higher-bitrate video as allowed in the level definition of SVC, to achieve improved video quality.
SVCのレベルの定義で許可された送信者は、改善されたビデオ品質を達成するために、より高いビットレートの映像を送信するためにこの知識を使用するかもしれません。
Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. No assumption can be made from the value of this parameter that the network is capable of handling such bitrates at any given time. In particular, no conclusion can be drawn that the signaled bitrate is possible under congestion control constraints.
有益な注：このパラメータは、シグナリングゲートウェイの設計を容易にするように、ITU-T勧告H.245に類似のコードポイントを補完するために主に添加しました。何の仮定は、ネットワークは、任意の時点でそのようなビットレートを取り扱うことのできる、このパラメータの値から作られることができません。具体的には、いかなる結論はシグナリングビットレートは、輻輳制御制約の下で可能であることを引き出すことはできません。
redundant-pic-cap: This parameter is as specified in [RFC6184].
冗長PICキャップ：[RFC6184]で指定されるように、このパラメータです。
sprop-parameter-sets: This parameter MAY be used to convey any sequence parameter set, subset sequence parameter set, and picture parameter set NAL units (herein referred to as the initial parameter set NAL units) that can be placed in the NAL unit stream to precede any other NAL units in decoding order and that are associated with the default level of profile-level-id. The parameter MUST NOT be used to indicate codec capability in any capability exchange procedure. The value of the parameter is a comma (',') separated list of base64 [RFC4648] representations of the parameter set NAL units as specified in Sections 7.3.2.1, 7.3.2.2, and G.7.3.2.1 of [H.264]. Note that the number of bytes in a parameter set NAL unit is typically less than 10, but a picture parameter set NAL unit can contain several hundreds of bytes.
spropパラメータセット：このパラメータは、NALユニットストリーム内に配置することができる任意のシーケンスパラメータセット、サブセットシーケンスパラメータセット、ピクチャパラメータセットNALユニットを（本明細書でNALユニットを設定された初期パラメータと呼ぶ）を伝達するために使用されるかもしれません復号化順序とそのプロファイルレベルIDのデフォルトレベルに関連付けられている任意の他のNALユニットに先行します。パラメータは任意の能力交換手順にコーデックの能力を示すために使用してはいけません。パラメータの値は（「」）カンマでBASE64のリスト[RFC4648]セクション7.3.2.1で指定されたパラメータセットNALユニットの表現、7.3.2.2、及び[264のG.7.3.2.1分離]。パラメータセットNALユニット内のバイト数が10未満では、典型的には、しかし、ピクチャパラメータセットNALユニットは、バイトの数百を含むことができることに留意されたいです。
Informative note: When several payload types are offered in
the SDP Offer/Answer model, each with its own sprop-
parameter-sets parameter, then the receiver cannot assume
that those parameter sets do not use conflicting storage
locations (i.e., identical values of parameter set identifiers). Therefore, a receiver should buffer all
sprop-parameter-sets and make them available to the decoder
instance that decodes a certain payload type.
sprop-level-parameter-sets: This parameter MAY be used to convey any sequence, subset sequence, and picture parameter set NAL units (herein referred to as the initial parameter set NAL units) that can be placed in the NAL unit stream to precede any other NAL units in decoding order and that are associated with one or more levels different than the default level of profile-level-id. The parameter MUST NOT be used to indicate codec capability in any capability exchange procedure.
sprop-レベルパラメータセット：このパラメータは、先行するNALユニットストリーム内に配置することができる任意の配列、サブセットシーケンス、およびピクチャパラメータセットNALユニットを（本明細書でNALユニットを設定された初期パラメータと呼ぶ）を伝達するために使用されるかもしれません復号化順序およびプロファイルレベルIDのデフォルトのレベルとは異なる1つまたは複数のレベルに関連付けられた任意の他のNALユニット。パラメータは任意の能力交換手順にコーデックの能力を示すために使用してはいけません。
The sprop-level-parameter-sets parameter contains parameter sets for one or more levels that are different than the default level. All parameter sets targeted for use when one level of the default sub-profile is accepted by a receiver are clustered and prefixed with a three-byte field that has the same syntax as profile-level-id. This enables the receiver to install the parameter sets for the accepted level and discard the rest. The three-byte field is named PLId, and all parameter sets associated with one level are named PSL, which has the same syntax as sprop-parameter-sets. Parameter sets for each level are represented in the form of PLId:PSL, i.e., PLId followed by a colon (':') and the base64 [RFC4648] representation of the initial parameter set NAL units for the level. Each pair of PLId:PSL is also separated by a colon. Note that a PSL can contain multiple parameter sets for that level, separated with commas (',').
spropレベルのパラメータセットのパラメータは、デフォルトのレベルは異なる1つ以上のレベルのためのパラメータセットが含まれています。デフォルトサブプロファイルの1つのレベルが受信機によって受け入れられ、使用対象となるすべてのパラメータセットは、クラスタとプロファイルレベルIDと同じシンタックスを有する3バイトのフィールドが付いています。これが受け入れられたレベルのためのパラメータセットをインストールし、残りの部分を破棄し、受信を可能にします。 3バイトのフィールドはPLIDと命名され、そして1つのレベルに関連付けられているすべてのパラメータセットはのspropパラメータセットと同じ構文を持っているPSL、命名されています。各レベルのパラメータセットは、PLIDの形で表され：およびレベルのための初期パラメータセットNALユニットのBASE64 [RFC4648]表現：PSLは、すなわち、コロン（「」）が続くPLID。 PLIDの各ペア：PSLもコロンで分離されています。 （「」）カンマで区切られ、PSLは、そのレベルのための複数のパラメータセットを含むことができることに留意されたいです。
The subset of coding tools indicated by each PLId field MUST be equal to the default sub-profile, and the level indicated by each PLId field MUST be different than the default level.
各PLIDフィールドによって示される符号化ツールのサブセットがデフォルトサブプロファイルに等しくなければならない、そして各PLIDフィールドによって示されるレベルが既定レベルよりも異なっている必要があります。
Informative note: This parameter allows for efficient level downgrade or upgrade in SDP Offer/Answer and out-of-band transport of parameter sets, simultaneously.
有益な注意：このパラメータは、効率的なレベルダウングレードすることができますまたは同時に、SDPオファー/回答およびパラメータセットのアウトオブバンド輸送にアップグレードしてください。
in-band-parameter-sets: This parameter MAY be used to indicate a receiver capability. The value MAY be equal to either 0 or 1. The value 1 indicates that the receiver discards out-of-band parameter sets in sprop-parameter-sets and sprop-level-parameter-sets, therefore the sender MUST transmit all parameter sets in-band. The value 0 indicates that the receiver utilizes out-of-band parameter sets included in sprop-parameter-sets and/or sprop-level-parameter-sets. However, in this case, the sender MAY still choose to send parameter sets in-band. When the parameter is not present, this receiver capability is not specified, and therefore the sender MAY send out-of-band parameter sets only, or it MAY send in-band-parameter-sets only, or it MAY send both.
インバンド・パラメータセット：このパラメータは、受信機の性能を示すために使用されるかもしれません。値1は、受信機の廃棄は、アウトオブバンドのspropパラメータセットとのsprop-レベルパラメータセットのパラメータセット、したがって、送信者は、内のすべてのパラメータセットを送信しなければならないことを示す0または1のいずれかの値に等しくてもよいです-バンド。値0は、受信機がのspropパラメータセット及び/又はのspropレベルパラメータセットに含まれるアウトオブバンドパラメータセットを利用することを示しています。しかし、この場合には、送信者がまだインバンドパラメータセットを送信するために選ぶかもしれません。パラメータが存在しない場合、この受信機能が指定されていないので、送信側は、アウトオブバンドパラメータセットを送信することができる、またはそれだけインバンドパラメータセットを送信することができる、またはそれは両方を送信することができます。
packetization-mode: This parameter is as specified in [RFC6184]. When the mst-mode parameter is present, the value of this parameter is additionally constrained as follows. If mst-mode is equal to "NI-T", "NI-C", or "NI-TC", packetization-mode MUST NOT be equal to 2. Otherwise, (mst-mode is equal to "I-C"), packetization-mode MUST be equal to 2.
パケットモード：[RFC6184]で指定したように、このパラメータがあります。 MST-modeパラメータが存在する場合、以下のように、このパラメータの値は、さらに制約されます。 MST-モードが "NI-T"、 "NI-C"、または "NI-TC" に等しい場合、パケットモードは、（MSTモードが "IC" に等しい）、そうでなければ2に等しいはずがありませんパケットモードは2に等しくなければなりません。
sprop-interleaving-depth: This parameter is as specified in [RFC6184].
spropインターリーブ深さ：[RFC6184]で指定されるように、このパラメータです。
sprop-deint-buf-req: This parameter is as specified in [RFC6184].
sprop-deint-BUF-REQ：[RFC6184]で指定されるように、このパラメータです。
deint-buf-cap: This parameter is as specified in [RFC6184].
deint-BUFキャップ：[RFC6184]で指定されるように、このパラメータです。
sprop-init-buf-time: This parameter is as specified in [RFC6184].
sprop-INIT-BUF-時間：[RFC6184]で指定されるように、このパラメータです。
sprop-max-don-diff: This parameter is as specified in [RFC6184].
sprop-MAX-ドン・デフ：[RFC6184]で指定したように、このパラメータがあります。
max-rcmd-nalu-size: This parameter is as specified in [RFC6184].
MAX-RCMD-NALUサイズ：[RFC6184]で指定したように、このパラメータがあります。
mst-mode: This parameter MAY be used to signal the properties of a NAL unit stream or the capabilities of a receiver implementation. If this parameter is present, multi-session transmission MUST be used. Otherwise (this parameter is not present), single-session transmission MUST be used. When this parameter is present, the following applies. When the value of mst-mode is equal to "NI-T", the NI-T mode MUST be used. When the value of mst-mode is equal to "NI-C", the NI-C mode MUST be used. When the value of mst-mode is equal to "NI-TC", the NI-TC mode MUST be used. When the value of mst-mode is equal to "I-C", the I-C mode MUST be used. The value of mst-mode MUST have one of the following tokens: "NI-T", "NI-C", "NI-TC", or "I-C".
MSTモード：このパラメータは、NALユニットストリームのプロパティまたは受信機の実装の機能を知らせるために使用されるかもしれません。このパラメータが存在する場合、マルチセッション伝送を使用しなければなりません。そうでない場合（このパラメータが存在しない）、シングルセッション伝送を使用しなければなりません。このパラメータが存在する場合、以下が適用されます。 MST-modeの値が "NI-T" に等しい場合、NI-Tモードが使用されなければなりません。 MST-modeの値が "NI-C" に等しい場合、NI-Cモードが使用されなければなりません。 MST-modeの値が "NI-TC" に等しい場合、NI-TCモードを使用しなければなりません。 MST-modeの値が "I-C" に等しい場合、I-Cモードが使用されなければなりません。 "NI-T"、 "NI-C"、 "NI-TC"、または "I-C"：MST-modeの値は、次のトークンのいずれかが必要。
All RTP sessions in an MST MUST have the same value of mst-mode.
MSTのすべてのRTPセッションは、MSTモードの同じ値を持つ必要があります。
sprop-mst-csdon-always-present: This parameter MUST NOT be present when mst-mode is not present or the value of mst-mode is equal to "NI-T" or "I-C". This parameter signals the properties of the NAL unit stream. When sprop-mst-csdon-always-present is present and the value is equal to 1, packetization-mode MUST be equal to 1, and all the RTP packets carrying the NAL unit stream MUST be STAP-A packets containing a PACSI NAL unit that further contains the DONC field or NI-MTAP packets with the J field equal to 1. When sprop-mst-csdon-always-present is present and the value is equal to 1, the CS-DON value of any particular NAL unit can be derived solely according to information in the packet containing the NAL unit.
sprop-MST-csdon-常に存在する：MST-modeが存在しないか、MST-modeの値が "NI-T" 又は "I-C" に等しい場合、このパラメータは存在してはなりません。このパラメータは、NALユニットストリームのプロパティを知らせます。 sprop-MST-csdon-常に存在が存在し、値が1に等しい、パケットモードは1に等しくなければならない、及びNALユニットストリームを搬送するすべてのRTPパケットは、PACSI NALユニットを含むSTAP-Aパケットする必要がある場合その更でき存在し、値が1に等しい場合のsprop-MST-csdon-常に存在する、1に等しいJフィールドとDONCフィールドまたはNI-MTAPパケットを含む任意の特定のNALユニットのCS-DON値NALユニットを含むパケット内の情報に応じて単独で導き出すこと。
When sprop-mst-csdon-always-present is present in the current RTP session, it MUST be present also in all the RTP sessions the current RTP session depends on and the value of sprop-mst-csdon-always-present is identical for the current RTP session and all the RTP sessions on which the current RTP session depends.
sprop-MST-csdon-常に存在は、現在のRTPセッション中に存在する場合、それはすべてのRTPセッション中にも存在しなければならない現在のRTPセッションが依存とのsprop-MST-csdon-常に現在の値が同一です現在のRTPセッションと現在のRTPセッションが依存するすべてのRTPセッション。
sprop-mst-remux-buf-size: This parameter MUST NOT be present when mst-mode is not present or the value of mst-mode is equal to "NI-T". This parameter MUST be present when mst-mode is present and the value of mst-mode is equal to "NI-C", "NI-TC", or "I-C".
sprop-MST-リマックス-BUFサイズ：MST-modeが存在しないか、MST-modeの値が「NI-T」に等しい場合、このパラメータは存在してはなりません。 MSTモードが存在し、MST-modeの値が "NI-C" に等しく、 "NI-TC"、または "I-C" 場合、このパラメータが存在しなければなりません。
This parameter signals the properties of the NAL unit stream. It MUST be set to a value one less than the minimum re-multiplexing buffer size (in NAL units), so that it is guaranteed that receivers can reconstruct NAL unit decoding order as specified in Subsection 6.2.2.
このパラメータは、NALユニットストリームのプロパティを知らせます。サブセクション6.2.2で指定されるように受信機がNALユニットの復号化順序を再構築することができることが保証されるように、それは、（NAL単位）最小再多重化バッファサイズより1小さい値に設定しなければなりません。
The value of sprop-mst-remux-buf-size MUST be an integer in the range of 0 to 32767, inclusive.
sprop-MST-リマックス-BUF-sizeの値は包括32767から0までの範囲の整数でなければなりません。
sprop-remux-buf-req: This parameter MUST NOT be present when mst-mode is not present or the value of mst-mode is equal to "NI-T". It MUST be present when mst-mode is present and the value of mst-mode is equal to "NI-C", "NI-TC", or "I-C".
sprop-リマックス-BUF-REQ：MST-modeが存在しないか、MST-modeの値が「NI-T」に等しい場合、このパラメータは存在してはなりません。 MSTモードが存在し、MST-modeの値が "NI-C" に等しく、 "NI-TC"、または "I-C" ときが存在しなければなりません。
sprop-remux-buf-req signals the required size of the re-multiplexing buffer for the NAL unit stream. It is guaranteed that receivers can recover the decoding order of the received NAL units from the current RTP session and the RTP sessions the current RTP session depends on as specified in Section 6.2.2, when the re-multiplexing buffer size is of at least the value of sprop-remux-buf-req in units of bytes.
sprop-リマックス-BUF-REQは、NALユニットストリームの再多重化バッファの必要なサイズを通知します。再多重化バッファのサイズは、少なくともである場合、セクション6.2.2で指定されるように受信機が現在のRTPセッションが依存する現在のRTPセッションから受信したNALユニットの復号化順とRTPセッションを回復できることが保証されますバイト単位でのsprop-リマックス-BUF-REQの値。
The value of sprop-remux-buf-req MUST be an integer in the range of 0 to 4294967295, inclusive.
sprop-リマックス-BUF-REQの値は4294967295、包括的に0の範囲の整数でなければなりません。
remux-buf-cap: This parameter MUST NOT be present when mst-mode is not present or the value of mst-mode is equal to "NI-T". This parameter MAY be used to signal the capabilities of a receiver implementation and indicates the amount of re-multiplexing buffer space in units of bytes that the receiver has available for recovering the NAL unit decoding order as specified in Section 6.2.2. A receiver is able to handle any NAL unit stream for which the value of the sprop-remux-buf-req parameter is smaller than or equal to this parameter.
リマックス-BUFキャップ：MST-modeが存在しないか、MST-modeの値が「NI-T」に等しい場合、このパラメータは存在してはなりません。このパラメータは、受信機の実装の機能を知らせるために使用され、受信機は、セクション6.2.2で指定されるようにNALユニットの復号化順序を回復するために利用できる有するバイト単位で再多重化バッファ領域の量を示しているかもしれません。受信機は、のsprop-リマックス-BUF-REQパラメータの値がこのパラメータより小さいか等しいされた任意のNALユニットストリームを処理することが可能です。
If the parameter is not present, then a value of 0 MUST be used for remux-buf-cap. The value of remux-buf-cap MUST be an integer in the range of 0 to 4294967295, inclusive.
パラメータが存在しない場合、0の値は、リマックス-BUFキャップするために使用されなければなりません。リマックス-BUFキャップの値は4294967295、包括的に0の範囲の整数でなければなりません。
sprop-remux-init-buf-time: This parameter MAY be used to signal the properties of the NAL unit stream. The parameter MUST NOT be present if mst-mode is not present or the value of mst-mode is equal to "NI-T".
sprop-リマックス-INIT-BUF-時間：このパラメータは、NALユニットストリームの特性を知らせるために使用されるかもしれません。 MST-modeが存在しないか、MST-modeの値が「NI-T」に等しい場合、パラメータが存在してはなりません。
The parameter signals the initial buffering time that a receiver MUST wait before starting to recover the NAL unit decoding order as specified in Section 6.2.2 of this memo.
パラメータは、受信機がこのメモのセクション6.2.2で指定されるようにNALユニットの復号化順序を回復するために開始する前に待機しなければならない初期バッファリング時間を知らせます。
The parameter is coded as a non-negative base10 integer representation in clock ticks of a 90-kHz clock. If the parameter is not present, then no initial buffering time value is defined. Otherwise, the value of sprop-remux-init-buf-time MUST be an integer in the range of 0 to 4294967295, inclusive.
パラメータは、90 kHzのクロックのクロック・ティックで非負base10整数表現として符号化されます。パラメータが存在しない場合は、何の初期バッファリング時間値が定義されていません。そうでない場合、のsprop-リマックス-INIT-BUF-timeの値は4294967295、包括的に0の範囲の整数でなければなりません。
sprop-mst-max-don-diff: This parameter MAY be used to signal the properties of the NAL unit stream. It MUST NOT be used to signal transmitter or receiver or codec capabilities. The parameter MUST NOT be present if mst-mode is not present or the value of mst-mode is equal to "NI-T". sprop-mst-max-don-diff is an integer in the range of 0 to 32767, inclusive. If sprop-mst-max-don-diff is not present, the value of the parameter is unspecified. sprop-mst-max-don-diff is calculated same as sprop-max-don-diff as specified in [RFC6184], with decoding order number being replaced by cross-session decoding order number.
sprop-MST-MAX-ドン差分：このパラメータは、NALユニットストリームの特性を知らせるために使用されるかもしれません。送信機または受信機やコーデック機能を知らせるために使用してはいけません。 MST-modeが存在しないか、MST-modeの値が「NI-T」に等しい場合、パラメータが存在してはなりません。 sprop-MST-MAX-ドン-diffは包括32767から0までの範囲の整数です。 sprop-MST-MAX-ドン-diffが存在しない場合、パラメータの値が指定されていません。 sprop-MST-MAX-ドン-diffは復号化順序番号は、クロスセッション復号順序番号で置き換えられると、[RFC6184]で指定されるようにのsprop-MAX-ドン差分と同じ計算されます。
sprop-scalability-info: This parameter MAY be used to convey the NAL unit containing the scalability information SEI message as specified in Annex G of [H.264]. This parameter MAY be used to signal the contained layers of an SVC bitstream. The parameter MUST NOT be used to indicate codec capability in any capability exchange procedure. The value of the parameter is the base64 [RFC4648] representation of the NAL unit containing the scalability information SEI message. If present, the NAL unit MUST contain only one SEI message that is a scalability information SEI message.
sprop-スケーラビリティ-INFO：このパラメータは、[264]の付属書Gで指定されスケーラビリティ情報SEIメッセージを含むNALユニットを伝えるために使用されるかもしれません。このパラメータは、SVCビットストリームの含有層を知らせるために使用されるかもしれません。パラメータは任意の能力交換手順にコーデックの能力を示すために使用してはいけません。パラメータの値は、スケーラビリティ情報SEIメッセージを含むNALユニットのBASE64 [RFC4648]です。存在する場合、NALユニットは、スケーラビリティ情報SEIメッセージである唯一のSEIメッセージを含まなければなりません。
This parameter MAY be used in an offering or declarative SDP message to indicate what layers (operation points) can be provided. A receiver MAY indicate its choice of one layer using the optional media type parameter scalable-layer-id.
このパラメータを提供することができるもの層（動作点）を示すために提供または宣言SDPメッセージに使用されるかもしれません。受信機は、任意のメディアタイプパラメータスケーラブル層-IDを使用して1つの層のその選択を示すことができます。
scalable-layer-id: This parameter MAY be used to signal a receiver's choice of the offers or declared operation points or layers using sprop-scalability-info or sprop-operation-point-info. The value of scalable-layer-id is a base16 representation of the layer_id[ i ] syntax element in the scalability information SEI message as specified in Annex G of [H.264] or layer-ID contained in sprop-operation-point-info.
スケーラブル層-ID：このパラメータは、オファーやのsprop-スケーラビリティ-情報またはのsprop-運転点-情報を使用して宣言動作点または層の受信者の選択を知らせるために使用されるかもしれません。 [264]または層-IDのsprop-動作点情報に含まれるの付録Gで指定されるように、スケーラブル層-IDの値は、スケーラビリティ情報SEIメッセージにおけるレイヤID [i]のシンタックス要素のbase16表現であります。
sprop-operation-point-info: This parameter MAY be used to describe the operation points of an RTP session. The value of this parameter consists of a comma-separated list of operation-point-description vectors. The values given by the operation-point-description vectors are the same as, or are derived from, the values that would be given for a scalable layer in the scalability information SEI message as specified in Annex G of [H.264], where the term scalable layer in the scalability information SEI message refers to all NAL units associated with the same values of temporal_id, dependency_id, and quality_id. In this memo, such a set of NAL units is called an operation point.
sprop-運転点-情報：このパラメータは、RTPセッションの動作点を記述するために使用されるかもしれません。このパラメータの値は、動作点の説明ベクトルのコンマ区切りのリストで構成されています。動作点の説明ベクトルによって与えられる値と同じであるか、または由来する、[264]の付属書Gで指定されスケーラビリティ情報SEIメッセージにおけるスケーラブルレイヤのために与えられる値は、ここでスケーラビリティ情報SEIメッセージにおける用語スケーラブルレイヤはtemporal_id、のdependency_id、及びquality_idの同じ値に関連付けられたすべてのNALユニットを指します。このメモでは、NALユニットのこのようなセットは、動作点と呼ばれます。
Each operation-point-description vector has ten elements, provided as a comma-separated list of values as defined below. The first value of the operation-point-description vector is preceded by a '<', and the last value of the operation-point-description vector is followed by a '>'. If the sprop-operation-point-info is followed by exactly one operation-point-description vector, this describes the highest operation point contained in the RTP session. If there are two or more operation-point-description vectors, the first describes the lowest and the last describes the highest operation point contained in the RTP session.
各動作点の説明ベクターは、以下に定義されるような値のカンマ区切りリストとして提供され10個の要素を有しています。動作点の説明ベクトルの最初の値が先行する「<」、および動作点の説明ベクトルの最後の値が続いて「>」。 sprop-運転点-情報が正確に一つの動作点記述ベクトルが続いている場合、これはRTPセッションに含まれる最も高い動作点を説明します。二つ以上の操作点記述ベクトルがある場合は、最初は最低説明し、最後には、RTPセッションに含まれる最も高い動作点を説明します。
The values given by the operation-point-description vector are as follows, in the order listed:
動作点の説明ベクトルによって与えられた値は、列挙された順序で、以下の通りであります：
- layer-ID: This value specifies the layer identifier of the operation point, which is identical to the layer_id that would be indicated (for the same values of dependency_id, quality_id, and temporal_id) in the scalability information SEI message. This field MAY be empty, indicating that the value is unspecified. When there are multiple operation-point-description vectors with layer-ID, the values of layer-ID do not need to be consecutive.
- レイヤID：この値は、スケーラビリティ情報SEIメッセージ内（のdependency_id、quality_id、およびtemporal_idの同じ値に対して）に示されるであろうレイヤIDと同一である動作点、の層の識別子を指定します。このフィールドには値が指定されていないことを示す、空でもよいです。層-IDを有する複数の動作点の説明ベクトルが存在する場合、層-IDの値が連続している必要はありません。
- temporal-ID: This value specifies the temporal_id of the operation point. This field MUST NOT be empty.
- 時間的-ID：この値は、動作点のtemporal_idを指定します。このフィールドは空にすることはできません。
- dependency-ID: This values specifies the dependency_id of the operation point. This field MUST NOT be empty.
- 依存-ID：この値は、動作点のdependency_idをを指定します。このフィールドは空にすることはできません。
- quality-ID: This values specifies the quality_id of the operation point. This field MUST NOT be empty.
- 品質-ID：この値は、動作点のquality_idを指定します。このフィールドは空にすることはできません。
- profile-level-ID: This value specifies the profile-level-idc of the operation point in the base16 format. The default sub-profile or default level indicated by the parameter profile-level-ID in the sprop-operation-point-info vector SHALL be equal to or lower than the default sub-profile or default level indicated by profile-level-id, which may be either present or the default value is taken. This field MAY be empty, indicating that the value is unspecified.
- プロファイルレベルID：この値は、base16形式の動作点のプロファイルレベルIDCを指定します。 sprop-動作点情報ベクトルのパラメータプロファイルレベルIDが示すデフォルトサブプロファイルまたはデフォルトレベルは、プロファイルレベルIDが示すデフォルトサブプロファイルまたはデフォルトレベル以下でなければなりませんこれは、現在またはデフォルト値が取られるのいずれであってもよいです。このフィールドには値が指定されていないことを示す、空でもよいです。
- avg-framerate: This value specifies the average frame rate of the operation point. This value is given as an integer in frames per 256 seconds. The field MAY be empty, indicating that the value is unspecified.
- 平均 - フレームレート：この値は、動作点の平均フレームレートを指定します。この値は256秒あたりのフレーム数の整数として与えられます。フィールドの値が指定されていないことを示す、空であってもよいです。
- width: This value specifies the width dimension in pixels of decoded frames for the operation point. This parameter is not directly given in the scalability information SEI message. This field MAY be empty, indicating that the value is unspecified.
- 幅：この値は、動作点のための復号されたフレームのピクセル単位の幅寸法を特定します。このパラメータは、直接、スケーラビリティ情報SEIメッセージに与えられていません。このフィールドには値が指定されていないことを示す、空でもよいです。
- height: This value gives the height dimension in pixels of decoded frames for the operation point. This parameter is not directly given in the scalability information SEI. This field MAY be empty, indicating that the value is unspecified.
- 高さ：この値は、動作点のための復号されたフレームのピクセル単位の高さ寸法を与えます。このパラメータは、直接、スケーラビリティ情報SEIに与えられていません。このフィールドには値が指定されていないことを示す、空でもよいです。
- avg-bitrate: This value specifies the average bitrate of the operation point. This parameter is given as an integer in kbits per second over the entire stream. Note that this parameter is provided in the scalability information SEI message in bits per second and calculated over a variable time window. This field MAY be empty, indicating that the value is unspecified.
- 平均ビットレート：この値は、動作点の平均ビットレートを指定します。このパラメータは、ストリーム全体にわたって毎秒キロビットの整数として与えられます。このパラメータは、秒あたりのビット数でスケーラビリティ情報SEIメッセージに設けられ、可変の時間窓にわたって計算されることに留意されたいです。このフィールドには値が指定されていないことを示す、空でもよいです。
- max-bitrate: This value specifies the maximum bitrate of the operation point. This parameter is given as an integer in kbits per second and describes the maximum bitrate per each one-second window. Note that this parameter is provided in the scalability information SEI message in bits per second and is calculated over a variable time window. This field MAY be empty, indicating that the value is unspecified.
- 最大ビットレート：この値は、動作点の最大ビットレートを指定します。このパラメータは、毎秒キロビットの整数として与えられ、各1秒窓あたりの最大ビットレートを記述しています。このパラメータは、秒あたりのビット数でスケーラビリティ情報SEIメッセージにおいて提供される可変時間窓にわたって計算されることに留意されたいです。このフィールドには値が指定されていないことを示す、空でもよいです。
Similarly to sprop-scalability-info, this parameter MAY be used in an offering or declarative SDP message to indicate what layers (operation points) can be provided. A receiver MAY indicate its choice of the highest layer it wants to send and/or receive using the optional media type parameter scalable-layer-id.
同様のsprop-スケーラビリティ-INFOをするために、このパラメータを提供することができる何層（動作点）を示すために提供または宣言SDPメッセージに使用されるかもしれません。受信機は、送信および/またはオプションのメディアタイプパラメータスケーラブル層-IDを使用して受信したい最上位層のその選択肢を示すことがあります。
sprop-no-NAL-reordering-required: This parameter MAY be used to signal the properties of the NAL unit stream. This parameter MUST NOT be present when mst-mode is not present or the value of mst-mode is not equal to "NI-T". The presence of this parameter indicates that no reordering of non-VCL or VCL NAL units is required for the decoding order recovery process.
sprop-NO-NAL-並べ替えない要：このパラメータは、NALユニットストリームの特性を知らせるために使用されるかもしれません。 MST-modeが存在しないか、MST-modeの値が「NI-T」に等しくない場合、このパラメータは存在してはなりません。このパラメータの存在は、非VCLまたはVCL NALユニットのない並べ替えは、復号化順序の回復処理のために必要とされないことを示しています。
sprop-avc-ready: This parameter MAY be used to indicate the properties of the NAL unit stream. The presence of this parameter indicates that the RTP session, if used in SST, or used in MST combined with other RTP sessions also with this parameter present, can be processed by a [RFC6184] receiver. This parameter MAY be used with RTP sessions with media subtype H264-SVC.
sprop-AVC対応：このパラメータは、NALユニットストリームのプロパティを示すために使用されるかもしれません。このパラメータの存在は、RTPセッションは、このパラメータ存在と他のRTPセッションと組み合わせSSTで使用される、又はMSTで使用される場合、[RFC6184]受信機によって処理されることができることを示しています。このパラメータは、メディアサブタイプH264-SVCとのRTPセッションで使用されるかもしれません。
Encoding considerations: This media type is framed and binary; see Section 4.8 of RFC 4288 [RFC4288].
エンコードの考慮事項：このメディアタイプは、フレームとバイナリされます。 RFC 4288 [RFC4288]のセクション4.8を参照してください。
Security considerations: See Section 8 of RFC 6190.
セキュリティの考慮事項：RFC 6190のセクション8を参照してください。
Published specification: Please refer to RFC 6190 and its Section 13.
公開された仕様：RFC 6190およびその第13節を参照してください。
Additional information: none
追加情報：なし
File extensions: none
ファイル拡張子：なし
Macintosh file type code: none
Macintoshのファイルタイプコード：なし
Object identifier or OID: none
オブジェクト識別子またはOID：なし
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Ye-Kui Wang, yekui.wang@huawei.com
Yエリトリア-K UI王、また損失。華為王@ .COM
Intended usage: COMMON
意図している用法：COMMON
Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time.
使用上の制限：このメディアタイプは、RTP [RFC3550]を介してRTPフレーミングに依存し、したがってのみ転送のために定義されています。他のフレーミングプロトコル内の輸送は、この時点で定義されていません。
Interoperability considerations: The media subtype name contains "SVC" to avoid potential conflict with RFC 3984 and its potential future replacement RTP payload format for H.264 non-SVC profiles.
相互運用性に関する注意事項：メディアサブタイプ名は、RFC 3984およびH.264非SVCプロファイルのその潜在的な将来の代替RTPペイロードフォーマットとの潜在的な競合を避けるため、「SVC」が含まれています。
Applications that use this media type: Real-time video applications like video streaming, video telephony, and video conferencing.
ビデオストリーミング、ビデオ電話、ビデオ会議などのリアルタイムビデオアプリケーション：このメディアタイプを使用するアプリケーション。
Author:
著者：
Ye-Kui Wang, yekui.wang@huawei.com
Yエリトリア-K UI王、また損失。華為王@ .COM
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
変更コントローラ：IESGから委任IETFオーディオ/ビデオ輸送ワーキンググループ。
The media type video/H264-SVC string is mapped to fields in the Session Description Protocol (SDP) as follows:
次のようにメディアタイプビデオ/ H264-SVC列は、セッション記述プロトコル（SDP）内のフィールドにマッピングされます。
o The media name in the "m=" line of SDP MUST be video.
メディア名O「M =」SDPのラインがビデオでなければなりません。
o The encoding name in the "a=rtpmap" line of SDP MUST be H264-SVC (the media subtype).
O SDPの「A = rtpmap」ラインでエンコーディング名は、H264-SVC（メディアサブタイプ）でなければなりません。
o The clock rate in the "a=rtpmap" line MUST be 90000.
O「A = rtpmap」行のクロックレートは90000でなければなりません。
o The OPTIONAL parameters profile-level-id, max-recv-level, max-recv-base-level, max-mbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, in-band-parameter-sets, packetization-mode, sprop-interleaving-depth, deint-buf-cap, sprop-deint-buf-req, sprop-init-buf-time, sprop-max-don-diff, max-rcmd-nalu-size, mst-mode, sprop-mst-csdon-always-present, sprop-mst-remux-buf-size, sprop-remux-buf-req, remux-buf-cap, sprop-remux-init-buf-time, sprop-mst-max-don-diff, and scalable-layer-id, when present, MUST be included in the "a=fmtp" line of SDP. These parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs.
Oオプションのパラメータは、プロファイルレベルID、MAX-RECVレベル、MAX-RECVベースレベル、MAX-Mbpsの、MAX-FS、MAX-CPB、MAX-DPB、MAX-BR、冗長PICキャップを帯域内パラメータセット、パケットモード、のsprop-インターリーブ深さ、deint-BUF-キャップのsprop-deint-BUF-REQ、のsprop-INIT-BUF-時間のsprop-MAX-ドン差分、MAX- RCMD-NALUサイズ、MSTモード、のsprop-MST-csdon-常に存在のsprop-MST-リマックス-BUFサイズ、のsprop-リマックス-BUF-REQ、リマックス-BUF-キャップのsprop-リマックス、INIT- BUF-時間のsprop-MST-MAX-ドン差分、及びスケーラブル層-ID、存在する場合は、SDPの "A =のfmtp" 行に含まれなければなりません。これらのパラメータは、パラメータ=値のペアのセミコロンで区切られたリストの形式で、メディアタイプ文字列として表されます。
o The OPTIONAL parameters sprop-parameter-sets, sprop-level-parameter-sets, sprop-scalability-info, sprop-operation-point-info, sprop-no-NAL-reordering-required, and sprop-avc-ready, when present, MUST be included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576]. For a particular media format (i.e., RTP payload type), a sprop-parameter-sets or sprop-level-parameter-sets MUST NOT be both included in the "a=fmtp" line of SDP and conveyed using the "fmtp" source attribute. When included in the "a=fmtp" line of SDP, these parameters are expressed as a media type string, in the form of a semicolon-separated list of parameter=value pairs. When conveyed using the "fmtp" source attribute, these parameters are only associated with the given source and payload type as parts of the "fmtp" source attribute.
Oオプションのパラメータのspropパラメータセット、のspropレベルパラメータセット、のsprop-スケーラビリティ情報、のsprop-動作点情報、のsprop-NO-NAL-所要並べ替え、およびのsprop-AVC対応、場合現在、SDPの「A =のfmtp」行に含まれるか、[RFC5576]のセクション6.3で指定されるように、「のfmtp」source属性を使用して伝達されなければなりません。特定のメディア・フォーマット（すなわち、RTPペイロードタイプ）の場合、のspropパラメータセットまたはのspropレベルパラメータセットは、SDPの「A =のfmtp」行に含まれ、「のfmtp」ソースを使用して搬送されてはいけません両方属性。 SDPの「A =のfmtp」行に含まれる場合、これらのパラメータは、パラメータ=値のペアのセミコロンで区切られたリストの形式で、メディアタイプ文字列として表されます。 「のfmtp」source属性を使用して搬送する際、これらのパラメータは、「のfmtp」ソース属性の一部として指定されたソースと、ペイロードタイプに関連付けられています。
Informative note: Conveyance of sprop-parameter-sets and
sprop-level-parameter-sets using the "fmtp" source attribute
allows for out-of-band transport of parameter sets in
topologies like Topo-Video-switch-MCU [RFC5117].
When an SVC stream (with media subtype H264-SVC) is offered over RTP using SDP in an Offer/Answer model [RFC3264] for negotiation for unicast usage, the following limitations and rules apply:
（メディアサブタイプH264-SVC有する）SVCストリームはユニキャスト使用のためのネゴシエーション[RFC3264]オファー/アンサーモデルにSDPを使用してRTPの上に提供される場合、以下の制限と規則が適用されます。
o The parameters identifying a media format configuration for SVC are profile-level-id, packetization-mode, and mst-mode. These media configuration parameters (except for the level part of profile-level-id) MUST be used symmetrically when the answerer does not include scalable-layer-id in the answer; i.e., the answerer MUST either maintain all configuration parameters or remove the media format (payload type) completely, if one or more of the parameter values are not supported. Note that the level part of profile-level-id includes level_idc, and, for indication of level 1b when profile_idc is equal to 66, 77, or 88, bit 4 (constraint_set3_flag) of profile-iop. The level part of profile-level-id is changeable.
oをSVC用のメディアフォーマット構成を識別するパラメータは、プロファイルレベルID、パケットモード、及びMSTモードです。 （プロファイルレベルIDのレベル部分を除く）これらのメディアの設定パラメータは、回答者が回答にスケーラブル層-IDが含まれていない場合対称的に使用されなければなりません。すなわち、回答は、いずれかのすべての構成パラメータを維持するか、またはメディアフォーマット（ペイロードタイプ）完全に、パラメータ値の1つ以上がサポートされていない場合を削除する必要があります。 profile_idcプロファイル-IOPの66、77、または88、ビット4（constraint_set3_flag）に等しい場合、プロファイルレベルIDのレベルの一部はレベル1bの表示のために、level_idcを含み、そしてことに留意されたいです。プロファイルレベルIDのレベルの部分は変更可能です。
Informative note: The requirement for symmetric use does not
apply for the level part of profile-level-id, and does not
apply for the other stream properties and capability
parameters.
Informative note: In [H.264], all the levels except for Level 1b are equal to the value of level_idc divided by 10. Level 1b is a level higher than Level 1.0 but lower than Level 1.1, and is signaled in an ad hoc manner. For the Baseline, Main, and Extended profiles (with profile_idc equal to 66, 77, and 88, respectively), Level 1b is indicated by level_idc equal to 11 (i.e., the same as level 1.1) and constraint_set3_flag equal to 1. For other profiles, Level 1b is indicated by level_idc equal to 9 (but note that Level 1b for these profiles is still higher than Level 1, which has level_idc equal to 10, and lower than Level 1.1). In SDP Offer/Answer, an answer may indicate a level equal to or lower than the level indicated in the offer. Due to the ad hoc indication of Level 1b, offerers and answerers must check the value of bit 4 (constraint_set3_flag) of the middle octet of the parameter profile-level-id, when profile_idc is equal to 66, 77, or 88 and level_idc is equal to 11.
有益な注意：[264]では、レベル1Bを除くすべてのレベルが10レベル1Bで割っlevel_idcの値に等しいレベルレベル1.0より高いが1.1のレベルよりも低く、アドホックにシグナリングされます方法。 （それぞれ、66に等しいprofile_idcと、77、及び88）は、ベースライン、メイン、および拡張プロファイル、レベル1bは11に等しいlevel_idc（レベル1.1として、すなわち、同じ）および他について1に等しいconstraint_set3_flagによって示されますプロファイル、レベル1bが9に等しいlevel_idcによって示される（ただし、これらのプロファイルのために、そのレベル1bは依然として10にlevel_idc等しい有するレベル1、より高く、そしてレベル1.1未満で注意されます）。 SDPオファー/アンサーでは、答えは等しいまたはオファーに示されるレベルよりも低いレベルを示すことができます。レベル1B、申し出と回答のアドホック指示がビット4（constraint_set3_flag）の値をチェックしなければならないパラメータプロファイルレベルIDの中間オクテットの、profile_idcが66、77、または88に等しく、level_idcである場合11に等しいです。
To simplify handling and matching of these configurations, the same RTP payload type number used in the offer should also be used in the answer, as specified in [RFC3264]. The same RTP payload type number used in the offer MUST also be used in the answer when the answer includes scalable-layer-id. When the answer does not include scalable-layer-id, the answer MUST NOT contain a payload type number used in the offer unless the configuration is exactly the same as in the offer or the configuration in the answer only differs from that in the offer with a level lower than the default level offered.
[RFC3264]で指定されるように取り扱い及びこれらの構成のマッチングを簡単にするために、提供に使用されるのと同じRTPペイロードタイプ番号はまた、回答に使用されるべきです。オファーで使用したものと同じRTPペイロードタイプ番号も答えは、スケーラブルレイヤ-IDを含む応答で使用されなければなりません。答えはスケーラブル層-IDが含まれていない場合には設定が提供と全く同じであるかの回答の構成でのみ提供してのものと異なる場合を除き、答えは提供に使用されるペイロードタイプ番号を含んではなりません提供するデフォルトのレベルよりも低いレベル。
Informative note: When an offerer receives an answer that does not include scalable-layer-id it has to compare payload types not declared in the offer based on the media type (i.e., video/H264-SVC) and the above media configuration parameters with any payload types it has already declared. This will enable it to determine whether the configuration in question is new or if it is equivalent to configuration already offered, since a different payload type number may be used in the answer.
有益な注意：オファー側は、それがメディアタイプ（すなわち、ビデオ/ H264-SVC）及び上記メディアの設定パラメータとに基づいて提供で宣言されていないペイロードタイプを比較するために持っているスケーラブル層-IDが含まれていない答えを受信した場合任意のペイロードタイプは、それがすでに宣言しています。これは、異なるペイロードタイプ番号が答えで使用することができるので、問題の設定は、新しいものであるか、すでに提供された構成と同等である場合かどうかを判断することが可能となります。
Since an SVC stream may contain multiple operation points, a facility is provided so that an answerer can select a different operation point than the entire SVC stream. Specifically, different operation points MAY be described using the sprop-scalability-info or sprop-operation-point-info parameters. The first one carries the entire scalability information SEI message defined in Annex G of [H.264], whereas the second one may be derived, e.g., as a subset of this SEI message that only contains key information about an operation point. Operation points, in both cases, are associated with a layer identifier.
SVCストリームは、複数の動作点を含むことができるので、回答全体SVCストリームとは異なる動作点を選択することができるように、施設が提供されます。具体的には、異なる動作点がのsprop-スケーラビリティ-INFOまたはのsprop-動作ポイント情報パラメータを用いて記述することができます。最初のものは、第1のみ動作点に関する重要な情報が含まれ、このSEIメッセージの一部として、例えば、誘導することができる一方、[264]の付属書Gで定義された全体のスケーラビリティ情報SEIメッセージを運びます。動作点は、両方の場合において、層識別子に関連付けられています。
If such information (sprop-operation-point-info or sprop-scalability-info) is provided in an offer, an answerer MAY select from the various operation points offered in the sprop-scalability-information or sprop-operation-point-info parameters by including scalable-layer-id in the answer. By this, the answerer indicates its selection of a particular operation point in the received and/or in the sent stream. When such operation point selection takes place, i.e., the answerer includes scalable-layer-id in the answer, the media configuration parameters MUST NOT be present in the answer. Rather, the media configuration that the answerer will use for receiving and/or sending is the one used for the selected operation point as indicated in the offer.
そのような情報は、（のsprop-動作点情報またはのsprop-スケーラビリティ-INFO）オファーで提供される場合、回答はのsprop-スケーラビリティ情報またはのsprop-動作ポイント情報パラメータに提供される様々な動作点から選択することができます。答えにおけるスケーラブルレイヤ-IDを含むこともできます。これにより、回答者は、受信および/または送信されたストリーム内の特定の動作点のその選択を示します。ときにこのような動作点の選択、すなわち、回答者が回答にスケーラブル層-IDを含む、メディア・コンフィギュレーション・パラメータは、回答に存在してはならない、行われます。オファーに示されるように、むしろ、回答を受信及び/又は送信するために使用するメディアの設定は、選択された動作点のために使用されるものです。
Informative note: The ability to perform operation point selection enables a receiver to utilize the scalable nature of an SVC stream.
有益な注意：動作点の選択を実行する能力は、SVCストリームのスケーラブルな性質を利用する受信機を可能にします。
o The parameter max-recv-level, when present, declares the highest level supported for receiving. In case max-recv-level is not present, the highest level supported for receiving is equal to the default level indicated by the level part of profile-level-id. max-recv-level, when present, MUST be higher than the default level.
Oパラメータのmax-recvをレベルは、存在する場合、受信するためにサポートされている最高レベルを宣言します。ケースMAX-RECVレベルに存在しない、受信するためのサポート最高レベルは、プロファイルレベルIDのレベルの一部によって示されるデフォルトのレベルに等しいです。 MAX-recvをレベル、存在する場合、デフォルトのレベルよりも高くなければなりません。
o The parameter max-recv-base-level, when present, declares the highest level of the base layer supported for receiving. When max-recv-base-level is not present, the highest level supported for the base layer is not constrained separately from the SVC stream containing the base layer. The endpoint at the other side MUST NOT send a scalable stream for which the base layer is of a level higher than max-recv-base-level. Parameters declaring receiver capabilities above the default level (max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, and max-recv-level) do not apply to the base layer when max-recv-base-level is present.
OパラメータMAX-RECVベースレベルは、存在する場合、受信するためのサポートベース層の最高レベルを宣言する。 MAX-RECVベースレベルが存在しない場合、ベース層のためのサポートされる最高レベルは、ベース層を含むSVCストリームから別々に制約されません。他方のエンドポイントは、ベース層がMAX-RECVベースレベルよりも高いレベルであるため、スケーラブルなストリームを送ってはいけません。既定レベル以上の受信機能（MAX-Mbpsの、MAX-smbps、MAX-FS、MAX-CPB、MAX-DPB、MAX-BR、およびMAX-RECVレベル）を宣言したパラメータは、ベース層ときMAX-には適用されませんRECVベース・レベルが存在します。
o The parameters sprop-deint-buf-req, sprop-interleaving-depth, sprop-max-don-diff, sprop-init-buf-time, sprop-mst-csdon-always-present, sprop-remux-buf-req, sprop-mst-remux-buf-size, sprop-remux-init-buf-time, sprop-mst-max-don-diff, sprop-scalability-information, sprop-operation-point-info, sprop-no-NAL-reordering-required, and sprop-avc-ready describe the properties of the NAL unit stream that the offerer or answerer is sending for the media format configuration. This differs from the normal usage of the Offer/Answer parameters: normally such parameters declare the properties of the stream that the offerer or the answerer is able to receive. When dealing with SVC, the offerer assumes that the answerer will be able to receive media encoded using the configuration being offered.
Oパラメータのsprop-deint-BUF-REQ、のsprop-インターリーブ深さ、のsprop-MAX-ドン差分、のsprop-INIT-BUF-時間のsprop-MST-csdon-常に存在のsprop-リマックス-BUF-REQ 、のsprop-MST-リマックス-BUF-サイズ、のsprop-リマックス-のinit-BUF-時間、のsprop-MST-MAX-ドン・デフ、のsprop-スケーラビリティ情報、のsprop-運転点-情報、のsprop-NO-NAL所要-reorderingとのsprop-AVC対応は、オファーまたは回答がメディアフォーマット構成に送信していることNALユニットストリームのプロパティを記述する。これは、オファー/アンサーパラメータの通常の使用とは異なる。通常、このようなパラメータは、オファーまたは回答を受信することができることストリームのプロパティを宣言する。 SVCを扱う場合、オファー側は回答が提供されているコンフィギュレーションを使用してエンコードされたメディアを受け取ることができるようになることを想定しています。
Informative note: The above parameters apply for any stream
sent by the declaring entity with the same configuration; i.e.,
they are dependent on their source. Rather than being bound to
the payload type, the values may have to be applied to another
payload type when being sent, as they apply for the
configuration.
o The capability parameters max-mbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, and max-rcmd-nalu-size MAY be used to declare further capabilities of the offerer or answerer for receiving. These parameters MUST NOT be present when the direction attribute is sendonly, and the parameters describe the limitations of what the offerer or answerer accepts for receiving streams.
O能力パラメータ、MAX-FS、MAX-CPB、MAX-DPB、MAX-BR、冗長PICキャップ、および最大RCMD-NALUサイズをオファーまたは回答のさらなる能力を宣言するために使用されるかもしれMAX-Mbpsの受信するため。方向属性がsendonlyであるとき、これらのパラメータは存在してはならない、とのパラメータは、オファー側や回答がストリームを受信するための受け入れ何の制限について説明します。
o When mst-mode is not present and packetization-mode is equal to 2, the following applies.
MSTモードが存在せず、パケット化モードが2に等しいとき、O、以下が適用されます。
o An offerer has to include the size of the de-interleaving buffer, sprop-deint-buf-req, in the offer. To enable the offerer and answerer to inform each other about their capabilities for de-interleaving buffering, both parties are RECOMMENDED to include deint-buf-cap. It is also RECOMMENDED to consider offering multiple payload types with different buffering requirements when the capabilities of the receiver are unknown.
Oオファーは、オファーでデインタリーブバッファのsprop-deint-BUF-REQのサイズを含める必要があります。デインタリーブバッファリングのために彼らの能力についてお互いに通知するオファー側とアンサーを有効にするには、両当事者はdeint-BUF-キャップを含めることをお勧めします。また、受信機の機能が不明であるときに別のバッファリング要件で複数のペイロードタイプを提供して考慮することが推奨されます。
o When mst-mode is present and equal to "NI-C", "NI-TC", or "I-C", the following applies.
MSTモードが存在し、 "NI-C" に等しく、 "NI-TC"、または "I-C" である場合、O、以下が適用されます。
o An offerer has to include sprop-remux-buf-req in the offer. To enable the offerer and answerer to inform each other about their capabilities for re-multiplexing buffering, both parties are RECOMMENDED to include remux-buf-cap. It is also RECOMMENDED to consider offering multiple payload types with different buffering requirements when the capabilities of the receiver are unknown.
Oオファー側は、提供中のsprop-リマックス-BUF-REQを含める必要があります。再多重バッファリングのために彼らの能力についてお互いに通知するオファー側とアンサーを有効にするには、両当事者がリマックス-BUF-キャップを含めることをお勧めします。また、受信機の機能が不明であるときに別のバッファリング要件で複数のペイロードタイプを提供して考慮することが推奨されます。
o The sprop-parameter-sets or sprop-level-parameter-sets parameter, when present (included in the "a=fmtp" line of SDP or conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576]), is used for out-of-band transport of parameter sets. However, when out-of-band transport of parameter sets is used, parameter sets MAY still be additionally transported in-band.
spropパラメータセットまたはのspropレベルパラメータセットのパラメータO、存在する場合（SDPの「A =のfmtp」行に含まれるか、[RFC5576]のセクション6.3で指定されるように、「のfmtp」source属性を使用して伝達） 、パラメータセットのアウトオブバンド搬送するために使用されます。パラメータセットの帯域外トランスポートを使用する場合しかし、パラメータセットは、依然としてさらに帯域内輸送することができます。
The answerer MAY use either out-of-band or in-band transport of parameter sets for the stream it is sending, regardless of whether out-of-band parameter sets transport has been used in the offerer-to-answerer direction. Parameter sets included in an answer are independent of those parameter sets included in the offer, as they are used for decoding two different video streams, one from the answerer to the offerer, and the other in the opposite direction.
回答に関係なくアウトオブバンドパラメータはトランスポートを設定するにはオファー・ツー・アンサー方向で使用されているかどうか、それが送信されるストリームのパラメータセットのいずれかの帯域外または帯域内輸送を使用するかもしれません。彼らは、2つの異なるビデオストリーム、提供者への回答から1、及び反対方向における他方を復号化するために使用される回答に含まれるパラメータセットは、オファーに含まれるものパラメータセットとは無関係です。
The following rules apply to transport of parameter sets in the offerer-to-answerer direction.
次の規則がオファー・ツー・アンサー方向におけるパラメータセットの輸送に適用されます。
o An offer MAY include either or both of sprop-parameter- sets and sprop-level-parameter-sets. If neither sprop-parameter-sets nor sprop-level-parameter-sets is present in the offer, then only in-band transport of parameter sets is used.
提供oをのsprop-PARAMETER-セットとのsprop-レベルパラメータセットのいずれか、または両方を含んでもよいです。どちらのspropパラメータセットものspropレベルのパラメータセットが提供中に存在する場合、唯一の帯域内パラメータセットのトランスポートが使用されます。
o If the answer includes in-band-parameter-sets equal to 1, then the offerer MUST transmit parameter sets in-band. Otherwise, the following applies.
答えは1に等しく、帯域内パラメータセットが含まれている場合、O、次いでオファーは、帯域内パラメータセットを送信しなければなりません。それ以外の場合、以下が適用されます。
o If the level to use in the offerer-to-answerer direction is equal to the default level in the offer, the following applies.
オファー側ツー回答方向で使用するレベルは提供のデフォルトのレベルに等しい場合、O、以下が適用されます。
The answerer MUST be prepared to use the parameter sets
included in sprop-parameter-sets, when present, for
decoding the incoming NAL unit stream, and ignore sprop-
level-parameter-sets, when present.
When sprop-parameter-sets is not present in the offer, in-band transport of parameter sets MUST be used.
spropパラメータセットが提供中に存在しない場合、パラメータセットの帯域内輸送が使用されなければなりません。
o Otherwise (the level to use in the offerer-to-answerer direction is not equal to the default level in the offer), the following applies.
Oそうでない場合（オファー・ツー・アンサー方向で使用するレベルがオファーのデフォルトレベルに等しくない）、以下が適用されます。
The answerer MUST be prepared to use the parameter sets
that are included in sprop-level-parameter-sets for the
accepted level (i.e., the default level in the answer,
which is also the level to use in the offerer-to-answerer
direction), when present, for decoding the incoming NAL
unit stream, and ignore all other parameter sets included
in sprop-level-parameter-sets and sprop-parameter-sets,
when present.
When no parameter sets for the accepted level are present in the sprop-level-parameter-sets, in-band transport of parameter sets MUST be used.
受け入れられたレベルのためのパラメータセットは、のspropレベルパラメータセットに存在しない場合、帯域内パラメータセットのトランスポートを使用しなければなりません。
The following rules apply to transport of parameter sets in the answerer-to-offerer direction.
次の規則が回答対オファー方向におけるパラメータセットの輸送に適用されます。
o An answer MAY include either sprop-parameter-sets or sprop-level-parameter-sets, but MUST NOT include both of the two. If neither sprop-parameter-sets nor sprop-level-parameter-sets is present in the answer, then only in-band transport of parameter sets is used.
O答えはのspropパラメータセットまたはのspropレベルのパラメータセットのいずれかを含むことができるが、二つの両方を含んではいけません。どちらのspropパラメータセットものspropレベルのパラメータセットが答えに存在している場合は、唯一の帯域内パラメータセットのトランスポートが使用されます。
o If the offer includes in-band-parameter-sets equal to 1, then the answerer MUST NOT include sprop-parameter-sets or sprop-level-parameter-sets in the answer and MUST transmit parameter sets in-band. Otherwise, the following applies.
オファーは1に等しく、帯域内パラメータセットが含まれている場合、O、次いで回答は回答でのspropパラメータセットまたはのspropレベルパラメータセットを含めることはできませんと帯域内パラメータセットを送信しなければなりません。それ以外の場合、以下が適用されます。
o If the level to use in the answerer-to-offerer direction is equal to the default level in the answer, the following applies.
回答ツーオファー側方向に使用するためのレベルが答えでデフォルトのレベルに等しい場合、O、以下が適用されます。
The offerer MUST be prepared to use the parameter sets
included in sprop-parameter-sets, when present, for
decoding the incoming NAL unit stream, and ignore sprop-
level-parameter-sets, when present.
When sprop-parameter-sets is not present in the answer, the answerer MUST transmit parameter sets in-band.
spropパラメータセットが答えに存在しない場合、回答は、帯域内のパラメータセットを伝えなければなりません。
o Otherwise (the level to use in the answerer-to-offerer direction is not equal to the default level in the answer), the following applies.
Oそれ以外の場合（回答対オファー方向で使用するレベルが回答のデフォルトレベルに等しくない）、以下が適用されます。
The offerer MUST be prepared to use the parameter sets
that are included in sprop-level-parameter-sets for the
level to use in the answerer-to-offerer direction, when
present in the answer, for decoding the incoming NAL unit
stream, and ignore all other parameter sets included in
sprop-level-parameter-sets and sprop-parameter-sets, when
present in the answer.
When no parameter sets for the level to use in the answerer-to-offerer direction are present in sprop-level-parameter-sets in the answer, the answerer MUST transmit parameter sets in-band.
回答対オファー方向で使用するレベルのためのパラメータセットが答えでのspropレベルパラメータセット内に存在しない場合、回答は、帯域内パラメータセットを送信しなければなりません。
When sprop-parameter-sets or sprop-level-parameter-sets is conveyed using the "fmtp" source attribute as specified in Section 6.3 of [RFC5576], the receiver of the parameters MUST store the parameter sets included in the sprop-parameter-sets or sprop-level-parameter-sets for the accepted level and associate them to the source given as a part of the "fmtp" source attribute. Parameter sets associated with one source MUST only be used to decode NAL units conveyed in RTP packets from the same source. When this mechanism is in use, SSRC collision detection and resolution MUST be performed as specified in [RFC5576].
[RFC5576]のセクション6.3で指定されているのspropパラメータセットまたはのspropレベルパラメータセットを「のfmtp」source属性を使用して搬送されると、パラメータセットを格納しなければならないパラメータの受信機がに含まれるのsprop-PARAMETER-セットまたは受け入れられたレベルのためのspropレベルのパラメータセットと「のfmtp」ソース属性の一部として与えられたソースに関連付けます。一方のソースに関連付けられたパラメータセットは、同じソースからのRTPパケットで搬送されるNALユニットを復号するために使用されなければなりません。このメカニズムが使用されているときに[RFC5576]で指定されるように、SSRC衝突検出および解決を実行しなければなりません。
Informative note: Conveyance of sprop-parameter-sets and sprop-level-parameter-sets using the "fmtp" source attribute may be used in topologies like Topo-Video-switch-MCU [RFC5117] to enable out-of-band transport of parameter sets.
有益な注意：のspropパラメータセットと「のfmtp」ソース属性を使用してのsprop-レベルパラメータセットの搬送は、アウトオブバンド輸送を可能にするために、TOPO-ビデオスイッチ-MCU [RFC5117]のようなトポロジーで使用することができますパラメータセット。
For streams being delivered over multicast, the following rules apply:
マルチキャストを介して配信されるストリームの場合、次の規則が適用されます。
o The media format configuration is identified by profile-level- id, including the level part, packetization-mode, and mst-mode. These media format configuration parameters (including the level part of profile-level-id) MUST be used symmetrically; i.e., the answerer
Oメディアフォーマット構成は、レベル部、パケットモード、及びMST-モードを含むプロファイル、レベルIDによって識別されます。 （プロファイルレベルIDのレベルの一部を含む）は、これらのメディアフォーマット構成パラメータは対称的に使用されなければなりません。すなわち、回答
MUST either maintain all configuration parameters or remove the media format (payload type) completely. Note that this implies that the level part of profile-level-id for Offer/Answer in multicast is not changeable.
すべての構成パラメータを維持するか、または完全にメディアフォーマット（ペイロードタイプ）を除去する必要があります。これはマルチキャストでオファー/アンサー用プロファイルレベルIDのレベルの一部が変更できないことを意味することに留意されたいです。
To simplify handling and matching of these configurations, the same RTP payload type number used in the offer should also be used in the answer, as specified in [RFC3264]. An answer MUST NOT contain a payload type number used in the offer unless the configuration is the same as in the offer.
[RFC3264]で指定されるように取り扱い及びこれらの構成のマッチングを簡単にするために、提供に使用されるのと同じRTPペイロードタイプ番号はまた、回答に使用されるべきです。設定は提供の場合と同じでなければ答えは提供に使用されるペイロードタイプ番号を含めることはできません。
o Parameter sets received MUST be associated with the originating source, and MUST be only used in decoding the incoming NAL unit stream from the same source.
受信Oパラメータセットは、発信元に関連付けられている必要があり、かつ、同じソースから受信NALユニットストリームを復号化で使用されなければなりません。
o The rules for other parameters are the same as above for unicast as long as the above rules are obeyed.
他のパラメータのためのルールがあれば、上記の規則が守られているように、ユニキャストのための上記と同じであるO。
Table 14 lists the interpretation of all the parameters that MUST be used for the various combinations of offer, answer, and direction attributes. Note that the two columns wherein the scalable-layer-id parameter is used only apply to answers, whereas the other columns apply to both offers and answers.
表14に提供、解答、および方向属性の様々な組み合わせのために使用されなければならないすべてのパラメータの解釈。他の列は、オファーと回答の両方に適用され、一方、スケーラブル層-idパラメータが使用される二つのカラムだけ回答に適用されることに留意されたいです。
Table 14. Interpretation of parameters for various combinations of offers, answers, direction attributes, with and without scalable-layer-id. Columns that do not indicate offer or answer apply to both.
オファーの種々の組み合わせのパラメータの表14.解釈、回答、方向属性、スケーラブル層-IDを有するとせず。プランを示すか、両方に適用答えない列。
sendonly --+ answer: recvonly,scalable-layer-id --+ | recvonly w/o scalable-layer-id --+ | | answer: sendrecv, scalable-layer-id --+ | | | sendrecv w/o scalable-layer-id --+ | | | | | | | | | profile-level-id C X C X P max-recv-level R R R R - max-recv-base-level R R R R - packetization-mode C X C X P mst-mode C X C X P sprop-avc-ready P P - - P sprop-deint-buf-req P P - - P sprop-init-buf-time P P - - P sprop-interleaving-depth P P - - P sprop-max-don-diff P P - - P sprop-mst-csdon-always-present P P - - P sprop-mst-max-don-diff P P - - P sprop-mst-remux-buf-size P P - - P sprop-no-NAL-reordering-required P P - - P sprop-operation-point-info P P - - P sprop-remux-buf-req P P - - P sprop-remux-init-buf-time P P - - P sprop-scalability-info P P - - P deint-buf-cap R R R R - max-br R R R R - max-cpb R R R R - max-dpb R R R R - max-fs R R R R - max-mbps R R R R - max-rcmd-nalu-size R R R R - redundant-pic-cap R R R R - remux-buf-cap R R R R - in-band-parameter-sets R R R R - sprop-parameter-sets S S - - S sprop-level-parameter-sets S S - - S scalable-layer-id X O X O -
sendonlyで - +答え：がrecvonly、スケーラブル層-ID - + |がrecvonly W / O拡張性の高い層-ID - + | |答え：SENDRECV、スケーラブル層-ID - + | | | SENDRECV W / O拡張性の高い層-ID - + | | | | | | | | |プロファイルレベルID CXCXPのMAX-RECVレベルRRRRを - MAX-RECVベースレベルRRRRを - PPパケットモードCXCXP MSTモードCXCXP用のsprop-AVC対応 - - Pのsprop-deint-BUF-REQのPP - - P sprop-INIT-BUF時間PP - - Pのsprop-インターリーブ深度PP - - Pとのsprop-MAX-ドン差分PP - - Pのsprop-MST-csdon-常時本PP - - Pのsprop-MST-MAX-ドン差分PP - - Pのsprop-MST-リマックス-BUFサイズPP - - Pのsprop-NO-NAL-並べ替え、必要PP - - Pのsprop-動作点情報PP - - Pとのsprop-リマックス-buf- REQ PP - - Pのsprop-リマックス-INIT-BUF-時間PP - - Pのsprop-スケーラビリティ-INFO PP - - P deint-BUFキャップRRRR - MAX-BRのRRRR - MAX-CPBのRRRR - MAX-DPB RRRR - マックスMAX-MbpsのRRRR - - RRRR -fs MAX-RCMD-NALUサイズRRRR - 冗長PIC-キャップRRRR - リマックス-BUFキャップRRRR - 帯域内パラメータセットのRRRR - SSはのspropパラメータセット - - S sprop-レベルパラメータセットSS - - スケーラブル層-IDのXOXOは、S -
Legend:
伝説：
C: configuration for sending and receiving streams P: properties of the stream to be sent R: receiver capabilities S: out-of-band parameter sets O: operation point selection X: MUST NOT be present -: not usable, when present SHOULD be ignored
C：ストリームPを送受信するための構成：受信機能S：操作点選択X：存在してはならないアウトオブバンドパラメータOセットストリームの特性がRを送信する - ：使用できない、存在するすべきときを無視
Parameters used for declaring receiver capabilities are in general downgradable; i.e., they express the upper limit for a sender's possible behavior. Thus, a sender MAY select to set its encoder using only lower/lesser or equal values of these parameters.
受信機の能力を宣言するために使用されるパラメータは、一般的なダウングレードしています。すなわち、彼らは送信者の可能性行動の上限を表します。したがって、送信者は、これらのパラメータだけ低い/より少ないか又は等しい値を使用してエンコーダを設定することを選択することができます。
Parameters declaring a configuration point are not changeable, with the exception of the level part of the profile-level-id parameter for unicast usage. This expresses values a receiver expects to be used and must be used verbatim on the sender side. If level downgrading (for profile-level-id) is used, an answerer MUST NOT include the scalable-layer-id parameter.
コンフィギュレーション・ポイントを宣言パラメータはユニキャスト使用のプロファイルレベルIDパラメータのレベルの一部を除いて、変更されません。これは、受信機が使用されることを想定し、送信者側でそのまま使用しなければならない値を表現しています。 （プロファイルレベルIDの）レベルの格下げが使用される場合、回答は、スケーラブルレイヤ-idパラメータを含んではいけません。
When a sender's capabilities are declared, and non-downgradable parameters are used in this declaration, then these parameters express a configuration that is acceptable for the sender to receive streams. In order to achieve high interoperability levels, it is often advisable to offer multiple alternative configurations, e.g., for the packetization mode. It is impossible to offer multiple configurations in a single payload type. Thus, when multiple configuration offers are made, each offer requires its own RTP payload type associated with the offer.
送信者の能力が宣言され、非ダウングレードパラメータは、この宣言で使用される場合、これらのパラメータは、送信者がストリームを受信するための許容される設定を発現します。高い相互運用性のレベルを達成するためには、パケット化モードのために、例えば、複数の代替構成を提供することが多いことをお勧めします。単一のペイロードタイプに複数の構成を提供することは不可能です。複数の構成の提供が行われたときにこのように、各オファーは提供に関連した独自のRTPペイロードタイプが必要です。
A receiver SHOULD understand all media type parameters, even if it only supports a subset of the payload format's functionality. This ensures that a receiver is capable of understanding when an offer to receive media can be downgraded to what is supported by the receiver of the offer.
受信機は、それが唯一のペイロード形式の機能のサブセットをサポートしている場合でも、すべてのメディアタイプのパラメータを理解する必要があります。これは、メディアを受信するためのオファーはオファーの受信機によってサポートされているものにダウングレードすることができたときに、受信機が理解することが可能であることを保証します。
An answerer MAY extend the offer with additional media format configurations. However, to enable their usage, in most cases a second offer is required from the offerer to provide the stream property parameters that the media sender will use. This also has the effect that the offerer has to be able to receive this media format configuration, not only to send it.
回答は、追加のメディアフォーマット構成でのオファーを延長することができます。しかし、彼らの使用を可能にするために、ほとんどの場合、二オファーがメディアの送信者が使用するストリーム・プロパティ・パラメータを提供するために、オファー側から必要とされます。これはまた、オファーがそれを送信するだけでなく、このメディア・フォーマットの設定を受信することができるように持っている効果を持っています。
If an offerer wishes to have non-symmetric capabilities between sending and receiving, the offerer can allow asymmetric levels via level-asymmetry-allowed equal to 1. Alternatively, the offerer can offer different RTP sessions, i.e., different media lines declared as "recvonly" and "sendonly", respectively. This may have further implications on the system, and may require additional external semantics to associate the two media lines.
オファーは、オファーは、代替的レベル非対称許容1に等しい介し非対称のレベルを許可することができ、提供者は、異なるRTPセッションを提供することができ、送信側と受信側の間で非対称能力を有することを望む場合、すなわち、異なるメディアラインがrecvonlyで「として宣言しました"および "sendonlyの"、それぞれ。これは、システムにさらに影響する可能性があり、かつ2本のメディアラインを関連付けるために追加の外部セマンティクスが必要な場合があります。
If MST is used, the rules on signaling media decoding dependency in SDP as defined in [RFC5583] apply. The rules on "hierarchical or layered encoding" with multicast in Section 5.7 of [RFC4566] do not
MSTが使用される場合、[RFC5583]で定義されるようにSDPに依存する復号メディアシグナリング上の規則が適用されます。 [RFC4566]のセクション5.7でマルチキャストと「階層または階層符号化」に関するルールはありません
apply, i.e., the notation for Connection Data "c=" SHALL NOT be used with more than one address. Additionally, the order of dependencies of the RTP sessions indicated by the "a=depend" attribute as defined in [RFC5583] MUST represent the decoding order of the VC) NAL units in an access unit, i.e., the order of session dependency is given from the base or the lowest enhancement RTP session (the most important) to the highest enhancement RTP session (the least important).
適用、すなわち、接続データの表記は、「C =」は、2つ以上のアドレスを使用してはなりません。また、「A =依存」で定義された属性を[RFC5583]で示されるRTPセッションの依存性の順序は、VCの復号順序を表現しなければなりません）NALユニットアクセスユニットにおいて、すなわち、セッション依存性の順序が与えられますベース又は最も低い拡張RTPセッション（最も重要な）から最高エンハンスメントRTPセッション（最も重要な）へ。
When SVC over RTP is offered with SDP in a declarative style, as in Real Time Streaming Protocol (RTSP) [RFC2326] or Session Announcement Protocol (SAP) [RFC2974], the following considerations are necessary.
RTPオーバーSVCはリアルタイムストリーミングプロトコル（RTSP）[RFC2326]またはセッションアナウンスメントプロトコル（SAP）[RFC2974]のように、宣言型スタイルでSDPで提供されている場合、以下の考慮事項が必要です。
o All parameters capable of indicating both stream properties and receiver capabilities are used to indicate only stream properties. For example, in this case, the parameter profile-level-id declares the values used by the stream, not the capabilities for receiving streams. This results in that the following interpretation of the parameters MUST be used:
Oストリームのプロパティと受信機能の両方を示すことができるすべてのパラメータは、ストリームのプロパティを示すために使用されます。例えば、この場合には、パラメータプロファイルレベルIDが流れなく、ストリームを受信するための機能によって使用される値を宣言する。これは、以下のパラメータの解釈が使用されなければならないことになります。
Declaring actual configuration or stream properties:
実際の構成またはストリームプロパティの宣言：
- profile-level-id - packetization-mode - mst-mode - sprop-deint-buf-req - sprop-interleaving-depth - sprop-max-don-diff - sprop-init-buf-time - sprop-mst-csdon-always-present - sprop-mst-remux-buf-size - sprop-remux-buf-req - sprop-remux-init-buf-time - sprop-mst-max-don-diff - sprop-scalability-info - sprop-operation-point-info - sprop-no-NAL-reordering-required - sprop-avc-ready
- プロファイルレベルID - パケットモード - MSTモード - のsprop-deint-BUF-REQ - のsprop-インターリーブ深さ - のsprop-MAX-ドン差分 - のsprop-INIT-BUF時間 - のsprop-MST-csdon -always - 現在 - のsprop-MST-リマックス-BUF-サイズ - のsprop-リマックス-BUF-REQ - のsprop-リマックス-のinit-BUF-時間 - のsprop-MST-MAX-丼-diffを - のsprop-スケーラビリティ - 情報 - のsprop -operation点 - 情報 - のsprop-NO-NAL-並べ替え-必要 - のsprop-AVC対応
Out-of-band transporting of parameter sets:
アウトオブバンドパラメータセットの輸送：
- sprop-parameter-sets - sprop-level-parameter-sets
- のspropパラメータセット - のspropレベルパラメータセット
Not usable (when present, they SHOULD be ignored):
（存在する場合、彼らは無視されるべきである）使用できません。
- max-mbps - max-fs - max-cpb - max-dpb - max-br - max-recv-level - max-recv-base-level - redundant-pic-cap - max-rcmd-nalu-size - deint-buf-cap - remux-buf-cap - scalable-layer-id
- MAX-Mbpsの - MAX-FS - MAX-CPB - MAX-DPB - MAX-BR - MAX-RECVレベル - MAX-RECVベースレベル - 冗長PICキャップ - MAX-RCMD-NALUサイズ - deint -bufキャップ - リマックス-BUFキャップ - スケーラブル層-ID
o A receiver of the SDP is required to support all parameters and values of the parameters provided; otherwise, the receiver MUST reject (RTSP) or not participate in (SAP) the session. It falls on the creator of the session to use values that are expected to be supported by the receiving application.
O SDPの受信機が提供されたパラメータの全てのパラメータおよび値をサポートするために必要とされます。そうでない場合、受信機は、（RTSP）を拒否または（SAP）セッションに参加してはいけません。これは、受信アプリケーションでサポートされていることが期待されている値を使用するために、セッションの作成者に当たります。
In the following examples, "{data}" is used to indicate a data string encoded as base64.
以下の実施例では、「{データ}」BASE64のように符号化データ列を示すために使用されます。
Example 1: The offerer offers one video media description including two RTP payload types. The first payload type offers H264, and the second offers H264-SVC. Both payload types have different fmtp parameters as profile-level-id, packetization-mode, and sprop-parameter-sets.
例1：オファー側は、2つのRTPペイロードタイプを含む1本のビデオメディアの説明を提供しています。最初のペイロードタイプは、H264を提供し、第二は、H264-SVCを提供しています。両方のペイロードタイプは、異なるプロファイルレベルID、パケットモードとしてのfmtpパラメータとのspropパラメータセットを有しています。
Offerer -> Answerer SDP message:
申出人 - >回答SDPメッセージ：
m=video 20000 RTP/AVP 97 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;
sprop-parameter-sets={sps0},{pps0};
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
sprop-parameter-sets={sps0},{pps0},{sps1},{pps1};
If the answerer does not support media subtype H264-SVC, it can issue an answer accepting only the base layer offer (payload type 96). In the following example, the receiver supports H264-SVC, so it lists payload type 97 first as the preferred option.
回答は、メディアサブタイプH264-SVCをサポートしていない場合、それが唯一のベース層のオファー（ペイロードタイプ96）を受け入れて答えを出すことができます。次の例では、受信機は、H264-SVCをサポートするので、好ましい選択肢として、第1のペイロードタイプ97を示しています。
Answerer -> Offerer SDP message:
回答 - >申出人SDPメッセージ：
m=video 40000 RTP/AVP 97 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;
sprop-parameter-sets={sps2},{pps2};
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
sprop-parameter-sets={sps2},{pps2},{sps3},{pps3};
7.3.2. Example for Offering a Single SVC Session Using scalable-layer-id
7.3.2. スケーラブル層-IDを使用して単一のSVCのセッションを提供するための例
Example 2: Offerer offers the same media configurations as shown in the example above for receiving and sending the stream, but using a single RTP payload type and including sprop-operation-point-info.
実施例2：受信したストリームを送信するが、単一のRTPペイロードタイプを使用してのsprop-動作点情報を含むために上の例に示すように、申出人が同じメディアの構成を提供します。
Offerer -> Answerer SDP message:
申出人 - >回答SDPメッセージ：
m=video 20000 RTP/AVP 97
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
sprop-parameter-sets={sps0},{sps1},{pps0},{pps1};
sprop-operation-point-info=<1,0,0,0,4de00a,3200,176,144,128,
256>,<2,1,1,0,53000c,6400,352,288,256,512>;
In this example, the receiver supports H264-SVC and chooses the lower operation point offered in the RTP payload type for sending and receiving the stream.
この例では、受信機は、H264-SVCをサポートし、ストリームを送受信するためのRTPペイロードタイプで提供されるより低い動作点を選択します。
Answerer -> Offerer SDP message:
回答 - >申出人SDPメッセージ：
m=video 40000 RTP/AVP 97
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 sprop-parameter-sets={sps2},{sps3},{pps2},{pps3};
scalable-layer-id=1;
In an equivalent example showing the use of sprop-scalability-info instead using the sprop-operation-point-info, the sprop-operation-point-info would be exchanged by the sprop-scalability-info followed by the binary (base16) representation of the Scalability Information SEI message.
代わりのsprop-動作点情報を用いてのsprop-スケーラビリティ-INFOの使用を示す等価の例では、のsprop-動作点の情報は、バイナリ（base16）、続いてのsprop-スケーラビリティ-INFOによって交換される表現スケーラビリティ情報SEIメッセージの。
Example 3: In this example, the offerer offers a multi-session transmission with up to three sessions. The base session media description includes payload types that are backward compatible with
例3：この例では、オファー側は、最大3つのセッションにマルチセッション伝送を提供しています。ベースセッションメディア記述は、との下位互換性のあるペイロードタイプを含みます
[RFC6184], and three different payload types are offered. The other two media are using payload types with media subtype H264-SVC. In each media description, different values of profile-level-id, packetization-mode, mst-mode, and sprop-parameter-sets are offered.
[RFC6184]と、3つの異なるペイロードタイプが提供されています。他の二つのメディアは、メディアサブタイプH264-SVCとペイロードタイプを使用しています。各メディアの説明では、プロファイルレベルID、パケットモード、MSTモードとのspropパラメータセットの異なる値が提供されます。
Offerer -> Answerer SDP message:
申出人 - >回答SDPメッセージ：
a=group:DDP L1 L2 L3
m=video 20000 RTP/AVP 96 97 98
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;
mst-mode=NI-T; sprop-parameter-sets={sps0},{pps0};
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=4de00a; packetization-mode=1;
mst-mode=NI-TC; sprop-parameter-sets={sps0},{pps0};
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=4de00a; packetization-mode=2;
mst-mode=I-C; init-buf-time=156320;
sprop-parameter-sets={sps0},{pps0};
a=mid:L1
m=video 20002 RTP/AVP 99 100
a=rtpmap:99 H264-SVC/90000
a=fmtp:99 profile-level-id=53000c; packetization-mode=1;
mst-mode=NI-T; sprop-parameter-sets={sps1},{pps1};
a=rtpmap:100 H264-SVC/90000
a=fmtp:100 profile-level-id=53000c; packetization-mode=2;
mst-mode=I-C; sprop-parameter-sets={sps1},{pps1};
a=mid:L2
a=depend:99 lay L1:96,97; 100 lay L1:98
m=video 20004 RTP/AVP 101
a=rtpmap:101 H264-SVC/90000
a=fmtp:101 profile-level-id=53001F; packetization-mode=1;
mst-mode=NI-T; sprop-parameter-sets={sps2},{pps2};
a=mid:L3
a=depend:101 lay L1:96,97 L2:99
It is assumed that in this example the answerer only supports the NI-T mode for multi-session transmission. For this reason, it chooses the corresponding payload type (96) for the base RTP session. For the two enhancement RTP sessions, the answerer also chooses the payload types that use the NI-T mode (99 and 101).
なお、この例では回答のみマルチセッション伝送用NI-Tモードをサポートしているものとします。このため、ベースRTPセッションの対応するペイロード・タイプ（96）を選択します。 2つの拡張RTPセッションのために、回答者はまた、NI-Tモード（99と101）を使用するペイロードタイプを選択します。
Answerer -> Offerer SDP message:
回答 - >申出人SDPメッセージ：
a=group:DDP L1 L2 L3
m=video 40000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;
mst-mode=NI-T; sprop-parameter-sets={sps3},{pps3};
a=mid:L1
m=video 40002 RTP/AVP 99
a=rtpmap:99 H264-SVC/90000
a=fmtp:99 profile-level-id=53000c; packetization-mode=1;
mst-mode=NI-T; sprop-parameter-sets={sps4},{pps4};
a=mid:L2
a=depend:99 lay L1:96
m=video 40004 RTP/AVP 101
a=rtpmap:101 H264-SVC/90000
a=fmtp:101 profile-level-id=53001F; packetization-mode=1;
mst-mode=NI-T; sprop-parameter-sets={sps5},{pps5};
a=mid:L3
a=depend:101 lay L1:96 L2:99
7.3.4. Example for Offering Multiple Sessions in MST Including Operation with Answerer Using scalable-layer-id
7.3.4. スケーラブル層-IDを使用して回答して動作を含むMSTに複数のセッションを提供するための一例
Example 4: In this example, the offerer offers a multi-session transmission of three layers with up to two sessions. The base session media description has a payload type that is backward compatible with [RFC6184]. Note that no parameter sets are provided, in which case in-band transport must be used. The other media description contains two enhancement layers and uses the media subtype H264-SVC. It includes two operation point definitions.
例4：この例では、オファーは、最大2つのセッションを有する3層のマルチセッション伝送を提供します。ベースセッションのメディア記述は[RFC6184]との下位互換性のあるペイロードタイプを有しています。帯域内輸送が使用されなければならない場合には、何のパラメータセットが提供されていないことに留意されたいです。他のメディア記述は、二つのエンハンスメントレイヤを含み、メディアサブタイプH264-SVCを使用します。これは、2つの動作点の定義が含まれています。
Offerer -> Answerer SDP message:
申出人 - >回答SDPメッセージ：
a=group:DDP L1 L2
m=video 20000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;
mst-mode=NI-T;
a=mid:L1
m=video 20002 RTP/AVP 97
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53001F; packetization-mode=1;
mst-mode=NI-TC; sprop-operation-point-info=<2,0,1,0,53000c,
3200,352,288,384,512>,<3,1,2,0,53001F,6400,704,576,768,1024>;
a=mid:L2
a=depend:97 lay L1:96
It is assumed that the answerer wants to send and receive the base layer (payload type 96), but it only wants to send and receive the lower enhancement layer, i.e., the one with layer id equal to 2. For this reason, the response will include the selection of the desired layer by setting scalable-layer-id equal to 2. Note that the answer only includes the scalable-layer-id information. The answer could include sprop-parameter-sets in the response.
なお、回答は、ベース層（ペイロードタイプ96）を送信し、受信したいと仮定し、それだけで応答、このため、下部エンハンスメントレイヤ、すなわち、2に等しい階層IDを持つものを送信し、受信したいされています答えが唯一のスケーラブル層-ID情報を含む2ノートに等しいスケーラブル層-IDを設定することにより、所望の層の選択が含まれます。答えは、応答のspropパラメータセットを含めることができます。
Answerer -> Offerer SDP message:
回答 - >申出人SDPメッセージ：
a=group:DDP L1 L2
m=video 40000 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=4de00a; packetization-mode=0;
mst-mode=NI-T;
a=mid:L1
m=video 40002 RTP/AVP 97
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 scalable-layer-id=2;
a=mid:L2
a=depend:97 lay L1:96
7.3.5. Example for Negotiating an SVC Stream with a Constrained Base Layer in SST
7.3.5. SSTでの制約ベース層とのSVCストリームを交渉するための例
Example 5: The offerer (Alice) offers one video description including two RTP payload types with differing levels and packetization modes.
実施例5：提供者（アリス）は、異なるレベル及びパケット化モードを有する2つのRTPペイロードタイプを含む一つのビデオの説明を提供します。
Offerer -> Answerer SDP message:
申出人 - >回答SDPメッセージ：
m=video 20000 RTP/AVP 97 96
a=rtpmap:96 H264-SVC/90000
a=fmtp:96 profile-level-id=53001e; packetization-mode=0;
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53001f; packetization-mode=1;
The answerer (Bridge) chooses packetization mode 1, and indicates that it would receive an SVC stream with the base layer being constrained.
回答（ブリッジ）は、パケット化モード1を選択し、それが拘束されるベース層とSVCストリームを受信することを示しています。
Answerer -> Offerer SDP message:
回答 - >申出人SDPメッセージ：
m=video 40000 RTP/AVP 97 a=rtpmap:97 H264-SVC/90000 a=fmtp:97 profile-level-id=53001f; packetization-mode=1; max-recv-base-level=000d
M =ビデオ40000 RTP / AVP 97 = rtpmap：97 H264-SVC / 90000 =のfmtp：97プロファイルレベルID = 53001f。パケットモード= 1。 MAX-RECVベースレベル= 000D
The answering endpoint must send an SVC stream at Level 3.1. Since the offering endpoint did not declare max-recv-base-level, the base layer of the SVC stream the answering endpoint must send is not specifically constrained. The offering endpoint (Alice) must send an SVC stream at Level 3.1, for which the base layer must be of a level not higher than Level 1.3.
答えるエンドポイントはレベル3.1でSVCストリームを送信する必要があります。募集エンドポイントがMAX-recvをベースレベルを宣言していないので、SVCのベース層は留守番エンドポイントをストリーミング送信する必要があり、特に制約されません。提供エンドポイント（アリス）は、ベース層は、レベル1.3より高くないレベルのものでなければならないため、レベル3.1でのSVCストリームを送信しなければなりません。
Section 8.4 of [RFC6184] applies in this memo, with the following applies additionally for multi-session transmission (MST).
以下は、マルチセッション送信（MST）のためにさらに適用して、[RFC6184]のセクション8.4は、このメモで適用されます。
In MST, regardless of out-of-band or in-band transport of parameter sets are in use, parameter sets required for decoding NAL units carried in one particular RTP session SHOULD be carried in the same session, MAY be carried in a session that the particular RTP session depends on, and MUST NOT be carried in a session that the particular RTP session does not depend on.
MSTに関係なく、パラメータセットの帯域外または帯域内輸送の使用において、ある特定のRTPセッションで運ばNALユニットを復号するために必要なパラメータセットは、同じセッション内で実施すべきであり、そのセッションで実行することができます特定のRTPセッションが依存し、特定のRTPセッションが依存しないことをセッションに運ばれてはなりません。
The security considerations of the RTP Payload Format for H.264 Video specification [RFC6184] apply. Additionally, the following applies.
H.264ビデオ仕様[RFC6184]のためのRTPペイロードフォーマットのセキュリティに関する考慮事項が適用されます。さらに、以下が適用されます。
Decoders MUST exercise caution with respect to the handling of reserved NAL unit types and reserved SEI messages, particularly if they contain active elements, and MUST restrict their domain of applicability to the presentation containing the stream. The safest way is to simply discard these NAL units and SEI messages.
デコーダは、彼らがアクティブな要素が含まれている場合は特に、予約されたNALユニットの種類と予約SEIメッセージの取り扱いに関しては注意を行使しなければならない、とストリームを含むプレゼンテーションへの適用の彼らのドメインを制限する必要があります。最も安全な方法は、単純にこれらのNALユニットとSEIメッセージを破棄することです。
When integrity protection is applied to a stream, care MUST be taken that the stream being transported may be scalable; hence a receiver may be able to access only part of the entire stream.
完全性保護がストリームに適用されている場合、注意が輸送されるストリームは、スケーラブルであり得ることを取らなければなりません。したがって、受信機は、ストリーム全体の一部のみをアクセスすることができます。
End-to-end security with either authentication, integrity, or confidentiality protection will prevent a MANE from performing media-aware operations other than discarding complete packets. And in the case of confidentiality protection it will even be prevented from performing discarding of packets in a media-aware way. To allow any MANE to perform its operations, it will be required to be a trusted entity that is included in the security context establishment. This applies both for the media path and for the RTCP path, if RTCP packets need to be rewritten.
認証、完全性、または機密性保護のいずれかでエンドツーエンドのセキュリティは、完全なパケットを廃棄以外のメディアを意識した操作を実行するからMANEを防ぐことができます。そして、機密性保護の場合にはそれも、メディアを意識したように、パケットの廃棄を実行することを防止することになります。任意のMANEは、その操作を実行できるようにするには、セキュリティコンテキストの確立に含まれている信頼できるエンティティであることが要求されます。 RTCPパケットを書き換える必要がある場合に、メディアパスのためにとRTCPパスの両方に適用されます。
Within any given RTP session carrying payload according to this specification, the provisions of Section 10 of [RFC6184] apply. Reducing the session bitrate is possible by one or more of the following means:
この仕様によれば、ペイロードを運ぶ任意のRTPセッション内で、[RFC6184]のセクション10の規定が適用されます。セッションのビットレートを下げると、次の手段のいずれかの方法で可能です：
a) Within the highest layer identified by the DID field remove any NAL units with QID higher than a certain value.
A）DIDフィールドによって識別される最上位階層内の特定の値以上QIDを持つNALユニットを除去します。
b) Remove all NAL units with TID higher than a certain value.
b）は一定値以上TIDを持つすべてのNALユニットを取り外します。
c) Remove all NAL units associated with a DID higher than a certain value.
C）一定値以上DIDと関連付けられたすべてのNALユニットを取り外します。
Informative note: Removal of all coded slice NAL units
associated with DIDs higher than a certain value in the entire
stream is required in order to preserve conformance of the
resulting SVC stream.
d) Utilize the PRID field to indicate the relative importance of NAL units, and remove all NAL units associated with a PRID higher than a certain value. Note that the use of the PRID is application-specific.
D）NALユニットの相対的な重要性を示すためにPRIDフィールドを利用し、一定値以上PRIDに関連付けられたすべてのNALユニットを除去します。 PRIDの使用は、アプリケーション固有であることに注意してください。
e) Remove NAL units or entire packets according to application-specific rules. The result will depend on the particular coding structure used as well as any additional application-specific functionality (e.g., concealment performed at the receiving decoder). In general, this will result in the reception of a non-conforming bitstream and hence the decoder behavior is not specified by [H.264]. Significant artifacts may therefore appear in the decoded output if the particular decoder implementation does not take appropriate action in response to congestion control.
E）アプリケーション固有の規則に従ってNALユニットまたはパケット全体を削除。結果は、使用される特定の符号化構造ならびに任意の追加のアプリケーション固有の機能（受信デコーダで実行例えば、隠蔽）に依存するであろう。一般に、これは、非準拠のビットストリームの受信になり、したがって、デコーダの動作は[264]で指定されていません。特定のデコーダの実装が輻輳制御に応じて適切な措置をとらない場合に有意なアーチファクトは、従って、復号化された出力に現れることがあります。
Informative note: The discussion above is centered on NAL units rather than packets, primarily because that is the level where senders can meaningfully manipulate the scalable bitstream. The mapping of NAL units to RTP packets is fairly flexible when using aggregation packets. Depending on the nature of the congestion control algorithm, the "dimension" of congestion measurement (packet count or bitrate) and reaction to it (reducing packet count or bitrate or both) can be adjusted accordingly.
有益な注意：これは送信者が有意義スケーラブルビットストリームを操作することができるレベルであるので、主に上記の説明は、NALユニットではなく、パケットを中心とします。集約パケットを使用する場合、RTPパケットのNALユニットのマッピングはかなり柔軟です。輻輳制御アルゴリズムの性質に応じて、輻輳測定（パケット数またはビットレート）の「寸法」とそれに反応（パケット数やビットレート、またはその両方を減少させる）のに応じて調整することができます。
All aforementioned means are available to the RTP sender, regardless of whether that sender is located in the sending endpoint or in a mixer-based MANE.
すべての前述の手段にかかわらず、その送信者は、送信エンドポイントまたはミキサベースMANEに位置しているかどうかの、RTP送信者に利用可能です。
When a translator-based MANE is employed, then the MANE MAY manipulate the session only on the MANE's outgoing path, so that the sensed end-to-end congestion falls within the permissible envelope. As with all translators, in this case, the MANE needs to rewrite RTCP RRs to reflect the manipulations it has performed on the session.
翻訳者ベースMANEを採用した場合検知されたエンド・ツー・エンドの混雑が許容封筒に収まるように、そしてMANEは、唯一MANEの往路でセッションを操作することができます。すべての翻訳者と同じように、この場合には、MANEは、それがセッションで実行した操作を反映するためにRTCP RRを書き換える必要があります。
Informative note: Applications MAY also implement, in addition or separately, other congestion control mechanisms, e.g., as described in [RFC5775] and [Yan].
有益な注意：[RFC5775]で説明されるようにアプリケーションはまた、例えば、付加または別々に、他の輻輳制御メカニズムに実装することができると[ヤン]。
A new media type, as specified in Section 7.1 of this memo, has been registered with IANA.
新しいメディアの種類は、このメモのセクション7.1で指定されるように、IANAに登録されています。
Scalable video coding is a concept that has been around since at least MPEG-2 [MPEG2], which goes back as early as 1993. Nevertheless, it has never gained wide acceptance, perhaps partly because applications didn't materialize in the form envisioned during standardization.
スケーラブル映像符号化は、アプリケーションが中に想定される形で具体化しなかったので、戻って早くも1993年とはいえ、それはおそらく、部分的に、広く受け入れられたことはない行く、少なくともMPEG2 [MPEG2]、以来の周りされている概念であり、標準化。
ISO/IEC MPEG and ITU-T VCEG, respectively, performed a requirement analysis for the SVC project. The MPEG and VCEG requirement documents are available in [JVT-N026] and [JVT-N027], respectively.
ISO / IEC MPEG及びITU-T VCEGは、それぞれ、SVCプロジェクトの要件分析を行いました。 MPEGとVCEG要件文書は、それぞれ、[JVT-N026]および[JVT-N027]で入手可能です。
The following introduces four main application scenarios that the authors consider relevant and that are implementable with this specification.
以下は、著者が関連すると考えられる。この仕様に実装可能であることの4つの主要なアプリケーションシナリオを紹介します。
This well-understood form of the use of layered coding [McCanne] implies that all layers are individually conveyed in their own RTP packet streams, each carried in its own RTP session using the IP (multicast) address and port number as the single demultiplexing point. Receivers "tune" into the layers by subscribing to the IP multicast, normally by using IGMP [IGMP]. Depending on the application scenario, it is also possible to convey a number of layers in one RTP session, when finer operation points within the subset of layers are not needed.
階層化コーディング[McCanne]の使用のこのよく理解形態は、それぞれが単一の分離点としてIP（マルチキャスト）アドレスとポート番号を使用して、自身のRTPセッションで運ば、全ての層が個々に独自のRTPパケットストリームで搬送されることを意味します。通常、IGMPを使用して、IPマルチキャストに加入することにより、層へのレシーバ「調整」[IGMP]。アプリケーションシナリオに応じて、層のサブセット内の細かい動作点が必要とされない場合、1つのRTPセッション内の層の数を伝えることも可能です。
Layered multicast has the great advantage of simplicity and easy implementation. However, it has also the great disadvantage of utilizing many different transport addresses. While the authors consider this not to be a major problem for a professionally maintained content server, receiving client endpoints need to open many ports to IP multicast addresses in their firewalls. This is a practical problem from a firewall and network address translation (NAT) viewpoint. Furthermore, even today IP multicast is not as widely deployed as many wish.
階層化マルチキャストはシンプルで簡単な実装の大きな利点があります。しかし、それはまた、多くの異なるトランスポートアドレスを利用するという大きな欠点があります。著者らは、これは専門的に維持され、コンテンツサーバにとって大きな問題ではないと考える一方で、クライアントのエンドポイントを受け取ることは彼らのファイアウォールにIPマルチキャストアドレスに多くのポートを開く必要があります。これは、ファイアウォールとネットワークアドレス変換（NAT）の観点から、実用上の問題です。さらに、今日でもIPマルチキャストは、として広く多くの願いとして展開されていません。
The authors consider layered multicast an important application scenario for the following reasons. First, it is well understood and the implementation constraints are well known. Second, there may well be large-scale IP networks outside the immediate Internet context that may wish to employ layered multicast in the future. One possible example could be a combination of content creation and core-network distribution for the various mobile TV services, e.g., those being developed by 3GPP (MBMS) [MBMS] and DVB (DVB-H) [DVB-H].
著者は、階層化マルチキャスト、次のような理由のための重要なアプリケーションのシナリオを検討してください。まず、それはよく理解されており、実装上の制約はよく知られています。第二に、今後も階層化マルチキャストを採用したいと思うかもしれ即時インターネットコンテキスト外の大規模IPネットワークがあるかもしれません。 1つの可能な例は、コンテンツの作成や各種モバイルTVサービスのためのコア・ネットワーク配信、例えば、それらは、3GPP（MBMS）によって開発され[MBMS]及びDVB（DVB-H）[DVB-H]の組合せとすることができます。
In this scenario, a streaming server has a repository of stored SVC coded layers for a given content. At the time of streaming, and according to the capabilities, connectivity, and congestion situation of the client(s), the streaming server generates and serves a scalable stream. Both unicast and multicast serving is possible. At the same time, the streaming server may use the same repository of stored layers to compose different streams (with a different set of layers) intended for other audiences.
このシナリオでは、ストリーミングサーバは、指定されたコンテンツの保存されたSVC符号化された層のリポジトリを有しています。ストリーミングの時には、クライアント（複数可）の能力、接続性、および混雑状況に応じて、ストリーミングサーバが生成し、スケーラブルなストリームを提供しています。ユニキャストおよびマルチキャスト配信の両方が可能です。これと同時に、ストリーミングサーバは、他の視聴者のために意図さ（層の異なるセットを有する）異なるストリームを構成するために、格納された層の同じリポジトリを使用してもよいです。
As every endpoint receives only a single SVC RTP session, the number of firewall pinholes can be optimized to one.
すべてのエンドポイントは、単一のSVC RTPセッションを受信すると、ファイアウォールピンホールの数は1つに最適化することができます。
The main difference between this scenario and straightforward simulcasting lies in the architecture and the requirements of the streaming server, and is therefore out of the scope of IETF standardization. However, compelling arguments can be made why such a streaming server design makes sense. One possible argument is related to storage space and channel bandwidth. Another is bandwidth adaptability without transcoding -- a considerable advantage in a congestion controlled network. When the streaming server learns about congestion, it can reduce the sending bitrate by choosing fewer layers when composing the layered stream; see Section 9. SVC is designed to gracefully support both bandwidth ramp-down and bandwidth ramp-up with a considerable dynamic range. This payload format is designed to allow for bandwidth flexibility in the mentioned sense. While, in theory, a transcoding step could achieve a similar dynamic range, the computational demands are impractically high and video quality is typically lowered -- therefore, few (if any) streaming servers implement full transcoding.
このシナリオでわかりやすい同時放送の主な違いは、アーキテクチャにあり、ストリーミングサーバの要件、およびIETF標準の範囲外であるので。そのようなストリーミングサーバの設計は理にかなって、なぜしかし、説得力のある引数を行うことができます。一つの可能な引数は、ストレージ容量とチャネル帯域幅に関連しています。もう一つは、トランスコーディングせずに、帯域幅適応性である - 輻輳制御ネットワークにかなりの利点。ストリーミングサーバが輻輳について学習する場合は、階層化ストリームを構成少ない層を選択して送信ビットレートを減らすことができます。第9節SVCが正常にかなりのダイナミックレンジとの両方の帯域幅のランプダウンと帯域幅のランプアップをサポートするように設計されて参照してください。このペイロード形式が挙げ意味での帯域幅の柔軟性を可能にするように設計されています。 、理論的には、トランスコーディング・ステップは、同様のダイナミックレンジを実現することができますが、計算要求は非現実的に高く、ビデオ品質は一般的に低下した - ので、（もしあれば）少数のストリーミングサーバが完全なトランスコーディングを実装します。
Videoconferencing has traditionally relied on Multipoint Control Units (MCUs). These units connect endpoints in a star configuration and operate as follows. Coded video is transmitted from each endpoint to the MCU, where it is decoded, scaled, and composited to construct output frames, which are then re-encoded and transmitted to the endpoint(s). In systems supporting personalized layout (each user is allowed to select the layout of his/her screen), the compositing and encoding process is performed for each of the receiving endpoints. Even without personalized layout, rate matching still requires that the encoding process at the MCU is performed separately for each endpoint. As a result, MCUs have considerable complexity and introduce significant delay. The cascaded encodings also reduce the video quality. Particularly for multipoint connections, interactive communication is cumbersome as the end-to-end delay is very high [G.114]. A simpler architecture is the switching MCU, in which one of the incoming video streams is redirected to the receiving endpoints. Obviously, only one user at a time can be seen and rate matching cannot be performed, thus forcing all transmitting endpoints to transmit at the lowest bit rate available in the MCU-to-endpoint connections.
ビデオ会議は、伝統的にマルチポイントコントロールユニット（MCUの）に頼っています。これらのユニットは、スター構成でエンドポイントを接続して、次のように動作します。符号化されたビデオは、それが、デコードスケーリング、および再符号化され、エンドポイント（複数可）に送信される出力フレームを構築するために合成されたMCU、各エンドポイントから送信されます。パーソナライズされたレイアウトをサポートするシステムでは合成と符号化プロセスは、受信エンドポイントのそれぞれについて実行される、（各ユーザーは、彼/彼女の画面のレイアウトを選択することができます）。パーソナライズレイアウトすることなく、レートのマッチングは依然としてMCUに符号化処理は、エンドポイントごとに別々に行われることを必要とします。その結果、MCUは、かなりの複雑さを持っており、大幅な遅延を導入します。カスケード接続のエンコーディングは、ビデオ品質を低下させます。エンドツーエンド遅延が非常に高い[G.114]であるように特にマルチポイント接続のために、双方向通信が煩雑です。より単純なアーキテクチャは、入力ビデオストリームの1つは、受信エンドポイントにリダイレクトされたスイッチングMCUです。明らかに、一度に一人のユーザが見ることができ、レートマッチングは、このようにMCU・ツー・エンドポイントの接続に利用可能な最低のビットレートで送信するすべての送信エンドポイントを強制的に行うことができません。
With scalable video coding the MCU can be replaced with an application-level router (ALR): this unit simply selects which incoming packets should be transmitted to which of the receiving endpoints [Eleft]. In such a system, each endpoint performs its own composition of the incoming video streams. Assuming, for example, a system that uses spatial scalability with two layers, personalized layout is equivalent to instructing the ALR to only send the required packets for the corresponding resolution to the particular endpoint. Similarly, rate matching at the ALR for a particular endpoint can be performed by selecting an appropriate subset of the incoming video packets to transmit to the particular endpoint. Personalized layout and rate matching thus become routing decisions, and require no signal processing. Note that scalability also allows participants to enjoy the best video quality afforded by their links, i.e., users no longer have to be forced to operate at the quality supported by the weakest endpoint. Most importantly, the ALR has an insignificant contribution to the end-to-end delay, typically an order of magnitude less than an MCU. This makes it possible to have fully interactive multipoint conferences with even a very large number of participants. There are significant advantages as well in terms of error resilience and, in fact, error tolerance can be increased by nearly an order of magnitude here as well (e.g., using unequal error protection). Finally, the very low delay of an ALR allows these systems to be cascaded, with significant benefits in terms of system design and deployment. Cascading of traditional MCUs is impossible due to the very high delay that even a single MCU introduces.
スケーラブルビデオMCU符号化とアプリケーションレベルのルータ（ALR）で置き換えることができる：このユニットは単に着信パケットが受信エンドポイント[Eleft]のどちらに送信すべきかを選択します。このようなシステムでは、各エンドポイントは、入力ビデオストリームの独自の組成を行います。仮定は、例えば、2層空間スケーラビリティを使用するシステムは、パーソナライズされたレイアウトは、特定のエンドポイントに対応する解像度のために必要なパケットを送信するためのALRに指示することと等価です。同様に、特定のエンドポイントに対してALRに一致率は、特定のエンドポイントに送信するために入力ビデオパケットの適切なサブセットを選択することによって行うことができます。パーソナライズされたレイアウト、レートマッチングは、このようなルーティングの決定になり、何も信号処理を必要としません。スケーラビリティはまた彼らのリンクによって与えられる最高のビデオ品質を楽しむことが参加者を許可することに注意してください、すなわち、ユーザーは、もはや最も弱いエンドポイントでサポートされている品質で動作するように強制する必要がありません。最も重要なのは、ALRは、エンドツーエンド遅延、MCU以下の大きさの通常の順序に意味のない貢献をしています。これは、参加者のも、非常に多くのと完全にインタラクティブなマルチポイント会議を持つことが可能となります。実際には、許容誤差は、ここでもほぼ1桁増加させることができる、そこに大きな利点は、エラー耐性の面で同様であり、（例えば、不均一誤り保護を使用して）。最後に、ALRの非常に低遅延は、これらのシステムは、システムの設計と展開の面で大きなメリットで、カスケード接続することができます。伝統のMCUのカスケード接続が原因であっても、単一のMCUが導入されて非常に高い遅延することは不可能です。
Scalable video coding enables a very significant paradigm shift in videoconferencing systems, bringing the complexity of video communication systems (particularly the servers residing within the network) in line with other types of network applications.
スケーラブルビデオコーディングは、ネットワーク・アプリケーションの他のタイプに合わせてビデオ通信システム（ネットワーク内に存在する特にサーバ）の複雑さをもたらし、テレビ会議システムにおける非常に重要なパラダイムシフトを可能にします。
This scenario is a bit more complex, and designed to optimize the network traffic in a core network, while still requiring only a single pinhole in the endpoint's firewall. One of its key applications is the mobile TV market.
このシナリオでは、もう少し複雑であり、まだエンドポイントのファイアウォール内の単一のピンホールを必要としながら、コアネットワーク内のネットワークトラフィックを最適化するように設計します。その主要なアプリケーションの一つは、モバイルTV市場です。
Consider a large private IP network, e.g., the core network of the Third Generation Partnership Project (3GPP). Streaming servers within this core network can be assumed to be professionally maintained. It is assumed that these servers can have many ports open to the network and that layered multicast is a real option. Therefore, the streaming server multicasts SVC scalable layers, instead of simulcasting different representations of the same content at different bitrates.
大規模なプライベートIPネットワーク、例えば、第三世代パートナーシッププロジェクト（3GPP）のコアネットワークを考えてみましょう。このコアネットワーク内のストリーミングサーバーは、専門的に維持されると仮定することができます。これらのサーバがネットワークに開放多くのポートを持っており、階層化マルチキャストが現実的な選択肢であることをできることが想定されます。従って、ストリーミングサーバマルチキャストSVCスケーラブル層の代わりに、異なるビットレートで同じコンテンツの異なる表現を同時放送。
Also consider many endpoints of different classes. Some of these endpoints may lack the processing power or the display size to meaningfully decode all layers; others may have these capabilities. Users of some endpoints may wish not to pay for high quality and are happy with a base service, which may be cheaper or even free. Other users are willing to pay for high quality. Finally, some connected users may have a bandwidth problem in that they can't receive the bandwidth they would want to receive -- be it through congestion, connectivity, change of service quality, or for whatever other reasons. However, all these users have in common that they don't want to be exposed too much, and therefore the number of firewall pinholes needs to be small.
また、異なるクラスの多くのエンドポイントを検討してください。これらのエンドポイントのいくつかは有意すべての層を復号する処理電力や表示サイズを欠いていてもよいです。他の人がこれらの機能を有することができます。いくつかのエンドポイントのユーザーが安くなる、あるいは無料かもしれない、高品質の支払いにないたいとベースのサービスに満足していることがあります。他のユーザーは、高品質のために支払うことを喜んでいます。それは混雑、接続性、サービス品質の変化を通じ、または他の何らかの理由のためになる - 最後に、いくつかの接続ユーザは、彼らが受け取るしたい帯域幅を受け取ることができないという点で、帯域幅の問題がある可能性があります。しかし、これらすべてのユーザーが、彼らはあまりにもさらされたくないという共通点を持っているので、ファイアウォールピンホールの数が少ないことが必要です。
This situation can be handled best by introducing middleboxes close to the edge of the core network, which receive the layered multicast streams and compose the single SVC scalable bitstream according to the needs of the endpoint connected. These middleboxes are called MANEs throughout this specification. In practice, the authors envision the MANE to be part of (or at least physically and topologically close to) the base station of a mobile network, where all the signaling and media traffic necessarily are multiplexed on the same physical link.
この状況は、階層化マルチキャストストリームを受信し、接続されたエンドポイントのニーズに応じて、単一のSVCスケーラブルビットストリームを構成するコアネットワークのエッジに近い中間装置を導入することによって最もよく処理することができます。これらのミドルボックスは、本明細書を通してマネスと呼ばれています。実際に、著者らは、すべてのシグナリングおよびメディアトラフィックは、必ずしも同一の物理リンク上に多重化されているモバイルネットワークの基地局（または、少なくとも、物理的およびトポロジ的に近い）の一部であるMANEを想像します。
MANEs necessarily need to be fairly complex devices. They certainly need to understand the signaling, so, for example, to associate the payload type octet in the RTP header with the SVC payload type.
鬣は必ずしもかなり複雑なデバイスである必要があります。彼らは確かに、例えば、SVCのペイロードタイプと、RTPヘッダ内のペイロードタイプオクテットを関連付けるために、シグナリングを理解する必要があり、そう。
A MANE may aggregate multiple RTP streams, possibly from multiple RTP sessions, thus to reduce the number of firewall pinholes required at the endpoints, or may optimize the outgoing RTP stream to the MTU size of the outgoing path by utilizing the aggregation and fragmentation mechanisms of this memo. This type of MANE is conceptually easy to implement and can offer powerful features, primarily because it necessarily can "see" the payload (including the RTP payload headers), utilize the wealth of layering information available therein, and manipulate it.
MANEは、複数のRTPエンドポイントで必要なファイアウォールピンホールの数を低減すること、場合によっては複数のRTPセッションから、ストリーム、または凝集および断片化のメカニズムを利用することによって、往路のMTUサイズに発信RTPストリームを最適化することができる集約することができますこのメモ。 MANEこのタイプの実装が概念的に簡単であり、それは必ずしも（RTPペイロードヘッダを含む）ペイロードを「見る」ことができる主な理由は、強力な機能を提供する情報利用できるそこを積層の富を利用し、それを操作することができます。
A MANE can also perform stream thinning, in order to adhere to congestion control principles as discussed in Section 9. While the implementation of the forward (media) channel of such a MANE appears to be comparatively simple, the need to rewrite RTCP RRs makes even such a MANE a complex device.
MANEはまた、このようなMANEの前方（メディア）チャネルの実装は比較的簡単なように見えますが、RTCP RRを書き換える必要がさえ作る第9節で説明したように輻輳制御の原則を遵守するためには、ストリームの間伐を行うことができますこのようMANE複雑なデバイス。
While the implementation complexity of either case of a MANE, as discussed above, is fairly high, the computational demands are comparatively low.
上述したようにMANEのいずれの場合の実装の複雑さは、かなり高いが、計算要求は比較的低いです。
Miska Hannuksela contributed significantly to the designs of the PACSI NAL unit and the NI-C mode for decoding order recovery. Roni Even organized and coordinated the design team for the development of this memo, and provided valuable comments. Jonathan Lennox contributed to the NAL unit reordering algorithm for MST and provided input on several parts of this memo. Peter Amon, Sam Ganesan, Mike Nilsson, Colin Perkins, and Thomas Wiegand were members of the design team and provided valuable contributions. Magnus Westerlund has also made valuable comments. Charles Eckel and Stuart Taylor provided valuable comments after the first WGLC for this document. Xiaohui (Joanne) Wei helped improving Table 13 and the SDP examples.
Miska HannukselaはPACSI NALユニット復号順序回復のためのNI-Cモードの設計に大きく貢献しました。ロニはさえ組織し、このメモの開発のための設計チームをコーディネートし、貴重なコメントを提供しました。ジョナサンレノックスは、MSTのアルゴリズムをリオーダリングNALユニットに寄与し、このメモのいくつかの部分に入力を提供しました。ピーター・アモン、サム・ガネサン、マイク・ニルソン、コリンパーキンス、そしてトーマス・ウィーガンドは、設計チームのメンバーだったと貴重な貢献を提供します。マグヌスウェスターはまた、貴重なコメントをしました。チャールズEckel氏とスチュアート・テイラーは、この文書の最初のWGLC後に貴重なコメントを提供しました。 Xiaohui（ジョアン）ウェイは、表13及びSDPの例を改善する助けました。
The work of Thomas Schierl has been supported by the European Commission under contract number FP7-ICT-248036, project COAST.
トーマスSchierlの仕事は、契約番号FP7-ICT-248036、プロジェクトCOASTの下で、欧州委員会によって支えられてきました。
[H.264] ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services", March 2010.
[264] ITU-T勧告H.264、 "一般的な視聴覚サービスのための高度なビデオコーディング"、2010年3月。
[RFC6184] Wang, Y.-K., Even, R., Kristensen, T., and R. Jesup, "RTP Payload Format for H.264 Video", RFC 6184, May 2011.
[RFC6184]王、Y.-K.、でも、R.、クリステンセン、T.、およびR.ジェサップ、 "H.264ビデオのためのRTPペイロードフォーマット"、RFC 6184、2011年5月。
[ISO/IEC14496-10] ISO/IEC International Standard 14496-10:2005.
[ISO / IEC14496-10] ISO / IEC国際標準14496-10：2005。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]解放され、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[RFC5576]レノックス、J.、オット、J.、およびT. Schierl、RFC 5576、2009年6月 "ソース固有のメディアセッション記述プロトコル（SDP）の属性"。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[RFC5583] Schierl、T.とS.ベンゲル監督、 "セッション記述プロトコルにおけるシグナリングメディアのデコード依存（SDP）"、RFC 5583、2009年7月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051]パーキンス、C.及びT. Schierl、 "RTPの迅速な同期化はフロー"、RFC 6051、2010年11月。
[DVB-H] DVB - Digital Video Broadcasting (DVB); DVB-H Implementation Guidelines, ETSI TR 102 377, 2005.
[DVB-H] DVB - デジタルビデオ放送（DVB）。実装ガイドラインDVB-H、ETSI TR 102 377、2005。
[Eleft] Eleftheriadis, A., R. Civanlar, and O. Shapiro, "Multipoint Videoconferencing with Scalable Video Coding", Journal of Zhejiang University SCIENCE A, Vol. 7, Nr. 5, April 2006, pp. 696-705. (Proceedings of the Packet Video 2006 Workshop.)
[Eleft] Eleftheriadis、A.、R. Civanlar、およびO.シャピロ、浙江大学SCIENCE A誌、Vol "スケーラブルビデオ符号化とマルチポイントビデオ会議"。 7、Nrを。 5、2006年4月、頁696から705まで。 （パケットビデオ2006ワークショップの議事。）
[G.114] ITU-T Rec. G.114, "One-way transmission time", May 2003.
[G.114] ITU-T勧告。 G.114、「一方向の伝送時間」、2003年5月。
[H.241] ITU-T Rec. H.241, "Extended video procedures and control signals for H.300-series terminals", May 2006.
[H.241] ITU-T勧告。 H.241、「H.300シリーズ端末用の拡張映像手順と制御信号」、2006年5月。
[IGMP] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[IGMP]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[JVT-N026] Ohm J.-R., Koenen, R., and Chiariglione, L. (ed.), "SVC requirements specified by MPEG (ISO/IEC JTC1 SC29 WG11)", JVT-N026, available from http://ftp3.itu.ch/av-arch/ jvt-site/2005_01_HongKong/JVT-N026.doc, Hong Kong, China, January 2005.
[JVT-N026]オームJ.-R.、ケーネン、R.、およびChiariglione、L.（編）、HTTPから入手可能な "MPEG（ISO / IEC JTC1 SC29 WG11）によって指定されたSVC要件"、JVT-N026、 ：//ftp3.itu.ch/av-arch/ JVT-サイト/ 2005_01_HongKong / JVT-N026.doc、香港、中国、2005年1月。
[JVT-N027] Sullivan, G. and Wiegand, T. (ed.), "SVC requirements specified by VCEG (ITU-T SG16 Q.6)", JVT-N027, available from http://ftp3.itu.int/av-arch/ jvt-site/2005_01_HongKong/JVT-N027.doc, Hong Kong, China, January 2005.
[JVT-N027]サリバン、G.およびウィーガンド、T.（編。）は、HTTPから入手可能な、JVT-N027、 "VCEG（ITU-T SG16 Q.6）によって指定されたSVC要件"：//ftp3.itu。 INT / AV-アーチ/ JVT-サイト/ 2005_01_HongKong / JVT-N027.doc、香港、中国、2005年1月。
[McCanne] McCanne, S., Jacobson, V., and Vetterli, M., "Receiver-driven layered multicast", in Proc. of ACM SIGCOMM'96, pages 117-130, Stanford, CA, August 1996.
PROCで【McCanne] McCanne、S.、ヤコブソン、V.、およびVetterli、M.、 "受信端末駆動層状マルチキャスト"。 ACM SIGCOMM'96、ページ117から130、スタンフォード大学、カリフォルニア州、1996年8月の。
[MBMS] 3GPP - Technical Specification Group Services and System Aspects; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 6), December 2005.
[MBMS] 3GPP - グループサービス及びシステムアスペクト技術仕様;マルチメディアブロードキャスト/マルチキャストサービス（MBMS）;プロトコルおよびコーデック（リリース6）、2005年12月。
[MPEG2] ISO/IEC International Standard 13818-2:1993.
[MPEG2] ISO / IEC国際規格13818-2：1993。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.、およびR. Lanphier、 "リアルタイムのストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974]ハンドリー、M.、パーキンス、C.、およびE.ウィーラン、 "セッションアナウンスメントプロトコル"、RFC 2974、2000年10月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117]ウェスター、M.とS.ベンゲル監督、 "RTPトポロジ"、RFC 5117、2008年1月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]ルビー、M.、ワトソン、M.、およびL. Vicisano、RFC 5775 "非同期階層は（ALC）プロトコルインスタンス化コーディング" 2010年4月。
[Yan] Yan, J., Katrinis, K., May, M., and Plattner, R., "Media-and TCP-friendly congestion control for scalable video streams", in IEEE Trans. Multimedia, pages 196-206, April 2006.
IEEEトランスで[ヤン]ヤン、J.、Katrinis、K.、月、M.、およびプラットナー、R.、 "スケーラブルビデオストリームのメディアおよびTCPフレンドリーな輻輳制御"、。マルチメディア、ページ196から206、2006年4月。
Authors' Addresses
著者のアドレス
Stephan Wenger 2400 Skyfarm Dr. Hillsborough, CA 94010 USA
ステファン・ベンゲル2400 Skyfarm博士ヒルズボロ、CA 94010 USA
Phone: +1-415-713-5473 EMail: stewe@stewe.org
電話：+ 1-415-713-5473 Eメール：stewe@stewe.org
Ye-Kui Wang Huawei Technologies 400 Crossing Blvd, 2nd Floor Bridgewater, NJ 08807 USA
Yルアー-K UI王HU Aはブルバードを横断する技術400で、2階ブリッジウォーター、NJ 08807 USA
Phone: +1-908-541-3518 EMail: yekui.wang@huawei.com
電話：+ 1-908-541-3518 Eメール：yekui.wang@huawei.com
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
トーマスSchierlフラウンホーファーHHI Einsteinufer 37 D-10587ベルリンドイツ
Phone: +49-30-31002-227 EMail: ts@thomas-schierl.de
電話：+ 49-30-31002-227 Eメール：ts@thomas-schierl.de
Alex Eleftheriadis Vidyo, Inc. 433 Hackensack Ave. Hackensack, NJ 07601 USA
アレックスEleftheriadisにVidyo社433ハッケンサックアベニュー。ハッケンサック、NJ 07601 USA
Phone: +1-201-467-5135 EMail: alex@vidyo.com
電話：+ 1-201-467-5135 Eメール：alex@vidyo.com