[要約] RFC 6190は、可変ビデオコーディングのためのRTPペイロード形式を定義しています。その目的は、可変ビデオコーディングのための効率的なデータ転送を可能にすることです。
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
スケーラブルなビデオコーディング用のRTPペイロード形式
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 International Standard 14496-10の修正3と技術的に同一のITU-T推奨H.264の付録Gで定義されているスケーラブルビデオコーディング（SVC）のRTPペイロード形式を説明しています。RTPペイロード形式により、各RTPパケットペイロードの1つ以上のネットワーク抽象化レイヤー（NAL）ユニットのパケット化、および複数のRTPパケットでのNALユニットの断片化が可能になります。さらに、単一および複数のRTPセッションにおけるSVCストリームの送信をサポートします。ペイロード形式は、新しいメディアサブタイプ名「H264-SVC」を定義しますが、独自のRTPストリームにカプセル化されている場合は、h.264メディアサブタイプ名（ "H264"）を使用する必要があるため、RFC 6184と後方互換性があります。また、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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は、修正3からISO/IEC 14496パート10 [ISO/IEC14496-10]で指定され、ITU-T Recの付属書Gで同等に指定されています。H.264 [H.264]。このメモでは、明示的に特に述べられていない限り、「H.264/AVC」とは、付録Gを除く[H.264]の仕様を指します。
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に追加するスケーラビリティ機能により、システムの能力に関連するいくつかのシステムレベルの機能が、処理なしまたは最小限のシステム条件に信号を異なるシステム条件に適応させることができます。適応は、潜在的に不均一な受信機の機能（画面解像度、処理速度などが異なる）の機能と、異なるまたは時変のネットワーク条件の両方に関連しています。適応は、ソース、目的地、または中間メディア認識ネットワーク要素（MANES）で実行できます。このメモで指定されたペイロード形式は、これらのシステムレベルの機能を公開し、システム設計者がこれらの機能を直接活用できるようにします。
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ストリームには、設計上、H.264/AVCに準拠したサブストリームが含まれているため、すべてのSVC固有の情報が削除されるように、たてがみがストリームをフィルタリングすることは些細なことです。実際、このメモは、RTPパケットを排除し、RTPコントロールプロトコル（RTCPの書き換えによってストリームを[RFC6184]に準拠させることができるかどうか）を示すメディアタイプパラメーター（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では、SVCビットストリームを含むすべてのスケーラビリティレイヤーの送信に単一のRTPセッションが使用されます。MSTでは、スケーラビリティレイヤーはさまざまなRTPセッションで輸送されます。SSTでは、パケット化は[RFC6184]の簡単な拡張です。MSTの場合、このメモで4つの異なるモードが定義されています。それらは、インターリーブを許可するかどうか、つまりネットワーク抽象化層（NAL）ユニットをデコード順とは異なる順序で送信するか、およびセッション間NALユニットデコード順序の回復を実施するために使用される手法によって異なります。デコード順序回復は、セッション間タイムスタンプアライメント[RFC3550]またはクロスセッションデコード順序番号（CS-Dons）を使用して実行されます。MSTモードの1つは、注文回収手法の両方を解読するため、受信機が好みのテクニックを選択できるようにすることができます。詳細については、セクション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ユニットタイプをさらに定義します。最初のタイプは、ペイロードコンテンツスケーラビリティ情報（PACSI）NALユニットです。これは、RTPパケットに含まれるデータのスケーラビリティ情報と補助データ（CS-Don値など）の有益な要約を提供するために使用されます。2番目と3番目の新しい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））、および時間（秒あたりの写真）です。特定のレベルの空間的、品質、および時間的忠実度に関連付けられたビットストリームコンポーネントは、BitStreamの対応するパラメーターを使用して識別されます：依存関係_ID、quality_id、およびthipal_id（セクション1.1.3も参照）。忠実度の識別子には整数値があり、より高い値が階層でより高いコンポーネントを指定します。SVCは、エンコーダーがさまざまなコンポーネント間の依存関係を構成する方法を選択する方法に関して、大きな柔軟性を提供することに注意してください。特定のコンポーネントのデコードには、直接または間接的に依存するすべてのコンポーネントの可用性が必要です。SVCビットストリームの動作点は、特定の依存関係_ID、quality_id、およびthipal_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ベースレイヤー」などのBitStreamスケーラビリティのコンテキストで使用される場合、特定の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に対応する時刻インスタンスで依存関係_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].
[H.264]の付録Aで定義されているプロファイルがすでにサポートしているため、時間的スケーラビリティの概念はすでにH.264/AVCに存在していることに注意してください。具体的には、H.264/AVCでは、サブシーケンスの概念が導入されており、補足強化情報（SEI）メッセージを通じて時間層をオプションの使用できるようにしています。SVCは、時間のパラメーターを使用して時間的スケーラビリティ情報を、それぞれ空間的および品質スケーラビリティに使用する依存関係とquality_id値と一緒に（および統合された）、時間的スケーラビリティ情報をそれぞれ公開することにより、このアプローチを拡張します。[H.264]の付録Gで定義されたコード化された画像データの場合、これは新しいタイプのNALユニット、つまりスケーラブル拡張NALユニット（タイプ20）のコード化されたスライスを使用して達成されます。。H.264/AVCに続くコード化された画像データ、および既存のH.264/AVCデコーダーとの互換性を確保するために、別の新しいタイプのNALユニット、つまりプレフィックスNALユニット（タイプ14）は、このヘッダー情報を携帯するために定義されています。SVCは、3番目の新しいタイプのNALユニット、つまりサブセットシーケンスパラメーターセットNALユニット（タイプ15）を指定し、品質および空間強化層のシーケンスパラメーターセット情報を含むように指定します。これら3つの新しく指定されたNALユニットタイプ（14、15、および20）はすべて、H.264/AVCに予約されているものの1つであり、[H.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内では、特定の依存関係_IDおよびquality_IDに関連付けられたVCL NALユニットは、「レイヤー表現」と呼ばれます。依存関係_IDおよびquality_idの最低値に対応するレイヤー表現（つまり、両方の場合はゼロ）は、H.264/AVCに設計することで準拠しています。VCLのセットと、依存関係_IDとquality_idの値の特定の組み合わせに関連付けられたビットストリーム内のすべてのAUSにおける関連する非VCL NALユニットのセット、およびTomeal_IDの値に関係なく、概念的にはスケーラブルなレイヤーです。ただし、H.264/AVCとの逆方向の互換性については、SVC固有のNALユニットが特定のビットストリームに存在するかどうかを区別することが重要です。これは、対応するVCLデータはH.264/AVCに準拠しており、関連するプレフィックスNALユニットを伴う場合がある場合と伴う場合があるため、依存関係_IDとquality_id（両方の場合はゼロ）の観点から最も低い忠実度の値にとって特に重要です。したがって、このメモは、「AVCベースレイヤー」という用語を使用して、SVC固有のNALユニットを含まないレイヤーを指定し、「SVCベースレイヤー」を使用して同じレイヤーを指定しますが、関連するSVCプレフィックスNALユニットを追加します。SVC仕様は、このメモの内容が「AVCベースレイヤー」と呼ばれるものについて「ベースレイヤー」という用語を使用していることに注意してください。同様に、レイヤー内で、それに含まれる時間的忠実度成分を区別できることも重要です。このメモでは、「T0」という用語を使用して、特定のレイヤー内で、0に等しいTOMELAL_IDに関連付けられたNALユニットを含むサブセットを示します。
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 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.
SVCは、H.264/AVCのパラメーターセットの概念を維持し、サブセットシーケンスパラメーターセット[H.264]と呼ばれる新しいタイプのシーケンスパラメーターセットを導入します。サブセットシーケンスパラメーターセットのNALユニットタイプは15に等しく、これはシーケンスパラメーターセットのNAL単位タイプ値（7）とは異なります。NALユニットタイプ1〜5のVCL NALユニットは、（間接的に）シーケンスパラメーターセットを参照する必要がありますが、NALユニットタイプ20のVCL NALユニットは（間接的に）サブセットシーケンスパラメーターセットを参照する必要があります。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を依存関係_ID * 16 quality_idに等しくします。デコードプロセス中はいつでも、DQIDの最高値を持つレイヤー表現に1つのアクティブシーケンスパラメーターセットと、DQIDの値が低いレイヤー表現の1つ以上のアクティブレイヤーSVCシーケンスパラメーターセットがあります。アクティブシーケンスパラメーターセットまたはアクティブレイヤーSVCシーケンスパラメーターセットは、アクティブシーケンスパラメーターセットまたはアクティブレイヤーSVCシーケンスパラメーターセットが参照されるスケーラブルレイヤーのコード化されたビデオシーケンス全体で変更されません。これは、参照されたシーケンスパラメーターセットまたはサブセットシーケンスパラメーターセットが、任意のレイヤーの瞬時デコードリフレッシュ（IDR）アクセスユニットでのみ変更できることを意味します。デコードプロセス中はいつでも、1つのアクティブな画像パラメーターセット（DQIDの最高値を持つレイヤー表現の場合）と1つ以上のアクティブレイヤー画像パラメーターセット（DQIDの値が低いレイヤー表現の場合）があります。。アクティブな画像パラメーターセットまたはアクティブレイヤー画像パラメーターセットは、アクティブな画像パラメーターセットまたはアクティブレイヤー画像パラメーターセットが参照されるレイヤー表現全体で変更されませんが、1つのAUから次の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は、1バイトのH.264/AVC NALユニットヘッダーをタイプ14および20のNALユニットの3つの追加オクテットで拡張します。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ユニットヘッダーの構文とセマンティクスは[H.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.
[H.264]で指定されているNALユニットタイプのコンポーネントのセマンティクスは、以下で簡単に説明します。各フィールドの名前とサイズに加えて、[H.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。このコンポーネントは、[h.264]の表7-1で定義されているNALユニットタイプを指定し、後にこのメモ内で指定します。現在定義されているすべてのNALユニットタイプとそのセマンティクスの参照については、[H.264]のセクション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.
H.264/AVCでは、NALユニットタイプ14、15、および20が将来の拡張のために予約されています。SVCは次のようにこれらの3つのNALユニットタイプを使用します。NALユニットタイプ14はプレフィックスNALユニットに使用され、NALユニットタイプ15はサブセットシーケンスパラメーターセットに使用され、NALユニットタイプ20はスケーラブル拡張のコード化されたスライスに使用されます（セクション7.4を参照してください。.1 [H.264]）。NALユニットタイプ14および20は、以下に示すように、NALユニットヘッダーに3つの追加オクテットの存在を示しています。
+---------------+---------------+---------------+
|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は1に等しくなければなりません。rの値はデコーダーによって無視する必要があります。
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ビット優先順位_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。このフラグは、コード化されたスライスNALユニットに存在する場合、コード化されたスライス（1に等しい場合）のデコード（0に等しい場合）のデコードに層間予測を使用できるかどうかを指定します。
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ビット依存関係_ID。このコンポーネントは、レイヤー表現の層間コーディング依存性レベルを示します。任意のアクセスユニットでは、指定された依存関係_IDを持つレイヤー表現を使用して、より高い依存関係_IDでレイヤー表現をコーディングするためにレイヤー間予測に使用できますが、特定の依存関係_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層表現の品質レベルを示します。任意のアクセスユニットで、同一の依存関係_ID値の場合、QLに等しいqualth_idを持つレイヤー表現は、QL-1に等しいqualth_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ビットTomeal_id。このコンポーネントは、層表現の時間レベルを示します。Tomeal_idはフレームレートに関連付けられており、_temporal_idの値が低いフレームレートに対応しています。特定のThemporal_IDでのレイヤー表現は、通常、Thipalal_ID値が低いレイヤー表現に依存しますが、より高いThePomal_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ユニットの値が高いNALユニットをデコードするために使用されないことを示しています。このようなNALユニットは、より高い依存関係_ID値でレイヤーの整合性を危険にさらすことなく破棄できます。0に等しいDisdardable_Flagは、より高い依存関係_IDでレイヤーの整合性を維持するためにNALユニットのデコードが必要であることを示します。
O: 1 bit output_flag: Affects the decoded picture output process as defined in Annex C of [H.264].
O：1ビットoutput_flag：[H.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ビットRESERVERT_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で説明されているように、[H.264]の概念Gごとに、F、NRI、I、PRID、DID、QID、TID、U、およびDのセマンティクスを拡張します。
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]と同様に、このペイロード形式は、[H.264]の付録Bで指定されたバイテストリーム形式ではなく、RTPを介して生の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.
o 可能な限り[RFC6184]との後方互換性。
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.
o SVCベース層またはSVCベース層の任意のH.264/AVC互換サブセットは、[RFC6184]を使用してカプセル化する必要があります。これにより、このようなRTPストリームが[RFC6184]レシーバーによって理解されることが保証されます。
o Media-aware network elements (MANEs) as defined in [RFC6184] are signaling-aware, rely on signaling information, and have state.
o [RFC6184]で定義されているメディア認識ネットワーク要素（MANES）は、シグナルを認識し、シグナル情報に依存し、状態を持っています。
o MANEs can aggregate multiple RTP streams, possibly from multiple RTP sessions.
o Manesは、おそらく複数の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].
o たてがみは、メディアを認識したストリームの薄化を実行できます（パケットまたはその部分の選択的除去）。RTPセッション内のレイヤーを識別するペイロードヘッダー情報を使用することにより、Manesは、着信RTPパケットストリームからパケットまたはその部分を削除できます。これは、[RFC3550]のセクション7で指定されているように、発信パケットストリームのRTPヘッダーを書き換え、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の場合、このメモで定義されたMST固有のパケット化モードに従って、[RFC6184]で定義されたパケット化モードに基づいて、2つ以上のRTPセッションがSVCデータを運ぶために使用されます。MSTでは、各RTPセッションは1つのRTPストリームに関連付けられており、1つ以上のレイヤーを搭載する場合があります。
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に互換性があります。送信中、SVCによって導入され、存在する場合、H.264/AVCデコーダーによって無視される関連プレフィックスNALユニットは、H.264/AVC VCL NALユニットと同じRTPパケットストリーム内または別のRTPパケットストリーム（MSTが使用されている場合）。便利なため、「AVCベースレイヤー」という用語は、接頭辞NAL単位のないベースレイヤーを参照するために使用されますが、「SVCベースレイヤー」という用語は、接頭辞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: 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.
このメモにより、特定のRTPストリームにカプセル化することができます。次の3つの層の組み合わせの代替品のいずれかを組み合わせます。1。T0 AVCベースレイヤーまたはT0 SVCベースレイヤーのみ。2. 1つ以上の拡張層のみ。または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]レシーバーとの互換性を確保します。ただし、1つ以上のSVC品質または空間強化層がSSTを使用して送信される場合、このメモで定義されているパケット化を使用する必要があります。SSTでは、3つの[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ビットストリームの動作点は、[H.264]の付録AまたはGで定義されたプロファイルの1つに合わせて、デコードされた場合、特定の忠実度のオリジナルビデオ。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- CS-を定義します。DONモード（NI-TC）、およびインターリーブCS-DON（I-C）ベースのモード（セクション4.5.2で詳細）。モードは、SVCデータをインターリーブすることが許可されているかどうか、つまり、意図したデコード順とは異なる順序で送信できるかどうかによって異なります。また、NAL単位の正しいデコード順序を回復するために提供されるメカニズムも異なります。複数のRTPセッション全体。これらの4つの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パケット化モードの名前が示すように、Ni-T、Ni-C、およびNi-TCモードはインターリーブされる伝送を許可しませんが、I-Cモードはインターリーブ送信を可能にします。3つの非介入されていないMSTパケット化モードのいずれかで、[RFC6184]で指定された非介入モードの実装を備えたレガシー[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]は、3つの基本ペイロード構造、つまり、単一NALユニットパケット、集約パケット、およびフラグメンテーションユニットを指定します。基本的なペイロード構造に応じて、RTPパケットには、他のNALユニットを集約しないNALユニット、別のNALユニットに集約された1つまたは複数のNALユニット、または他のNALユニットを集約しないNALユニットのフラグメントが含まれている場合があります。[H.264]（つまり、1〜23、包括的）で指定されたタイプの各NALユニットは、単一のNALユニットパケットで完全に運ばれるか、集約パケットに集約されるか、断片化されて運ばれる場合があります。多数の断片化ユニットパケット。NALユニットの集約または断片化を有効にしながら、RTPパケットペイロードがNALユニットのみで構成されていることを保証するために、[RFC6184]は、NALユニットタイプから選択されたペイロード構造として使用される6つの新しいNALユニットタイプ（24-29）を導入しました。[h.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]で使用されるすべてのペイロード構造を再利用します。さらに、3つの新しいタイプのNALユニットが定義されています。ペイロードコンテンツスケーラビリティ情報（PACSI）NALユニット、空のNALユニット、および非インターレッドマルチタイムアグリゲーションパケット（NI-MTAP）（セクション4.9、4.10、および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 マネーが、ビデオで定義される集約された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 NI-CまたはNi-TCモードを使用して、MSTでの正しいデコード順序回復を有効にし、Pacsi Nalユニットに含まれるCS-Don情報の助けを借ります。
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.
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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（on）の値を割り当てるのと同じです。少しクリアすることは、その値を0（オフ）に割り当てることと同じです。
This document uses the terms and definitions of [H.264]. Section 3.1.1 lists relevant definitions copied from [H.264] for convenience.
このドキュメントでは、[H.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つ以上の冗長コード化された写真、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].
ベースレイヤー：NAL_UNIT_TYPE構文要素を含むすべてのNALユニットをBitStreamの1または5に含むビットストリームサブセットは、14、15、または20に等しいNAL_UNIT_TYPE構文要素を持つNALユニットを含まず、[H.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.
ベース品質レイヤー表現：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ユニットによって提供される依存関係_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またはEIスライスであるコード化された画像は、IDR画像をデコードした直後にすべての参照画像を「参照のために使用していない」とデコードプロセスをマークするIまたはEIスライスです。IDR画像のデコード後、DECODING順序でコーディングされたすべてのコード化された写真は、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ユニットによって提供される依存関係_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_UNIT_TYPEが14に等しいNALユニットは、NAL_UNIT_TYPEが1、5、または12に等しいNALユニットをデコードする直前の14に等しくなります。関連する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.
参照ベース画像：NAL_REF_IDC構文要素を使用してベース品質レイヤー表現をデコードすることにより取得される参照画像。基本品質層表現の層間予測による。参照ベース画像は、デコードプロセスの出力ではありませんが、参照ベース画像のサンプルは、デコード順で後続の写真のデコードプロセスでインター予測に使用できます。参照ベース画像は、参照ベースフィールドまたは参照ベースフレームの集合用語です。
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仕様[H.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.
ターゲット依存性表現：アクセスユニットのすべての依存関係表現の依存関係_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.
アンカーレイヤー表現：アンカー層表現は、レイヤー表現であるため、レイヤーに対応する動作点のデコードがこのレイヤー表現を含むアクセスユニットから始まる場合、出力順にレイヤーの次のレイヤー表現はすべて、正しくデコードされています。出力順序は、[h.264]で定義されています。デコードされた画像がデコーダーのデコードされた画像バッファーから出力される順序として定義されています。H.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ベースレイヤーのサブセット。これは、[H.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セッション。このRTPセッションは、セクション7.2.3で定義されているメカニズムで示されているように、他の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の値は0に包みます。この定義は、まったく同じ形式で[RFC6184]にも存在することに注意してください。
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ユニット：NALユニットタイプが31に等しく、サブタイプのサブタイプのNALユニットが1に等しい。空の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で定義されたメカニズムで示されるように、少なくとも1つの他のRTPセッションに依存するRTPストリームが含まれています。Enhancement 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.
デフォルトのサブプロファイル：1つのプロファイルのすべてのコーディングツールまたは複数のプロファイルのコーディングツールの共通サブセットであるコーディングツールのサブセット。プロファイルレベル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].
拡張レイヤー：依存関係_IDまたはquality_idの値の少なくとも1つが0よりも高いレイヤー、またはNALユニットのいずれも0に関連付けられていないレイヤーが0に等しい。拡張層に関連付けられたThipal_id、依存関係_ID、およびquality_id値[H.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互換性：[H.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ユニットが、NALユニットヘッダー（タイプ14または20のNAL単位）を介して直接依存関係_IDとQuality_IDの値が同じか、または介して同じ値を持っているビットストリームサブセットプレフィックスとの関連（タイプ14）NALユニット（NALユニットタイプ1、5、または12の場合）。レイヤーには、TOMELAL_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.
Media-Aware Network Element（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].
有益なメモ：たてがみの概念は、通常のルーターまたはゲートウェイを超えています。たとえば、メディアストリームのペイロードタイプのマッピングについて学ぶためには、たとえば、たとえば、たとえば、たとえば、それが信頼する必要があるということです。安全なリアルタイムトランスポートプロトコル（SRTP）を使用します。たてがみを使用する利点は、メディアコーディングのニーズに応じてパケットをドロップできることです。たとえば、特定のリンクの輻輳のためにたてがみがパケットをドロップする必要がある場合、排除がユーザーエクスペリエンスに最も悪影響をもたらすパケットを識別および削除できます。パケットをドロップした後、MANESはRTCPパケットを書き換えて、[RFC3550]のセクション7で指定されているRTPパケットストリームの変更を一致させる必要があります。
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.
マルチセッション送信：複数のRTPセッションでSVCストリームが送信される伝送モード。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ユニットデコード順序：[H.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-TIME：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.
操作点：操作点は、Thipalal_id、Dependency_id、およびquality_idの値のセットによって識別されます。操作ポイントに対応するビットストリームは、依存関係_IDのより高い値に関連付けられたすべてのNAL単位を削除し、依存関係_IDの同じ値に関連するすべてのNAL単位をQuality_IDまたはTOMEAL_IDの値に関連付けて構築できます。操作ポイントビットストリームは、[H.264]の付録AまたはGで定義されているプロファイルの少なくとも1つに準拠し、特定の忠実度で元のビデオ信号の表現を提供します。
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ユニットを削除することができます（低い依存関係または同じ依存関係_IDでは）。ただし、結果のビットストリームは、[H.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パケットストリーム：シーケンス番号が増加する（ラップアラウンドを除く）、同一のペイロードタイプ、同一のSSRC（同期ソース）を備えたRTPパケットのシーケンス、1つのRTPセッションで運ばれます。このメモの範囲内で、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ベースレイヤー：依存関係_IDに関連付けられたすべてのNAL単位とquality_id値を含むレイヤーは、両方とも0に等しい（NAL単位タイプ14）を含む。
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エンハンスメントレイヤー：依存関係_IDまたはquality_IDの値の少なくとも1つが0を超えるレイヤー。[H.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ユニット：[H.264]の付録Gで指定されているように、NALユニット14、15、または20のNAL単位。
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ユニットヘッダー：NALユニットタイプ14および20に追加された3バイトSVC固有のヘッダー拡張の追加に起因する4バイトヘッダー。
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ベースレイヤー：0を超えるTomeal_id値に関連付けられたすべてのVCl NAL単位を削除することにより構築されたAVCベースレイヤーのサブセットと、削除されるVCL NALユニットのみに関連する非VCL NAL単位およびSEIメッセージ。
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ベースレイヤー：0を超えるTomeal_id値に関連付けられたすべてのVCl NALユニットを除去することにより構築されたSVCベースレイヤーのサブセット、およびプレフィックスNALユニット、非VCL NAL単位、およびVCL NALユニットのみに関連するSEIメッセージは削除。
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：クロスセッションデコード順序番号MGスケーラブルなビデオコーディング
In addition to Section 5.1 of [RFC6184], the following rules apply.
[RFC6184]のセクション5.1に加えて、次のルールが適用されます。
o Setting of the M bit:
o 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.
パケットペイロードがNI-MTAPであるRTPパケットのMビットは、RTPタイムスタンプに関連付けられたアクセスユニットの最後のNALユニットがパケットに含まれている場合、1に等しくなければなりません。
o Setting of the RTP timestamp:
o RTPタイムスタンプの設定：
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.
パケットペイロードがパクシン単位であるRTPパケットの場合、RTPタイムスタンプは、送信順に次の非Pacsi NalユニットのNALU時間と等しくなければなりません。MTAP内のNALユニットのNALU時間は、[RFC6184]で定義されていることを思い出してください。そのNALユニットが独自のRTPパケットで輸送される場合、RTPタイムスタンプが持つ値があることを思い出してください。
o Setting of the SSRC:
o SSRCの設定：
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.
このメモは、[RFC6184]（つまり、0、30、および31）で未定義の3つのNALユニットタイプを超えて、新しいタイプのNALユニットを導入できるように、NALユニット拡張メカニズムを指定します。拡張メカニズムは、NALユニットタイプ値31を利用し、次のように指定されています。NALユニットタイプの値が31に等しい場合、セクション1.1.3で指定されているF、NRI、およびタイプフィールドで構成される1バイトNALユニットヘッダーは、5ビットフィールドで構成される1つの追加のオクテットによって拡張されます。それぞれj、k、およびlという名前のサブタイプと3つの1ビットフィールドと名付けられました。追加のオクテットを次の図に示します。
+---------------+
|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に等しい場合、NALユニットはセクション4.7.1で指定されている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仕様[H.264]によるNALユニットヘッダーの構造とセマンティクスは、セクション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の値は、NALユニットタイプのオクテットとペイロードにビットエラーやその他の構文違反を含めてはならないことを示しますが、Fの値はNALユニットタイプのオクテットとペイロードにビットエラーまたはその他が含まれていることを示します。構文違反。MANESは、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の場合、[h.264]の付録Aで定義され、[RFC6184]を使用して輸送されたプロファイルの1つに準拠しているビットストリームの場合、[RFC6184]のセクション5.3で指定されたセマンティクスは、つまり、NRIも適用されます。nalユニット。[H.264]の付属書Gで定義され、[H.264]の付属書Gで指定されたセマンティクスに加えて、このメモを使用して輸送されたプロファイルの1つに準拠したビットストリームの場合、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.
Iの場合、[H.264]の付属書Gで指定されたセマンティクスに加えて、このメモによれば、Manesはこの情報を使用して、Iを使用してIを使用してIを1に等しく保護することができます。また、NALユニットの情報を1等で使用して、RTPパケットストリームのパケットをより多く転送するタイミングを決定します。たとえば、空間層の切り替えが発生していることが検出された場合、動作点がDIDのより高い値に変更されたため、MANESは、Iに等しいIでNALユニットを転送した後にのみDIDの高い値でNALユニットを転送し始める可能性があります。1の値が高い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ユニットの保護」とは、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の場合、[H.264]の付録Gで指定されたセマンティクスが適用されます。不均等なエラー保護を実装するManesは、この情報を使用して、PRID値が大きいものよりも優れたPRID値のNALユニットを保護するために、たとえばFEC保護メカニズムにより重要な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.
[H.264]の付録Gで指定されたセマンティクスに加えて、DID、QID、またはTIDは、このメモによれば、DIDの値、QID、またはTIDはそれぞれの次元の相対的な重要性を示しています。他の2つのコンポーネントが同一である場合、DID、QID、またはTIDの値が低いことを示します。Manesは、この情報を使用して、より重要な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の場合、[H.264]の付録Gで指定されたセマンティクスに加えて、このメモによれば、Manesはこの情報を使用してUを使用してUを使用して、Uを0に等しいNALユニットよりも1に等しく保護することができます。
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の場合、[H.264]の付属書Gで指定されたセマンティクスに加えて、このメモによれば、MANESはこの情報を使用して、SVCビットストリームの特定の動作点を正常にデコードするために特定のNALユニットが必要かどうかを判断することができます。したがって、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パケットペイロードは、H.264/AVCで指定された1つのNALユニットの1つまたは一部を含む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]は、3つの基本的なペイロード構造（[RFC6184のセクション5.2]）を指定しています。単一NALユニットパケット、集約パケット、断片化ユニット、およびNALユニットの6つの新しいタイプ（24〜29）。RTPパケットペイロードヘッダーのタイプフィールドの値（つまり、ペイロードの最初のバイト）は、単一の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.
元々H.264/AVCに対して定義されたNALユニットタイプに加えて、SVCはSVC専用の3つの新しいNALユニットタイプを定義します：スケーラブル拡張NALユニット（タイプ20）、プレフィックスNALユニット（タイプ14）、およびサブセットシーケンスのコード化されたスライスセクション1.1で説明されているように、パラメーター設定NAL単位（タイプ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で指定されている3つの新しいタイプのNALユニット、Pacsi nalユニット（NALユニットタイプ30）、セクション4.10で指定されている空のNALユニット（タイプ31、サブタイプ1）、およびNI-MTAP NALユニット（タイプ）（タイプ）（タイプ31、サブタイプ1）をさらに紹介します。31、サブタイプ2）セクション4.7.1で指定されているとおり。
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で指定された1つのNALユニットの1つまたは一部を含むNALユニットとしてまだ構造化されているか、1つのPACSI NALユニットまたは1つの空のNALユニット、またはゼロ以上のNALを凝集させます。H.264/AVCおよびSVC、Zeroまたは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).
このメモでは、3つの基本ペイロード構造の1つであるフラグメンテーションユニットは[RFC6184]と同じままであり、他の2つの単一NALユニットパケットと集約パケットは次のように拡張されています。ペイロードヘッダーのタイプフィールドの値は、単一のNALユニットパケットの場合、1〜23の任意の値、包括的、30〜31、包括的、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
表1. SVCで導入された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
表2.すべてのNALユニットタイプの基本ペイロード構造タイプがRTPパケットペイロードとして直接使用される場合
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)
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).
このメモにより、1つ以上のRTPセッションでSVCビットストリームを送信できます。SVCビットストリームの送信に1つのRTPセッションのみが使用される場合、送信モードはシングルセッション送信（SST）と呼ばれます。それ以外の場合は（SVCビットストリームの送信に複数のRTPセッションが使用されます）、伝送モードはマルチセッション送信（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.
SSTはポイントツーポイントユニキャストシナリオに使用する必要がありますが、MSTは、異なる受信機が同じSVCビットストリームの異なる動作ポイントを必要とするポイントツーマルチポイントマルチキャストシナリオに使用して、効率を利用する帯域幅を改善する必要があります。
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.
オプションのMSTモードメディアタイプパラメーター（セクション7.1を参照）が存在しない場合、SSTを使用する必要があります。それ以外の場合は（MST-Modeが存在します）、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]のセクション5.4で指定されたパケット化モード、すなわち、単一NALユニットモード、非インテリアモード、およびインターリーブモードは、セッションパケット化モードとも呼ばれます。表4は、SSTの許可されたセッションパケット化モードをまとめたものです。
Table 4. Summary of allowed session packetization modes (denoted as "Session Mode" for simplicity) for SST (yes = allowed, no = disallowed)
表4. SSTの許可されたセッションパケット化モード（単純さのための「セッションモード」として表される）の概要（はい=許可、いいえ=許可）
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.
0〜29の範囲のNALユニットタイプの場合、各セッションパケット化モードのパケットペイロードとして直接使用できるNALユニットタイプは、[RFC6184]のセクション5.4で指定されたものと同じです。このメモで新たに導入された他の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)
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モードはタイムスタンプを使用してNALユニットのデコード順序を回復しますが、NI-CモードとI-CモードはどちらもCS-Donメカニズム（後述）を使用してそうするために使用します。Ni-TCモードは、タイムスタンプとCS-Donメソッドの両方を提供します。この場合の受信機は、次の順序リカバリをデコードするためにいずれかの方法を使用することを選択できます。使用中のMSTパケット化モードは、オプションのMSTモードメディアタイプパラメーターの値によって信号を送信する必要があります。使用されたMSTパケット化モードは、関連する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)
表6. NI-T、NI-C、およびNI-TC（はい=許可、no =非許可）の許可されたセッションパケット化モード（単純さのための「セッションモード」として表される）の概要
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)
表7. I-Cの許可されたセッションパケット化モード（単純さのための「セッションモード」として表される）の概要（はい=許可、いいえ=許可）
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.
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)
表8. NI -Tが使用されているときに許可されたセッションパケット化モードごとにパケットペイロードとして直接使用できる新しいNALユニットタイプ（YES =許可、no = ollowed、 - =適用されない/指定されていない/指定されていない）
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)
表9. NI -Cが使用されているときに許可されたセッションパケット化モードごとにパケットペイロードとして直接使用できる新しいNALユニットタイプ（YES =許可、no = ollowed、 - =適用されない/指定されていない）
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)
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)
表11. I -Cが使用されているときに許可されたセッションパケット化モードのパケットペイロードとして直接使用できる新しいNALユニットタイプ（はい=許可、no = ollowed、 - =適用されない/指定されていない）
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パケットは1つ以上の空の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パケット化モードがI-Cの場合、空のNAL単位（タイプ31、サブタイプ1）とNi-MTAP NALユニット（タイプ31、サブタイプ2）の両方を使用してはなりません。つまり、RTPパケットはありません。1つ以上の空の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ユニットパケットのペイロードは、1〜23の任意の値に等しいNALユニットタイプを持つNALユニットのNALユニットに加えて、PACSI NALユニット（タイプ30）または空のNALユニット（タイプ31およびサブタイプ1）である場合があります。包括的。
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.
このメモで導入された新しいNALユニットタイプの1つは、非インターレアブマルチタイムアグリゲーションパケット（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ビットの署名されていないサイズ情報と、タイムスタンプオフセット（TSオフセット）の16ビット（ネットワークバイト順）で構成されています。NALユニット用。構造を図1に示します。パケット内の集約ユニットの開始位置または終了位置は、32ビットワード境界にある場合とそうでない場合があります。NI-MTAPのNALユニットは、NALユニットデコード順序で注文されます。
The Type field of the NI-MTAP MUST be set equal to "31".
Ni-MTAPのタイプフィールドは、「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ビットを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フィールドは0に等しくなければなりません。MSTの場合、Ni-Tモードではjフィールドは0に等しくなければなりませんが、Ni-CまたはNi-TCモードではJフィールドは1に等しくなければなりません。Ni-CまたはNi-TCモードが使用されている場合、DONフィールドは、存在する場合、セクション6.2.2で定義されている特定の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
図1. NI-MTAP用の非介入マルチタイム凝集ユニット
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時間は、[RFC6184]で定義されていることを思い出してください。そのNALユニットが独自のRTPパケットで輸送される場合、RTPタイムスタンプが持つ値があることを思い出してください。タイムスタンプオフセットフィールドは、次の式の値に等しい値に設定する必要があります。
if NALU-time >= TS, TS offset = NALU-time - TS
else, TS offset = NALU-time + (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ビット以上のタイムスタンプであり、タイムスタンプフィールドのラップアラウンドをカウントできるため、タイムスタンプがラップされた場合に最小値を決定できるようになります。このような「初期の」集約ユニットは、集約単位が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とラベル付けされた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
図2. 2つの非介入されていないマルチタイムアグリゲーションユニットを含むNI-MTAPを含む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.
このメモで指定されているもう1つの新しいタイプのNALユニットは、ペイロードコンテンツスケーラビリティ情報（PACSI）NALユニットです。Pacsi nalユニットのタイプフィールドは30に等しくなければなりません（[H.264]および[RFC6184]で不特定のままであるNAL単位タイプの値）。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 マネーが、ビデオで定義される集約された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 NI-CまたはNi-TCモードを使用して、MSTでの正しいデコード順序回復を有効にし、Pacsi Nalユニットに含まれるCS-Don情報の助けを借ります。と
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.
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.
o RTPヘッダーフィールドと集約パケットのペイロードヘッダーフィールドは、Pacsi Nalユニットが集約パケットに含まれていないかのように設定されています。
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.
o 集約パケットがMTAP16、MTAP24、またはjフィールドを持つjフィールドを1に等しいNi-MTAPである場合、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ユニットヘッダーとまったく同じです。その後、いくつかのフラグを含む1つのオクテット、次に5つのオプションのオクテット、そして最終的にゼロ以上のseinalユニットが続きます。各SEINALユニットの前には、次のNALユニットのサイズをバイト単位で示す16ビットの非署名サイズフィールド（ネットワークバイト順）があります（これら2オクテットを除くが、sei nalユニットのNALユニットヘッダーオクテットを含む）。図3は、2つのSeinalユニットを含むPacsi 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に等しい場合にのみ指定されます。BITSSとEが指定され、フィールドTL0PICIDXとIDRPICIDが存在します。ビットTが1に等しい場合にのみ存在します。PACSIナルユニットがSTAP-B、MTAP16、MTAP24、またはni-MTAPに1に等しいNi-MTAPに含まれている場合、フィールドTは0に等しくなければなりません。
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.
o 集約パケットの残りのNALユニットの少なくとも1つのFビットが1に等しい場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次の非Pacsi nalが1に等しい場合、Fビットを1に設定する必要があります。伝送順にユニットのfビットは1に等しい（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).
o NRIフィールドは、集約パケット内の残りのすべてのNALユニットの中でNRIフィールドの最高値に設定する必要があります（PACSI NALユニットが集約パケットに含まれている場合）または次の非PACSI NALのNRIフィールドの値の値伝送順にユニット（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ビットは1に設定する必要があります。受信機はRの値を無視する必要があります。
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.
o 集約パケット内の残りのNALユニットの少なくとも1つのビットが1に等しい場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次のiが次のビットの場合は1に設定する必要があります。透過順に非パクシルナルユニットは1に等しくなります（Pacsi nalユニットが単一のNALユニットパケットに含まれている場合）。それ以外の場合、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フィールドは、集約パケット内の残りのNALユニットのPRID値の最低値に設定する必要があります（Pacsi Nalユニットが集約パケットに含まれている場合）、または送信の次の非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.
o 集約パケット内の残りのすべてのNALユニットのnビットが1に等しい場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次の非Pacsiのnビットの場合、nビットを1に設定する必要があります伝送順にNALユニットは1に等しくなります（PACSI NALユニットが単一のNALユニットパケットに含まれている場合）。それ以外の場合、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).
o QIDフィールドは、残りのNALユニットのQID値の最低値に設定する必要があります。これは、集約パケット（Pacsi nalユニットが集約パケットに含まれている場合）または次の非qid値のdidの最低値（Pacsi nalユニットが含まれている場合）-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).
o TIDフィールドは、残りのNALユニットのTID値の最低値に設定する必要があります。これは、集約パケットで最も低い値（Pacsi nalユニットが集約パケットに含まれている場合）-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.
o アグリゲーションパケットの残りのNALユニットの少なくとも1つのUビットが1に等しい場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次のuが次のuビットの場合、uビットを1に設定する必要があります。透過順に非パクシルナルユニットは1に等しくなります（Pacsi nalユニットが単一のNALユニットパケットに含まれている場合）。それ以外の場合、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.
o 集約パケット内のすべてのNALユニットのすべてのd値が1に等しい場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次の非PACSIのDビットの場合、Dビットを1に設定する必要があります伝送順にNALユニットは1に等しくなります（PACSI NALユニットが単一のNALユニットパケットに含まれている場合）。それ以外の場合、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 集約パケット内の残りのNALユニットの少なくとも1つのoビットが1に等しい場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次のoビットの場合の場合、oビットを1に設定する必要があります。透過順に非パクシルナルユニットは1に等しくなります（Pacsi nalユニットが単一のNALユニットパケットに含まれている場合）。それ以外の場合、oビットを0に設定する必要があります。
o The RR field MUST be set to "11" (in binary form). Receivers MUST ignore the value of RR.
o RRフィールドは「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.
o xビットが1に等しい場合、ビット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.
o yビットが1に等しい場合、オプションのフィールド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.
o tビットが1に等しい場合、オプションのフィールド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.
o 集約パケット内の残りのNALユニットの少なくとも1つがアンカー層表現に属している場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次の非Pacsi nalユニットの場合に、1に設定する必要があります。トランスミッションオーダーは、アンカー層の表現に属します（Pacsi nalユニットが単一のNALユニットパケットに含まれている場合）。それ以外の場合は、少しを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.
有益なメモ：A a aは、非IDR層表現でCGSまたは空間層の切り替え（NAL_UNIT_TYPEを5に等しくなく、IDR_FLAGが1に等しくない）での層表現を実行できるかどうかを少し示します。一部の画像コーディング構造では、非IDR内部表現をランダムアクセスに使用できます。IDRレイヤー表現のみを使用する場合と比較して、より高いコーディング効率を達成できます。H.264/AVCまたはSVCソリューションは、非IDR層内表現のランダムアクセシビリティを示しています。回復ポイントSEIメッセージを使用しています。この情報は、この情報への直接アクセスを提供します。これは、sei nalユニットに深く埋められることがあるRecovery Point 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.
o 集約パケット内の残りのNALユニットがすべて0を超える場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次の非Pacsi nalユニットが送信順にreadundant_pic_cnt Greater Greater Greater Greaterを持っている場合、pビットを1に設定する必要があります。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.
o 集約パケット内の残りのNALユニットの少なくとも1つが層内表現に属している場合（Pacsi nalユニットが集約パケットに含まれている場合）、または次の非Pacsi nalユニットの場合にcビットを1に設定する必要があります。トランスミッションオーダーは、層内表現に属します（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.
o 集約パケットのPacsi nalユニットに続く最初のNALユニットが層表現の最初のVCl nalユニットである場合（デコード順）（Pacsi nalユニットが集約パケットに含まれている場合、sビットを1に設定する必要があります。）または、次の非PACSI NALユニットが、層表現のデコード順である最初のVCL NALユニットである場合（PACSI NALユニットが単一の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.
o eビットは、集約パケットのpacsi nalユニットに続く最後のnalユニットが層表現の最後のvcl nalユニットである場合、1に設定する必要があります（層表現のデコード順序）または、次の非pacsi nalユニットが送信順に、層表現のデコード順で最後のVCl nalユニットである場合（Pacsi nalユニットが単一の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ユニットヘッダーの依存関係、quality_id、およびthepalal_idの値の変化を検出することにより、レイヤー表現の開始または終了を常に検出することが常に可能です。。SまたはEビットは、単一NALユニットと集約パケットの両方にこの情報を提供するために使用されるため、以前またはフォローパケットを調べる必要はありません。これにより、Manesはスライス損失を検出し、できるだけ早く再送信を要求するなどの適切なアクションを実行したり、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).
o 存在する場合、TL0PICIDXフィールドは、凝集パケットのPACSIユニットに続く最初のNALユニットを含むレイヤー表現の[H.264]の付録Gで指定されたTL0_DEP_REP_IDXに等しく設定する必要があります（PACSI NALユニットが含まれる場合集約パケット）または次の非Pacsi Nalユニットを送信順に含む（Pacsi nalユニットが単一の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).
o 存在する場合、IDRPICIDフィールドは、集約パケットのパクシュナルユニットに続く最初のNALユニットを含む層表現の[H.264]の付属書Gで指定されているように、effection_idr_pic_idに等しく設定する必要があります（Pacsi nalユニットが含まれている場合集約パケット）または次の非Pacsi Nalユニットを送信順に含む（Pacsi nalユニットが単一の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フィールドは、受信機とたてがみによって最も重要な時間層（Thipalal_IDが0に等しい）で層表現の損失を検出することを可能にします。SVCは、SEIメッセージを使用するソリューションを提供します。SEIメッセージは、解析が難しく、ビットストリームに存在する場合と存在しない場合があります。Pacsi nalユニットがNI-MTAPパケットの一部である場合、これらのパラメーターが与えられたパラメーターの設定方法を指定するルールに従うことにより、NI-MTAPに含まれるすべてのレイヤー表現について、TL0_DEP_REP_IDXおよびIDR_PIC_IDの正しい値を推測することができます。[H.264]の付属書GおよびNALユニットヘッダーの依存関係_ID_、quality_id、およびthipal_idの値の変化を検出し、sおよびeフラグを使用することにより、Ni-MTAPパケットに含まれるさまざまなレイヤー表現を検出します。唯一の例外は、IDR画像のNALユニットがNi-MTAPに、Pacsi Nalユニットに続く最初のNALユニット以外の位置にある場合です。その場合、IDR_PIC_IDの値を推測できません。この場合、IDR_PIC_IDを取得するには、NALユニットを部分的に解析する必要があります。IDR写真のサイズが大きいため、Ni-MTAPに含まれること、特に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ユニットの最初の最初のNALユニット（Pacsi nalユニットが集約パケットに含まれている場合）またはCS-donのクロスセッションデコード順序番号（CS-DON）を示します。次の非Pacsi Nalユニットは、伝送順に（Pacsi Nalユニットが単一の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ユニットが属するアクセスユニットに関連付けられたSeinalユニットのサブセットを含めることができ、他のアクセスユニットに関連付けられているei 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では、各アクセスユニット内で、DECODING順序でVCL NALユニットの前にSEI NALユニットが表示される必要があります。したがって、Pacsi Nalユニットを使用せずに、SEIメッセージは通常、アクセスユニットを運ぶ最初のパケットでのみ伝達されます。送信者は、パクシュナルユニットの片線ユニットを繰り返す可能性があるため、複数のパケットで繰り返されるため、パケット損失に対する堅牢性が高まります。受信者は、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ユニットの1つにも含まれてはなりません。
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ユニットには、タイプ1の少なくとも1つのNALユニットが存在するアクセスユニットに関連付けられているRTPタイムスタンプ（単一のNALユニットパケットで輸送される場合）またはNALU時間（集約パケットで輸送される場合）が必要です。5、または20。MSTを使用すると、タイプ1、5、または20 NALユニットが別のRTPセッションにある場合があります。空のNALユニットは、セクション5.2.1で説明されているように、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に等しい必要がありますnriは3に等しい必要がありますタイプは31に等しくなければなりませんサブタイプは1に等しくなければなりませんjは0に等しくなければなりません0 kは0に等しいlは0に等しい必要があります
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]で導入されており、単一のセッション内でインターリーブが使用されている場合にデコード順序を回復するために使用されます。[RFC6184]のセクション5.5は、SSTを使用するときに適用されます。
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 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).
クロスセッションデコード順序番号（CS-DON）は、MSTに関与するすべてのRTPセッションにおけるNALユニットのデコード順序を示す数字です。[RFC6184]のDONコンセプトに似ていますが、[RFC6184]に反して、DONはインターリーブパケット化にのみ使用されました。このメモでは、インターリーブMSTモード（I-C）だけでなく、2つの2つでも使用されます。非介入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ユニットのSNSであり、それぞれ同じNALU時間を持つ以前のPACSI NALユニットです。
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.
o 非介入セッションパケット化モードを使用してセッションで運ばれる非PACSI NALユニットの場合、各非PACSIユニットのCS-DON値は次のように導出されます。
For a non-PACSI NAL unit in a single NAL unit packet, the following applies.
単一のNALユニットパケットの非PACSI NALユニットの場合、次のものが適用されます。
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-Aパケットに含まれています）、NALユニットのCS-DON値は上記のように計算され、DONC_PREV_PACSIは以前の非Pacsi nalユニットのCS-DON値に置き換えられます。デコード順序（つまり、STAP-Aパケットの最後のNALユニットのCS-DON値）。
For a non-PACSI NAL unit in an STAP-A packet, the following applies.
STAP-Aパケットの非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-Aパケットの最初の非PACSI NINALユニットである場合、NALユニットのCS-DON値は、STAP-Aパケットの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 nalユニットは、STAP-Aパケットの最初の非pacsi nalユニットではありません）、NALユニットのcs-don値は以前の非PacsiのCS-DON値に等しくなりますデコードのNALユニット1）％65536。
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値のSN値です。最初のfu-aパケット。
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.
すべての受信機は、単一のNALユニットパケット化モードをサポートして、[RFC6184]の単一NALユニットモードのみをサポートするエンドポイントへの後方互換性を提供する必要があります。ただし、単一のNALユニットパケット化モード（0に等しいパケット化モード）の使用は、可能な限り避ける必要があります。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 Recとの互換性のためにのみ[RFC6184]に含まれてきました。H.241付録A [H.241]。この歴史的なバラストを、SVCを提供するような新しいアプリケーションスペースに向けて運ぶ意味はありません。非介入モード（すなわち、STAP-AとFU-A）の追加メカニズムをサポートするための実装の複雑さの増加はマイナーですが、利点は重要です。その結果、STAP-AとFU-Aのサポートが必要です。さらに、セクション4.5.1で指定されているように、このメモで定義されている3つのNALユニットタイプのうち2つ、つまり空の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ユニットと一緒に集約パケットにカプセル化する必要があります。たとえば、アクセスユニットのデリミター、パラメーターセット、またはSEINALユニットなどの非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ユニットは、これがセッションに違反しない限り、関連する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ユニットのサイズが小さいことを考えると、関連するNALユニットと同じRTPパケットで輸送される場合が最適です。
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.
1つ以上の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で指定されたパケット化ルールが引き続き適用されます。さらに、セッションで指定された脱パケット化プロセスを使用して、各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モードにはこの制限がなく、CS-Don値を使用して、Pacsi nalユニットで直接コーディングされたか、パケット化ルールを使用してそれらから推測されるデコード順序を明示的に示す手段として使用します。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-REMUX-BUF-SIZE、SPROP-REMUX-BUF-REQ、REMUX-BUF-CAP、SPROP-REMUX-INIT-BUF-MAX、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のアクセスユニットの1つ以上のNALユニットがRTPセッションAに存在する場合、同じアクセスユニットの1つ以上の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つのオプションは、空のNALユニット（セクション4.10で定義）を使用することです。これは、アクセスユニットの並べ替えプロセスについてセクション6.2.1で説明したプロセスで使用できます。
- 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ストリームから複数のRTPストリームを生成するたてがみの場合、挿入されたパケットには同じ壁1杯の時間にマッピングされるRTPタイムスタンプが必要です（NTP形式）は、より低い拡張RTPセッションまたはベースRTPセッションに存在するアクセスユニットのパケットのRTPタイムスタンプの1つとして）。メディアタイムスタンプ（NTPタイムスタンプ）は、挿入されたパケットと対応するアクセスユニットのパケットで同じでなければならないため、これは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に存在しないと仮定します。上記のルールに従ってセッション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
図5.拡張層RTPセッションでのパケット挿入のためのRTPタイムスタンプの例の計算
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タイムラインの垂直バー（ "|"）は、少なくとも1つのセッションにアクセスユニットデータが存在することを示しています。「X」マークは、送信者レポートの時間を示しています。NTPタイムラインのすぐ下に示されているセッションBのRTPタイムスタンプタイムラインは、2つのタイムセグメント、T1とT2を示しています。T1は、RTPタイムスタンプクロックティックで表される2つのセッション間の送信者レポートの間の時間差であり、T2は、RTPタイムスタンプクロックティックで表現されるA2パケットへのセンサーレポートからの時差です。これらの違いの合計は、挿入されたパケットB2の正しいRTPタイムスタンプを導出するために、セッションBのセッションレポートのRTPタイムスタンプに追加されます。言い換えると：
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:
TOTTP（）を、NTPタイムスタンプの差を与えられた場合、RTPの時刻差（使用済みのクロックのクロックティック）を計算する関数と、EffrtpDiff（）をラップアラウンドを含む2つのタイムスタンプ間の有効な違いを計算する関数とします。
effRTPdiff( ts1, ts2 ):
Effrtpdiff（TS1、TS2）：
if( ts1 <= ts2 ) then
effRTPdiff := ts1-ts2
else
effRTPDiff := (4294967296 + ts2) - ts1
We have:
t1 = toRTP(NTP_A - NTP_B) and 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)
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.
o 非pacsi nalユニットのnalu時間が、以前の非pacsiユニットのnalu-timeにデコード順に等しくない場合、以前のパケットには、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-Aパケットでは、STAP-Aパケットの最初の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-Aパケットの場合、前のパケットにはFU-Aパケットと同じRTPタイムスタンプが必要であり、次のものが適用されます。
o If the FU-A packet is the start of the fragmented NAL unit, the following applies.
o FU-Aパケットが断片化されたNALユニットの開始である場合、次のものが適用されます。
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;
o 断片化されたNALユニットのNALU時間が、以前の非PACSIユニットのNALU時間とデコード順に等しくない場合、以前のパケットには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 それ以外の場合、（断片化されたNALユニットのNALU時間は、以前の非PACSIユニットのデコード順でのNALU時間に等しくなります）、以前のパケットには、DONCフィールドを含むPacsi Nalユニットが含まれる場合があります。
o Otherwise, if the FU-A packet is the end of the fragmented NAL unit, the following applies.
o それ以外の場合、FU-Aパケットが断片化されたNALユニットの終わりである場合、次のものが適用されます。
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-Timeに等しく、多くの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-Aパケットは断片化されたNALユニットの開始でも終わりでもありません）、以前のパケットはFU-Aパケットでなければなりません。
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.
o オプションのメディアタイプパラメーターSPROP-MST-MST-CSDON-Always-Presentが1に等しい場合、使用中のセッションパケット化モードは非インテリアモードでなければならず、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.
o Pacsi nalユニットが存在する場合、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ユニットは、H.264で非VCL NALユニットとして知られています。拡張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 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ユニットが複数のRTPセッションに関連している場合、どちらも他の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.
同じSVCビットストリームからデータを受信するために複数のRTPセッションを使用しているマルチセッション伝送の場合、脱パケット化プロセスは次のように指定されています。
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で指定されたメカニズムによって特定される必要があります。拡張RTPセッションには、通常、セクション7.2.3で定義されているメカニズムで示されるように、少なくとも1つの他のRTPセッションに依存するRTPストリームが含まれています。Enhancement 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.
NI-Tパケット化モードが使用されている場合、次のプロセスを適用する必要があります。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パケットの場合、セクション4.10で定義されているNI-MTAPパケットの「TSオフセット」値を使用して、NALU時間がそれぞれ含まれている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セッションに存在するNALユニットを、特定の時間インスタンスのアクセス単位のデータを含むRTPセッションと関連付けるために使用されます。それ以外の場合は、特定のアクセスユニットのデータが含まれないセッションでアクセスユニットインジケーターとして機能します。これらの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:
受信機が操作ポイント（DID、QID、およびTID値を確立し、この操作ポイントの最高の拡張RTPセッションを特定したと想定されています。複数のRTPセッションの複数のRTPストリームからのNALユニットのデコード順序は、次の手順に相当するプロセスを実行することにより、アクセスユニットにグループ化された単一のNALユニットに回復する必要があります。一般的なプロセスは、[RFC6051]のセクション4.2で説明されています。便宜上、[RFC6051]の指示は繰り返され、完全なRTPパケットではなくNALユニットに適用されます。さらに、セクション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 このプロセスは、セッションの（除去）バッファで利用可能な最初のメディアタイムスタンプTS（NTP形式）を使用して、最高の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 メディアタイムスタンプTSの同じ値に関連付けられたすべてのNALユニットを収集します。これは、受信したRTPセッションのすべての（除去）バッファーから、最高のRTPセッションから始まります。収集された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.
o 収集されたNALユニットは、最低RTPセッションから始まるセクション7.2.3で指定されているように、依存関係の表示によって導出されたセッション依存関係の順に配置します。
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ユニットの順序付けルールを満たすことにより、セッションを特定のアクセスユニット内でデコード順に配置します。
o Remove NI-MTAP and any PACSI NAL units from the access unit AU(TS).
o アクセスユニットAu（TS）からNi-MTAPおよびPACSI NITを削除します。
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.
有益な注意：パケットの損失により、すべてのセッションが最高のRTPセッションに存在するメディアタイムスタンプ値TSにNALユニットが存在するわけではない可能性があります。そのような場合、アルゴリズムは次の場合があります。a）受信したすべてのRTPセッションにNALユニットが存在する次の完全なアクセスユニットに進みます。またはb）アクセスユニットが完了する最高のRTPセッションである新しい最高のRTPセッションを検討し、上記のプロセスを適用します。アルゴリズムは、すべてのセッションにNALユニットを含む完全かつエラーのないアクセスユニットが受信されたときに、元の最高のRTPセッションに戻る場合があります。
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つのソースとして送信されるSVCビットストリームを含む3つのRTPセッションA、B、およびCを示しています。この例では、依存関係シグナル（セクション7.2.3で説明）は、セッションAがベースRTPセッションであり、Bは最初の拡張RTPセッションであり、Aに依存し、Cは2番目の拡張RTPセッションであり、AおよびAおよびAおよびAおよびB.階層画像コーディング予測構造が使用されます。セッション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.
このプロセスは、最初に最高のセッションCに存在する最初のメディアタイムスタンプTS [1]に関連付けられたNALユニットに進み、DEのそれぞれのTS [1]を使用して前回の（デコード順）NALユニットを削除/無視します。-RTPセッションa、b、およびCのバッファーを調整する次に、セッションCから始まるデコード順序で使用可能な最初のメディアタイムスタンプ（TS [1]）が選択され、RTPセッションAから始まるNALユニット、およびセッションBとCこのメモのセクション7.2.3（TS [1]の例：最初のセッションB、次にセッションc）で要求されるRTPセッション依存性の順序に配置され、アクセスユニットAU（TS [1]）に関連付けられています。メディアタイムスタンプTS [1]。次に、最高のRTPセッションCでの外観の次のメディアタイムスタンプTS [3]が処理され、上記のプロセスが繰り返されます。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ユニットをグループ化します。-RTPセッション「[]」 - メディアタイムスタンプTSのRTPセッション整数値の同じアクセスユニットAU（TS [..]）の対応するNALユニットを示します。（TS [..]）、各TS値を上回るセッションのNALユニットで構成されています。
Figure 6. Example of decoding order recovery in multi-source transmission.
図6.マルチソース伝送における順序回復のデコードの例。
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.
アクセスユニット内で、[H.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
表12.アクセスユニット内のNALユニットタイプの順序付け
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.
スケーラブルなネスト（30）のペイロードと0（バッファリング期間）のネストされたペイロードを含むSEIメッセージが存在する場合、これらは最初のSEIメッセージに従います。all_layer_representations_in_au_flagが1に等しいこのようなseiメッセージが最初に配置され、その後に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
14スケーラブルエクステンションのプレフィックスNALユニット1非IDR画像のコードスライス5 IDR画像のコード化されたスライス
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.)
タイプ1または5のNALユニットは、特定のアクセスユニットの1回のセッションのみで送信されます。それらはセッションの注文に配置されます。（注：任意のアクセスユニットには、両方ではなく、タイプ1またはタイプ5のNALユニットのみが含まれます。）
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単位が付いています。他の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.
アクセスユニット内のフィラーデータNALユニットの唯一の制限は、同じアクセスユニットを持つ最初のVCL NALユニットの前にいないことです。
19 Coded slice of an auxiliary coded picture without partitioning
19の分割なしで補助コード化された画像の19のコード化されたスライス
These NAL units will be sent within only a single session for any given access unit, and are placed in session order.
これらのNALユニットは、特定のアクセスユニットの1回のセッションのみで送信され、セッションの注文に配置されます。
20 Coded slice in scalable extension 21-23 Reserved
スケーラブルな拡張で20個のコード化されたスライス21-23は予約されています
Type 20 NAL units are placed in increasing order of DQId. Within each DQId value, they are placed in session order.
タイプ20 NALユニットは、DQIDの順序を増やします。各DQID値内で、それらはセッションの順序に配置されます。
(Note: SVC slices with a given DQId value will be sent within only a single session for any given access unit.)
（注：特定のDQID値を持つSVCスライスは、特定のアクセスユニットの1回のセッションのみで送信されます。）
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-REMUX-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ユニットを含むパケットよりも別のパケットにある情報に依存する場合があります。これは、単一NALユニットパケット自体にCS-Don情報が含まれていないため、単一NALユニットパケットに含まれる非PACSI NALユニットに対してCS-DON値を導出する必要がある場合に発生します。この場合、NALユニットに対して必要なCS-DON情報を含むパケットが受信されない場合、このNALユニットは、正しい順序でデコーダーに供給できないため、受信機によって破棄する必要があります。オプションのメディアタイプパラメーターSPROP-MST-CSDON-Always-Presentが1に等しい場合、そのような依存関係は存在しません。したがって、ユニット、したがって、受信者は受信した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 関数アブスドンは、[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は、オプションのSPROP-MST-REMUX-BUF-SIZEメディアタイプパラメーターの値です。
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.
o 最高のRTPセッションのsprop-mst-max-don-diffが存在する場合、don_diff（m、n）は、最高のRTPセッションのsprop-mst-max-don-diffの値よりも大きく、nはnが次のとおりです。受信したNALユニットとMの間でアブスドンの最大値を持つNALユニットは、受信したNALユニットの中でアブスドンの最小値を持つ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セッションのオプションのSPROP-REMUX-INIT-BUF-TIMEタイプのパラメーターの値以上の期間にわたって続きました。
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.
o 再倍率バッファに少なくともN VCl NALユニットが含まれている場合、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.
o 最高のRTPセッションのSPROP-MST-MAX-DON-DIFFが存在する場合、DON_DIFF（M、N）が最高のRTPセッションのSPROP-MAX-DON-DIFFよりも大きいすべてのNALユニットMがREから削除されます-Multiplexingバッファーと以下に指定された順序でデコーダーに渡されます。ここでは、nは、再倍率バッファーのNALユニットの間でアブスドンの最大値を持つ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.
o CS-DONの値に関連付けられた各NALユニットについて、CS-DON距離が次のように計算されます。NALユニットのCS-DONの値がPDONの値よりも大きい場合、CS-DON距離はCS-DON-PDONに等しくなります。それ以外の場合、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.
o 必要な数のNALユニットがデコーダーに渡された場合、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 provided for applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use SDP.
このセクションでは、ペイロード形式のオプションの機能とBitStreamの特定の機能を選択するために使用できるパラメーターを指定します。パラメーターは、SVCコーデックのメディアタイプ登録の一部としてここで指定されています。セッション説明プロトコル（SDP）[RFC4566]へのパラメーターのマッピングは、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-Parameter-Setsパラメーターは、プロファイルレベル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ユニットストリーム」は、SSTの現在のRTPセッションで伝えられたすべてのNALユニットを指し、現在のRTPセッションで伝えられ、他のRTPで伝えられているすべての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：ベース16 [rfc4648]（六分子）シーケンスパラメーターセットまたは[H.264]で指定されたサブセットシーケンスパラメーターセットNALユニットの次の3バイトの表現：1）profile_idc;2）ここでは、constraint_set0_flag、constraint_set1_flag、constraint_set2_flag、constraint_set3_flag、constraint_set5_flag、およびreserved_zero_2bits、reserved_zero_2bitsのconstraint_set3_flag、constraint_zero_2bits、constraint_set1_flag、constraint_set2_flagの値で構成されるプロファイルと呼ばれるバイト。。[h.264]では、remervered_zero_2bitsは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バイトとプロファイルバイトの一部のフィールドによって集合的に示されています。プロファイルバイト内のフィールドの値に応じて、デフォルトのサブプロファイルは、サブセクションG.7.4で指定されているように、1つのプロファイルでサポートされているコーディングツールのセット、または複数のプロファイルのコーディングツールの共通のサブセットである場合があります。[H.264]の.2.1.1。デフォルトレベルはレベル_IDCバイトで示され、プロファイル_IDCが66、77、または88（ベースライン、メイン、または拡張プロファイル）に等しい場合、レベル_IDCは11に等しく、さらにプロファイルのビット4（Constraint_set3_flag）によって等しくなります。-IOPバイト。profile_idcが66、77、または88（ベースライン、メイン、または拡張プロファイル）に等しく、level_idcが11に等しく、プロファイルバイトのビット4（constraint_set3_flag）が1に等しい場合、デフォルトのレベルはレベルですレベルはレベルです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には、[H.264]の付録AおよびGで定義されているすべてのプロファイルを示し、各プロファイルについて、同じサブプロファイルを表すプロファイル_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 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.
表13. 1つのプロファイルでサポートされているコーディングツールの完全なセットに対応する同じサブプロファイルを表すプロファイル_IDCとプロファイル-IOPの組み合わせ。以下では、xは0または1のいずれかで、プロファイル名は次のように示されている場合があります。CB：制約付きベースラインプロファイル、B：ベースラインプロファイル、M：メインプロファイル、E：拡張プロファイル、H：高プロファイル、H10：ハイ10プロファイル、H42：高4：2：2プロファイル、H44：ハイ4：4：4予測プロファイル、H10I：ハイ10イントラプロファイル、H42I：高4：2：2イントラプロファイル、H44I：高4：4：4イントラプロファイル、C44I：CAVLC 4：4：4イントラプロファイル、SB：スケーラブルベースラインプロファイル、SH：スケーラブルな注目、およびSHI：スケーラブルな高プロファイル。
Profile profile_idc profile-iop (hexadecimal) (binary)
プロファイルプロフィール
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.
たとえば、上記の表では、プロファイルが等しい11xx0000に等しい58（拡張）に等しいプロファイル_idcは、x1xx0000に等しいプロファイルが等しいプロファイル_idcに対応する同じサブプロファイルを42（ベースライン）に等しいと同じサブプロファイルを示します。Profile_idcとProfile-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-Levelが存在しない場合、プロファイルレベルIDからのデフォルトレベルは、コーデックがサポートしたい最高レベルを示します。Max-Recv-Levelが存在する場合、Codecが受信するためにサポートする最高レベルを示します。受信または送信のいずれかの場合、サポートされている最高レベルよりも低いすべてのレベルもサポートする必要があります。
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-of-n-of-n-of-n-of-n-of-nowの選択手順を使用できます（[RFC3264]のセクション10.2）。また、N-of-n-of-Nコーデックの選択手順を使用して、同じサブプロファイルを表すProfile_idcとProfile-IOPのさまざまな組み合わせを提供することもできます。同じサブプロファイルを表すProfile_idcとProfile-IOPの多くの異なる組み合わせがある場合、NON-N-of-n-of-n-of-n-of-no-of-of-ofのコーデック選択手順を使用すると、かなり大きなSDPメッセージが生じる可能性があります。したがって、受信者は、同じサブプロファイルを表すプロファイル_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-LEVEL：このパラメーターは、最高レベルがデフォルトレベル（プロファイルレベルIDで示されるレベル）よりも高いレベルが高い場合、レシーバーがサポートする最高レベルを示すために使用できます。max-recv-levelの値は、[h.264]で指定されたシーケンスパラメーターセットNALユニットの構文要素プロファイル_IDCの後の2バイトのベース16（ヘキサデシマル）表現です：プロファイル-IOP（上記で定義）およびlevel_idc。if（max-recv-levelのlevel_idcバイトは11に等しく、max-recv-revelのプロファイルバイトのビット4は1）または（max-recv-levelのレベル_idcバイトが9に等しいMAX-RECVレベルのプロファイルバイトのビット4は0に等しい）、レシーバーがサポートする最高レベルはレベル1Bです。それ以外の場合、レシーバーがサポートする最高レベルは、MAX-RECVレベルのレベル_IDCバイトを10で割ったものに等しくなります。
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-BASE-LEVEL：このパラメーターは、SVCストリームを交渉する際にベースレイヤーのレシーバーがサポートする最高レベルを示すために使用できます。Max-Recv-Base-Levelの値は、[H.264]で指定されたシーケンスパラメーターセットNALユニットの構文要素プロファイル_IDCの後の2つのバイトのベース16（16進数）表現です。level_idc。if（max-recv-levelのlevel_idcバイトは11に等しく、max-recv-revelのプロファイルバイトのビット4は1）または（max-recv-levelのレベル_idcバイトが9に等しいMAX-RECVレベルのプロファイルバイトのビット4は0に等しい）、ベースレイヤーのレシーバーがサポートする最高レベルはレベル1Bです。それ以外の場合、ベースレイヤーのレシーバーがサポートする最高レベルは、MAX-RECVレベルのレベル_IDCバイトを10で割ったものに等しくなります。
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ビットの単位単位の最大コード化された画像バッファーサイズを示す整数です。このパラメーターは、cpbbrvclactorとcpbbrnalfactorの単位を使用しないことに注意してください（[H.264]の表A-1を参照）。MAX-CPBパラメーターは、受信機がプロファイルレベルIDパラメーターまたはMAX-RECV-LEVELパラメーターの値で伝達されるシグナル最高レベルで必要なコード化された画像バッファメモリの最小量よりも多くのメモリを持っていることを示しています。max-cpbが信号された場合、受信機は、信号された最高レベルの[H.264]の表A-1のmaxcpb値が置き換えられることを除いて、信号された最高レベルに適合するNALユニットストリームをデコードできる必要があります。max-cpbの値（必要なときにcpbbrvclactorとcpbbrnalfactorを考慮した後）。MAX-CPBの値（必要に応じてCPBBRVCLFactorとCpbBrnalFactorを考慮した後）は、最高レベルで[H.264]の表A-1に示されているMAXCPBの値以上でなければなりません。送信者は、この知識を使用して、[H.264]の表A-1の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.
有益な注意：コード化された画像バッファーは、[H.264]の仮説参照デコーダー（HRD、付録C）で使用されます。HRDの使用は、SVCエンコーダーで推奨され、生成されたビットストリームが標準に適合し、出力ビットレートを制御することを確認します。したがって、コード化された画像バッファーは、インターレービング、再倍率、および脱ジャッタバッファを含む、受信機の他の潜在的なバッファーから概念的に独立しています。[H.264]の付録Cで指定されているように、コード化された画像バッファーをデコーダーに実装する必要はありません。標準に準拠したデコーダには、標準に準拠したビットストリームをデコードできる場合、バッファリング配置を使用できます。したがって、実際には、ビデオデコーダーの入力バッファーは、受信機のインターレービング、再倍率、および脱ジャッタバッファーと統合できます。
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パラメーターでは1000ビットあたり1000ビット、NAL HRDパラメーターの1秒あたり1200ビットの単位で最大ビデオビットレートを示す整数です。このパラメーターは、cpbbrvclactorとcpbbrnalfactorの単位を使用しないことに注意してください（[H.264]の表A-1を参照）。
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.
MAX-BRパラメーターは、受信機のビデオデコーダーが、プロファイルレベルIDパラメーターまたはMAX-RECVレベルのパラメーターの値で伝えられるシグナル最高レベルで必要とされるよりも高いビットレートでビデオをデコードできることを信号します。。
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.
o MAX-BRの値（必要に応じてCPBBRVCLFACTORとCPBBRNALFactorを考慮した後）は、[H.264]の表A-1の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).
o MAX-CPBパラメーターが存在しない場合、次の式の結果は、[H.264]の表A-1のMAXCPBの値を置き換えます：（シグナルレベルのMaxCPB）最高レベル）。
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).
たとえば、メインプロファイルレベル1.2のメインプロファイルレベル1550に等しいメインプロファイルレベル1.2の機能が1550に等しい場合、VCL HRDパラメーターの最大ビデオビットレートが1550 kbits/secの最大ビデオビットレートを示しています。、および4036458ビットのCPBサイズ（1550000 /384000 * 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.
MAX-BRの値（必要に応じてCPBBRVCLFACTORおよびCPBBRNALFactorを考慮に入れた後）は、シグナル付き最高レベルの[H.264]の表A-1に与えられた値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-CAP：このパラメーターは[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-Parameter-Sets：このパラメーターは、NALユニットストリームに配置できる任意のシーケンスパラメーターセット、サブセットシーケンスパラメーターセット、および画像パラメーターセットNALユニット（ここでは初期パラメーターセットNALユニットと呼ばれる）を伝達するために使用できます。デコード順序で他のNALユニットに先行し、プロファイルレベルIDのデフォルトレベルに関連付けられています。パラメーターは、任意の機能交換手順でコーデック機能を示すために使用してはなりません。パラメーターの値は、[H.2644のセクション7.3.2.1、7.3.2.2、およびG.7.3.2.1で指定されているパラメーターセットNAL単位のベース64 [RFC4648]表現のコンマ（ '、'）分離されたリストです。]。パラメーターセット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.
有益なメモ：SDPオファー/回答モデルでいくつかのペイロードタイプが提供されている場合、それぞれが独自のSprop-Parameter-Setsパラメーターを備えている場合、レシーバーはそれらのパラメーターセットが競合するストレージ場所（つまり、パラメーターの同一の値を使用しないと想定できません。識別子を設定）。したがって、レシーバーはすべてのSPROP-Parameterセットをバッファーし、特定のペイロードタイプをデコードするデコーダーインスタンスでそれらを使用できるようにする必要があります。
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-LEVEL-PARAMETER-SETS：このパラメーターは、NALユニットストリームに配置することができるシーケンス、サブセットシーケンス、および画像パラメーターセットNALユニット（ここでは初期パラメーターセットNALユニットと呼ばれる）を伝達するために使用される場合があります。デコード順序で他のNALユニットと、プロファイルレベルIDのデフォルトレベルとは異なる1つ以上のレベルに関連付けられています。パラメーターは、任意の機能交換手順でコーデック機能を示すために使用してはなりません。
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-LEVEL-PARAMETER-SETSパラメーターには、デフォルトレベルとは異なる1つ以上のレベルのパラメーターセットが含まれています。すべてのパラメーターは、デフォルトのサブプロファイルの1つのレベルが受信機によって受け入れられている場合に使用するためにターゲットにされたセットを設定します。これにより、受信者は受け入れられたレベルのパラメーターセットをインストールし、残りを破棄できます。3バイトフィールドの名前はPlidで、1つのレベルに関連付けられたすべてのパラメーターセットはPSLという名前で、Sprop-Parameter-Setsと同じ構文を持っています。各レベルのパラメーターセットは、PSL、すなわち剥がし、それに続いてコロン（ '：'）とBase64 [RFC4648]レベルの初期パラメーターセットNALユニットの表現が続く、PSLの形式で表されます。剥離の各ペア：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.
インバンドパラメーターセット：このパラメーターは、受信機の機能を示すために使用できます。値は0または1のいずれかに等しい場合があります。値1は、レシーバーがSprop-Parameter-SetsおよびSprop-Level-Parameter-Setsで帯域外パラメーターセットを破棄することを示します。-バンド。値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-Modeが「Ni-T」、「Ni-C」、または「Ni-TC」に等しい場合、パケット化モードは2に等しくてはなりません（それ以外の場合、MSTモードは「I-C」に等しくなります）、パケット化モードは2に等しくなければなりません。
sprop-interleaving-depth: This parameter is as specified in [RFC6184].
SPROP-INTERLEAVING-DEPTH：このパラメーターは[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].
SEINT-BUFF-CAP：このパラメーターは[RFC 6184]で指定されています。
sprop-init-buf-time: This parameter is as specified in [RFC6184].
SPROP-ISIT-BUF-TIME：このパラメーターは[RFC6184]で指定されているとおりです。
sprop-max-don-diff: This parameter is as specified in [RFC6184].
SPROP-MAX-DON-DIFF：このパラメーターは[RFC6184]で指定されているとおりです。
max-rcmd-nalu-size: This parameter is as specified in [RFC6184].
max-rcmd-nalu-size：このパラメーターは[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-Mode：このパラメーターは、NALユニットストリームのプロパティまたは受信機の実装の機能を信号するために使用できます。このパラメーターが存在する場合、マルチセッション伝送を使用する必要があります。それ以外の場合（このパラメーターは存在しません）、単一セッション伝送を使用する必要があります。このパラメーターが存在する場合、次のパラメーターが適用されます。MSTモードの値が「Ni-T」に等しい場合、Ni-Tモードを使用する必要があります。MSTモードの値が「NI-C」に等しい場合、NI-Cモードを使用する必要があります。MSTモードの値が「Ni-TC」に等しい場合、Ni-TCモードを使用する必要があります。MSTモードの値が「I-C」に等しい場合、I-Cモードを使用する必要があります。MST-Modeの値には、「Ni-T」、「Ni-C」、「Ni-TC」、または「I-C」のいずれかが次のトークンのいずれかを持っている必要があります。
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-always-present：mst-modeが存在しない場合、またはmst-modeの値が「ni-t」または「i-c」に等しい場合、このパラメーターは存在しないでください。このパラメーターは、NALユニットストリームのプロパティを信号します。sprop-mst-csdon-always-presentが存在し、値が1に等しい場合、パケット化モードは1に等しく、NALユニットストリームを運ぶすべてのRTPパケットはPacsi nalユニットを含むstap-aパケットでなければなりませんさらに、Jフィールドが1に等しいDONCフィールドまたはNi-MTAPパケットが含まれています。SPROP-MST-CSDON-Always-Presentが存在し、値が1に等しい場合、特定のNALユニットのCS-DON値は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-Always-Presentが現在のRTPセッションに存在する場合、現在のRTPセッションが依存しているすべてのRTPセッションにも存在する必要があり、SPROP-MST-CSDON-Always-Presentの値は同一です現在の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-REMUX-BUF-SIZE：MST-Modeが存在しない場合、またはMST-Modeの値が「Ni-T」に等しい場合、このパラメーターは存在しないでください。このパラメーターは、MSTモードが存在し、MSTモードの値が「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-remux-buf-sizeの値は、0〜32767の範囲の整数でなければなりません。
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-REMUX-BUF-REQ：MSTモードが存在しない場合、またはMSTモードの値が「Ni-T」に等しい場合、このパラメーターは存在しないでください。MSTモードが存在し、MSTモードの値が「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-REMUX-BUF-REQは、NALユニットストリームに必要なサイズの再マルチプレックスバッファーを信号します。受信者は、現在のRTPセッションから受信したNALユニットのデコード順序を回復できることが保証されています。RTPセッションは、現在のRTPセッションは、再溶解バッファーサイズが少なくとも少なくともの場合、セクション6.2.2で指定されています。バイト単位のSprop-remux-buf-reqの値。
The value of sprop-remux-buf-req MUST be an integer in the range of 0 to 4294967295, inclusive.
SPROP-REMUX-BUF-REQの値は、0〜4294967295の範囲の整数でなければなりません。
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.
REMUX-BUF-CAP：MSTモードが存在しない場合、またはMSTモードの値が「Ni-T」に等しい場合、このパラメーターが存在しないでください。このパラメーターは、受信機の実装の機能を信号するために使用でき、セクション6.2.2で指定されているように、受信機がNALユニットデコード順序を回復するために利用可能なバイト単位の再成長バッファースペースの量を示します。レシーバーは、SPROP-REMUX-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.
パラメーターが存在しない場合、Remux-Buf-Capには0の値を使用する必要があります。Remux-Buf-Capの値は、0〜4294967295の範囲の整数でなければなりません。
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-REMUX-INIT-BUF-TIME：このパラメーターを使用して、NALユニットストリームのプロパティを信号することができます。MSTモードが存在しない場合、またはMSTモードの値が「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-Remux-Init-Buf-Timeの値は、0〜4294967295の範囲の整数でなければなりません。
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-DON-DIFF：このパラメーターを使用して、NALユニットストリームのプロパティを信号することができます。送信機または受信機またはコーデック機能を信号に使用してはなりません。MSTモードが存在しない場合、またはMSTモードの値が「Ni-T」に等しい場合、パラメーターを存在しないでください。sprop-mst-max-don-diffは、0〜32767の範囲の整数です。sprop-mst-max-don-diffが存在しない場合、パラメーターの値は特定されていません。sprop-mst-max-don-diffは、[RFC6184]で指定されているようにSprop-Max-Don-Diffと同じ計算され、デコード順序数は、セッションのデコード順序番号に置き換えられます。
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-Scalability-INFO：このパラメーターは、[H.264]の付属書Gで指定されているように、スケーラビリティ情報SEIメッセージを含むNALユニットを伝達するために使用できます。このパラメーターは、SVCビットストリームの含まれる層を信号するために使用できます。パラメーターは、任意の機能交換手順でコーデック機能を示すために使用してはなりません。パラメーターの値は、スケーラビリティ情報SEIメッセージを含むNALユニットのBase64 [RFC4648]表現です。存在する場合、NALユニットには、スケーラビリティ情報SEIメッセージであるSEIメッセージが1つだけ含まれている必要があります。
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.
Scalable-Layer-ID：このパラメーターは、SPROP-SCALABILITY-INFOまたはSPROP-Operation-Point-INFOを使用して、受信者がオファーまたは宣言された操作ポイントまたはレイヤーを選択するために使用できます。Scalable-Layer-IDの値は、[H.264]の付録Gまたはスプロップオペレーションポイント-INFOに含まれるレイヤーIDで指定されているスケーラビリティ情報SEIメッセージのlayer_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-OPERATION-POINT-INFO：このパラメーターは、RTPセッションの動作ポイントを記述するために使用できます。このパラメーターの値は、操作点説明ベクターのコンマ分離されたリストで構成されています。操作点説明ベクトルによって与えられる値は、[H.264]の付属書Gで指定されているスケーラビリティ情報SEIメッセージのスケーラブルレイヤーに対して与えられる値と同じ、または導出されているものです。スケーラビリティ情報SEIメッセージのスケーラブルレイヤーという用語は、TOMEAL_ID、依存関係_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個の要素があります。操作点説明ベクターの最初の値の前には '<'があり、操作点説明ベクターの最後の値の後にa '>'が続きます。SPROP-OPERATION-POINT-INFOの後に正確に1つの操作点説明ベクターが続く場合、これはRTPセッションに含まれる最高の動作点を説明します。2つ以上の操作点説明ベクターがある場合、最初の操作点ベクトルは、最低と最後のものが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.
- Layer-ID：この値は、スケーラビリティ情報SEIメッセージで示されるレイヤー_ID（依存関係_ID、quality_id、およびthipalal_idの同じ値）と同一の動作点のレイヤー識別子を指定します。このフィールドは空である可能性があり、値が特定されていないことを示しています。layer-idを備えた複数の操作点説明ベクターがある場合、layer-idの値を連続する必要はありません。
- temporal-ID: This value specifies the temporal_id of the operation point. This field MUST NOT be empty.
- ThePoural-ID：この値は、操作点のTheperal_idを指定します。このフィールドは空であってはなりません。
- dependency-ID: This values specifies the dependency_id of the operation point. This field MUST NOT be empty.
- 依存関係ID：この値は、操作ポイントの依存関係_IDを指定します。このフィールドは空であってはなりません。
- quality-ID: This values specifies the quality_id of the operation point. This field MUST NOT be empty.
- Quality-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-Opation-Point-INFOベクターのパラメータープロファイルレベル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.
- AVG-Framerate：この値は、動作点の平均フレームレートを指定します。この値は、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.
- AVG-Bitrate：この値は、動作点の平均ビットレートを指定します。このパラメーターは、ストリーム全体にわたって1秒あたりのKBITの整数として与えられます。このパラメーターは、スケーラビリティ情報SEIメッセージが1秒あたりビットで提供され、可変時間ウィンドウで計算されていることに注意してください。このフィールドは空である可能性があり、値が特定されていないことを示しています。
- 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.
- Max-Bitrate：この値は、動作点の最大ビットレートを指定します。このパラメーターは、1秒あたりKBITの整数として指定され、各1秒ウィンドウごとに最大ビットレートを説明します。このパラメーターは、スケーラビリティ情報SEIメッセージで1秒あたりビットで提供され、可変時間ウィンドウで計算されることに注意してください。このフィールドは空である可能性があり、値が特定されていないことを示しています。
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-Scalability-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-reording-Required：このパラメーターは、NALユニットストリームの特性を信号するために使用できます。MSTモードが存在しない場合、またはMSTモードの値が「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ユニットストリームのプロパティを示すために使用できます。このパラメーターの存在は、SSTで使用される場合、またはMSTで使用される場合、またはこのパラメーターが存在する他のRTPセッションと組み合わせて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:
詳細については、連絡先への個人およびメールアドレス：
Ye-Kui Wang, yekui.wang@huawei.com
Ye-Kui Wang、Yekui.wang@huawei.com
Intended usage: 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フレーミングに依存するため、RTP [RFC3550]を介した転送に対してのみ定義されます。この時点では、他のフレーミングプロトコル内の輸送は定義されていません。
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
Ye-Kui Wang、Yekui.wang@huawei.com
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
Change Controller：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 SDPの「m =」行のメディア名はビデオでなければなりません。
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-LEVEL、MAX-RECV-BASE-LEVEL、MAX-MBPS、MAX-FS、MAX-CPB、MAX-DPB、MAX-BR、Redundant-PIC-CAP、-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-istinit-buf-time、sprop-mst-max-don-diff、およびscalable-layer-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スケーラビリティINFO、SPROP-OPERATION-POINT-INFO、SPROP-NO-NAL-REORDING-REQUERED、SPROP-AVC対応、SDPの「A = FMTP」行に含めるか、[RFC5576]のセクション6.3で指定されている「FMTP」ソース属性を使用して伝達する必要があります。特定のメディア形式（つまり、RTPペイロードタイプ）の場合、SPROP-Parameter-SetsまたはSPROP-LEVEL-PARAMETERセットをSDPの「A = FMTP」ラインに含め、「FMTP」ソースを使用して伝達する必要はありません。属性。SDPの「a = fmtp」行に含まれる場合、これらのパラメーターは、パラメーター=値ペアのセミコロン分離されたリストの形で、メディア型文字列として表されます。「FMTP」ソース属性を使用して伝達される場合、これらのパラメーターは、「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].
有益なメモ：「FMTP」ソース属性を使用したスプロップパラメーターセットとSPROPレベルパラメーターセットの運搬により、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:
ユニキャスト使用に関する交渉のために、オファー/回答モデル[RFC3264]でSDPを使用してRTPを介してSVCストリーム（メディアサブタイプH264-SVCを使用）が提供される場合、次の制限とルールが適用されます。
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-Level-IDのレベル部分には、Revel_Idcが含まれ、プロファイル_IDCがプロファイル-IOPの66、77、または88、ビット4（Constraint_set3_flag）に等しいレベル1bを示すために含まれることに注意してください。プロファイルレベル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.
有益な注意：対称使用の要件は、プロファイルレベルIDのレベル部分には適用されず、他のストリームプロパティと機能パラメーターには適用されません。
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.
有益な注意：[H.264]では、レベル1Bを除くすべてのレベルはレベル_IDCの値を10で割った値に等しくなります。レベル1Bはレベル1.0よりも高いがレベル1.1よりも低く、アドホックでシグナルが表示されます。マナー。ベースライン、メイン、および拡張プロファイル（それぞれ66、77、および88に等しいプロファイル_IDCを使用）の場合、レベル1Bは11（つまり、レベル1.1と同じ）とconstraint_set3_flagが1に等しいレベル_IDCで示されます。プロファイル、レベル1bは9に等しいレベル_IDCで示されます（ただし、これらのプロファイルのレベル1Bはレベル1よりも高く、レベル_IDCが10に等しく、レベル1.1よりも低いことに注意してください）。SDPのオファー/回答では、回答は、オファーに示されているレベルよりも低いレベルまたは低いレベルを示す場合があります。レベル1Bのアドホックな指標により、提供者と応答者は、プロファイル_IDCが66、77、または88に等しい場合、パラメータープロファイルレベルIDのミドルオクテットのビット4（constraint_set3_flag）の値をチェックする必要があります。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.
有益なメモ：提供者がスケーラブルレイヤーIDを含めない回答を受け取った場合、メディアタイプ（つまり、ビデオ/H264-SVC）および上記のメディア構成パラメーターに基づいてオファーで宣言されていないペイロードタイプを比較する必要があります。すでに宣言されているペイロードタイプ。これにより、問題の構成が新規であるかどうか、または回答で異なるペイロードタイプ番号を使用できるため、既に提供されている構成と同等かどうかを判断できます。
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-Opation-Point-INFOパラメーターを使用して、異なる動作点について説明することができます。最初のものは、[H.264]の付録Gで定義されたスケーラビリティ情報SEIメッセージ全体を導入しますが、2番目のものは、たとえば、動作点に関する重要な情報のみを含むこの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-OPERATION-POINT-INFOまたはSPROP-SCALABILATY-INFO）がオファーで提供されている場合、応答者はSPROPスケーラビリティインフォメーションまたはSPROP-OPERATION-POINT-INFOパラメーターで提供されるさまざまな動作ポイントから選択できます回答にスケーラブルレイヤー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-Levelは、存在する場合、受信にサポートされている最高レベルを宣言します。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-Base-Base-Levelは、存在する場合、受信にサポートされるベースレイヤーの最高レベルを宣言します。Max-Recv-Base-Levelが存在しない場合、ベースレイヤーでサポートされる最高レベルは、ベースレイヤーを含むSVCストリームとは別に制約されません。反対側のエンドポイントは、ベースレイヤーが最大レックレベルよりも高いレベルのスケーラブルなストリームを送信してはなりません。パラメーターデフォルトレベルを超えるレシーバー機能（Max-MBPS、MAX-SMBPS、MAX-FS、MAX-CPB、MAX-DPB、MAX-BR、およびMAX-RECV-LEVEL）を超えるパラメーターは、最大層の場合、基本層には適用されません。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-INTERLEAVING-DEPTH、SPROP-MAX-DON-DIFF、SPROP-ISIT-BUF-TIME、SPROP-MST-CSDON-ALWAYS-PRSENT、SPROP-REMUX-BUF-REQ、SPROP-MST-REMUX-BUF-SIZE、SPROP-REMUX-ISIT-BUF-TIME、SPROP-MST-MAX-DON-DIFF、SPROP-SCALABILITY-INFOLTINATION、SPROP-OPERATION-POINT-INFO、SPROP-NO-NAL-並べ替えが必要であり、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-mbps、max-fs、max-cpb、max-dpb、max-br、redundant-pic-cap、およびmax-rcmd-nalu-sizeを使用して、提供者または回答者のさらなる機能を宣言することができます。受信。これらのパラメーターは、方向属性がsendonlyである場合に存在しないでください。パラメーターは、オファーまたは応答者がストリームを受信するために受け入れるものの制限を説明しています。
o When mst-mode is not present and packetization-mode is equal to 2, the following applies.
o MST-Modeが存在せず、Packetization-Modeが2に等しい場合、次のものが適用されます。
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-capを含めることをお勧めします。また、受信機の機能が不明な場合は、異なるバッファリング要件を備えた複数のペイロードタイプの提供を検討することもお勧めします。
o When mst-mode is present and equal to "NI-C", "NI-TC", or "I-C", the following applies.
o MSTモードが存在し、「Ni-C」、「Ni-TC」、または「I-C」に等しい場合、次のものが適用されます。
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-Remux-Buf-Reqをオファーに含める必要があります。提供者と応答者がバッファリングの再溶融能力について互いに通知できるようにするために、両当事者はRemux-Buf-Capを含めることをお勧めします。また、受信機の機能が不明な場合は、異なるバッファリング要件を備えた複数のペイロードタイプの提供を検討することもお勧めします。
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.
o 存在する場合（SDPの「a = fmtp」行に含まれるか、[rfc5576]セクション6.3で指定されている「fmtp」ソース属性を使用して伝達される場合、sprop-parameter-setsまたはsprop-level-parameter-setsパラメーター。パラメーターセットの帯域外輸送に使用されます。ただし、パラメーターセットの帯域外輸送を使用する場合、パラメーターセットはさらに帯域内にさらに輸送される場合があります。
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つは応募者から、もう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-SetsとSprop-Level-Parameter-Setsのいずれかまたは両方が含まれます。Sprop-Parameter-SetsもSprop-Level-Parameter-Setsがオファーに存在しない場合、パラメーターセットの帯域内輸送のみが使用されます。
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.
o 答えに1に等しいインバンドパラメーターセットが含まれている場合、オファーはパラメーターセットをインバンドを送信する必要があります。それ以外の場合は、次のことが適用されます。
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.
回答者は、存在する場合はSprop-Parameter-Setsに含まれるパラメーターセットを使用して、着信NALユニットストリームをデコードし、存在する場合はSprop-Level-Parameterセットを無視する必要があります。
When sprop-parameter-sets is not present in the offer, in-band transport of parameter sets MUST be used.
SPROP-Parameter-Setsがオファーに存在しない場合、パラメーターセットの帯域内輸送を使用する必要があります。
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.
回答者は、受け入れられているレベルのSprop-Level-Parameter-Setsに含まれるパラメーターセットを使用する必要があります（つまり、回答のデフォルトレベルは、オファーからアンスワーへの方向で使用するレベルでもあります。）、存在する場合、着信NALユニットストリームをデコードし、SPROPレベルパラメーターセットとSPROPパラメーターセットに含まれる他のすべてのパラメーターセットを無視します。
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-Parameter-SetsまたはSprop-Level-Parameter-Setsのいずれかが含まれますが、2つの両方を含めてはなりません。SPROP-Parameter-SetsもSprop-Level-Parameter-Setsが回答に存在しない場合、パラメーターセットの帯域内輸送のみが使用されます。
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.
o オファーに1に等しいインバンドパラメーターセットが含まれている場合、回答者には、回答にSprop-Parameter-SetsまたはSprop-Revel-Parameter-Setsを含めるべきではなく、パラメーターセットをインバンドを送信する必要があります。それ以外の場合は、次のことが適用されます。
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 Answerer-offererの方向で使用するレベルが回答のデフォルトレベルに等しい場合、次のものが適用されます。
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.
オファーは、存在する場合は、存在する場合は、着信NALユニットストリームをデコードするために、Sprop-Parameter-Setsに含まれるパラメーターセットを使用し、存在する場合はSprop-Level-Parameterセットを無視する必要があります。
When sprop-parameter-sets is not present in the answer, the answerer MUST transmit parameter sets in-band.
SPROP-Parameter-Setsが回答に存在しない場合、Answererはパラメーターセットをインバンド送信する必要があります。
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 それ以外の場合は（Answerer-offererの方向で使用するレベルは、回答のデフォルトレベルに等しくありません）、次のものが適用されます。
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.
オファーは、回答に存在する場合、受信NALユニットストリームをデコードするために、回答者からオフフェラーへの方向に使用するレベルのスプロップレベルパラメーターセットに含まれるパラメーターセットを使用する必要があります。回答に存在する場合、SPROPレベルパラメーターセットとSPROPパラメーターセットに含まれる他のすべてのパラメーターセットを無視します。
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.
回答者のスプロップレベルパラメーターセットには、回答者の方向で使用するレベルのパラメーターセットが存在しない場合、回答者はパラメーターセットを帯域内に送信する必要があります。
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で指定されている「FMTP」ソース属性を使用してSPROP-Parameter-SetsまたはSPROP-LEVEL-PARAMETERセットが伝達される場合、パラメーターの受信者は、SPROPパラメーターに含まれるパラメーターセットを保存する必要があります。受け入れられているレベルのセットまたはSPROPレベルパラメーターセットと、「FMTP」ソース属性の一部として与えられたソースにそれらを関連付けます。1つのソースに関連付けられたパラメーターセットは、同じソースから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.
有益なメモ：「FMTP」ソース属性を使用したスプロップパラメーターセットとスプロップレベルパラメーターセットの搬送は、Topo-Video-Switch-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 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.
o メディア形式の構成は、レベルパーツ、パケット化モード、MSTモードを含むプロファイルレベルで識別されます。これらのメディア形式の構成パラメーター（プロファイルレベルIDのレベル部分を含む）は、対称的に使用する必要があります。つまり、回答者はすべての構成パラメーターを維持するか、メディア形式（ペイロードタイプ）を完全に削除する必要があります。これは、マルチキャストの提供/回答のプロファイルレベル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パラメーターが使用される2つの列は、回答にのみ適用されるのに対し、他の列はオファーと回答の両方に適用されることに注意してください。
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 -
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
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.
応答者は、追加のメディア形式構成でオファーを拡張する場合があります。ただし、使用を可能にするために、ほとんどの場合、メディア送信者が使用するストリームプロパティパラメーターを提供するために、オファーから2番目のオファーが必要です。これには、提供者が送信するだけでなく、このメディア形式の構成を受信できるようにする必要があるという効果もあります。
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セッション、つまり「Recvonlylylyとして宣言されたさまざまなメディアラインを提供できます。「そして、それぞれ「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 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).
MSTを使用すると、[RFC5583]で定義されているSDPのシグナリングメディアデコード依存関係に関するルールが適用されます。[RFC4566]のセクション5.7のマルチキャストを使用した「階層または階層エンコード」に関するルールは適用されません。つまり、接続データの表記「C =」は、複数のアドレスで使用されません。さらに、[rfc5583]で定義されている「a =依存」属性によって示される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.
リアルタイムストリーミングプロトコル（RTSP）[RFC2326]またはセッションアナウンスプロトコル（SAP）[RFC2974]のように、宣言スタイルでSDPを介したSVCを超えるRTPが宣言スタイルで提供される場合、次の考慮事項が必要です。
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-MODE-SPROP-DEINT-BUF-REQ-SPROP-INTERLEAVING-DEPTH-SPROP-MAX-DON-DIFF-SPROP-ISIT-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-スプロップ - Operation-Point-INFO-SPROP-NO-NAL-REORDING-REQUIRED-SPROP-AVC対応
Out-of-band transporting of parameter sets:
パラメーターセットの帯域外輸送：
- sprop-parameter-sets - sprop-level-parameter-sets
- SPROP-PARAMETER-SETS-SPROP-LEVEL-PARAMETER-SETS
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-level-max-recv-base-level-redundant-pic-cap-max-rcmd-nalu-size-deint-buf-cap-remux-buf-cap-scalable-layer-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の受信者は、提供されるパラメーターのすべてのパラメーターと値をサポートするために必要です。それ以外の場合、受信者はセッションに参加するか（SAP）拒否しなければなりません。セッションの作成者に該当し、受信アプリケーションによってサポートされると予想される値を使用します。
In the following examples, "{data}" is used to indicate a data string encoded as base64.
次の例では、「{data}」を使用して、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を提供し、2番目はH264-SVCを提供します。どちらのペイロードタイプも、プロファイルレベルID、パケット化モード、SPROPパラメーターセットなど、FMTPパラメーターが異なります。
Offerer -> Answerer SDP message:
offerer->回答者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.
AnswererがメディアサブタイプH264-SVCをサポートしていない場合、基本レイヤーのオファーのみを受け入れる回答を発行できます（ペイロードタイプ96）。次の例では、受信機はH264-SVCをサポートするため、最初にPayload Type 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};
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：Offererは、ストリームを受信および送信するために上記の例に示すのと同じメディア構成を提供しますが、単一のRTPペイロードタイプを使用してSPROP-Operation-Point-INFOを含みます。
Offerer -> Answerer SDP message:
offerer->回答者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.
スプロップオペレーションポイント-INFOを使用する代わりに、SPROPスケーラビリティINFOの使用を示す同等の例では、SPROP-OPERATION-POINT-INFOは、スプロップスケーラビリティINFOによって交換され、その後にバイナリ（base16）表現が交換されます。スケーラビリティ情報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つの異なるペイロードタイプが提供されています。他の2つのメディアは、メディアサブタイプH264-SVCを備えたペイロードタイプを使用しています。各メディアの説明では、プロファイルレベルID、パケット化モード、MSTモード、SPROPパラメーターセットの異なる値が提供されています。
Offerer -> Answerer SDP message:
offerer->回答者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セッションでは、Answererは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
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]との逆方向のペイロードタイプがあります。パラメーターセットは提供されていないことに注意してください。その場合、バンド内輸送を使用する必要があります。他のメディアの説明には、2つの拡張レイヤーが含まれており、メディアサブタイプH264-SVCを使用しています。2つの操作ポイント定義が含まれています。
Offerer -> Answerer SDP message:
offerer->回答者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）を送信して受信したいと考えられていますが、より低い拡張レイヤー、つまりレイヤーIDが2に等しいものを送信して受信したいと考えています。スケーラブルレイヤーIDを2に等しく設定することにより、目的のレイヤーの選択が含まれます。答えにはスケーラブルレイヤーID情報のみが含まれていることに注意してください。答えには、応答にsprop-parameterセットが含まれます。
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
Example 5: The offerer (Alice) offers one video description including two RTP payload types with differing levels and packetization modes.
例5：オファー（アリス）は、レベルが異なる2つのRTPペイロードタイプとパケット化モードを含む1つのビデオ説明を提供します。
Offerer -> Answerer SDP message:
offerer->回答者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.
Answerer（Bridge）はパケット化モード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
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-Base-Base-Levelを宣言しなかったため、応答エンドポイントが送信する必要があるSVCストリームの基本層は特に制約されていません。オファリングエンドポイント（アリス）は、レベル3.1でSVCストリームを送信する必要があります。この場合、ベースレイヤーはレベル1.3よりも高いレベルでなければなりません。
Section 8.4 of [RFC6184] applies in this memo, with the following applies additionally for multi-session transmission (MST).
[RFC6184]のセクション8.4はこのメモに適用され、次のものはマルチセッション伝送（MST）に追加されます。
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.
認証、整合性、または機密保護のいずれかを備えたエンドツーエンドのセキュリティは、完全なパケットを破棄する以外に、たてがみがメディアを認識している操作を実行することを妨げます。また、機密保護の場合、メディアを認識している方法でパケットの破棄を実行することさえできません。あらゆる機械がその運用を実行できるようにするには、セキュリティコンテキストの確立に含まれる信頼できるエンティティである必要があります。これは、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の規定が適用されます。セッションビットレートを削減することは、次の手段の1つ以上で可能です。
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) Aに関連付けられたすべての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.
有益なメモ：結果のSVCストリームの適合性を維持するために、ストリーム全体の特定の値よりも高いDIDに関連付けられているすべてのコード化されたスライス単位の削除が必要です。
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) Pridフィールドを利用して、NALユニットの相対的な重要性を示し、特定の値よりも高い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ユニットまたはパケット全体を削除します。結果は、使用される特定のコーディング構造と、追加のアプリケーション固有の機能（たとえば、受信デコーダーで実行される隠蔽）に依存します。一般に、これにより、不適合なビットストリームが受信されるため、デコーダーの動作は[H.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ユニットに集中しています。これは、主に、送信者がスケーラブルなビットストリームを有意義に操作できるレベルだからです。NALユニットのRTPパケットへのマッピングは、集約パケットを使用する場合、かなり柔軟です。輻輳制御アルゴリズムの性質に応じて、混雑測定（パケット数またはビットレート）の「寸法」とそれに対する反応（パケット数またはビットレート、またはその両方を減らす）は、それに応じて調整できます。
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.
その送信者が送信エンドポイントまたはミキサーベースのたてがみにあるかどうかにかかわらず、前述のすべての手段は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.
翻訳者ベースのたてがみが採用されると、たてがみはたてがみの発信経路でのみセッションを操作する可能性があり、感知されたエンドツーエンドの混雑が許容されるエンベロープ内に収まります。すべての翻訳者と同様に、この場合、たてがみは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]および[YAN]に記載されているように、さらに、または別々に、他の混雑制御メカニズムを実装することもできます。
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.
スケーラブルなビデオコーディングは、少なくともMPEG-2 [MPEG2]以来存在している概念です。これは、1993年には早くも遡ります。それでも、おそらくその中に想定されているフォームでアプリケーションが実現しなかったため、広く受け入れたことはありません。標準化。
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]の使用のこのよく理解されている形式は、すべてのレイヤーが独自のRTPパケットストリームで個別に伝達されることを意味します。。通常、IGMP [IGMP]を使用して、IPマルチキャストを購読することにより、レイヤーに「チューニング」します。アプリケーションシナリオに応じて、レイヤーのサブセット内のより細かい動作ポイントが必要ない場合、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つは、3GPP（MBMS）[MBMS]およびDVB（DVB-H）[DVB-H]によって開発されているさまざまなモバイルTVサービスのコンテンツ作成とコアネットワークディストリビューションの組み合わせです。
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標準化の範囲外です。ただし、このようなストリーミングサーバー設計が理にかなっている理由を作成することができます。考えられる引数の1つは、ストレージスペースとチャネル帯域幅に関連しています。もう1つは、トランスコーディングなしの帯域幅の適応性です。これは、混雑制御ネットワークでかなりの利点です。ストリーミングサーバーが混雑について学習すると、層状ストリームを作成するときに少ないレイヤーを選択することで、送信ビットレートを減らすことができます。セクション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]。よりシンプルなアーキテクチャは、Switching MCUで、着信ビデオストリームの1つが受信エンドポイントにリダイレクトされます。明らかに、一度に1人のユーザーのみが見られ、レートマッチングを実行できないため、すべての送信エンドポイントに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.
このシナリオはもう少し複雑で、コアネットワークのネットワークトラフィックを最適化するように設計されていますが、エンドポイントのファイアウォールには単一のピンホールのみが必要です。その重要なアプリケーションの1つは、モバイル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ネットワーク、たとえば第3世代パートナーシッププロジェクト（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スケーラブルなビットストリームを作成します。これらのミドルボックスは、この仕様全体でマネと呼ばれます。実際には、著者は、すべてのシグナルとメディアトラフィックが必然的に同じ物理リンクで多重化されるモバイルネットワークの基地局の一部である（または少なくとも物理的およびトポロジーに近い）ことを想定しています。
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.
たてがみは、必然的にかなり複雑なデバイスである必要があります。彼らは確かに信号を理解する必要があるので、たとえば、RTPヘッダーのペイロードタイプのオクテットをSVCペイロードタイプに関連付ける必要があります。
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.
たてがみは、おそらく複数のRTPセッションから複数のRTPストリームを集約することができ、したがって、エンドポイントで必要なファイアウォールピンホールの数を減らすか、発信RTPストリームを最適化することができます。このメモ。このタイプのたてがみは概念的に簡単に実装でき、主にペイロード（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.
セクション9で説明したように、輻輳制御原則を遵守するために、たてがみはストリームの薄化を実行することもできます。そのようなたてがみのフォワード（メディア）チャネルの実装は比較的単純であるように見えますが、RTCP RRを書き直す必要があるため、均等になりますそのようなたてがみは複雑なデバイスです。
While the implementation complexity of either case of a MANE, as discussed above, is fairly high, the computational demands are comparatively low.
上記で説明したように、どちらの場合でも、どちらの場合でも実装の複雑さはかなり高いですが、計算需要は比較的低いです。
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モードに大きく貢献しました。Roniは、このメモの開発のために設計チームを組織し、調整し、貴重なコメントを提供しました。Jonathan Lennoxは、MSTのNALユニットの並べ替えアルゴリズムに貢献し、このメモのいくつかの部分に入力を提供しました。ピーター・アモン、サム・ガネサン、マイク・ニルソン、コリン・パーキンス、トーマス・ウィーガンドはデザインチームのメンバーであり、貴重な貢献を提供しました。マグナス・ウェスターランドも貴重なコメントをしています。チャールズ・エッケルとスチュアート・テイラーは、この文書の最初のWGLCの後に貴重なコメントを提供しました。Xiaohui（Joanne）Weiは、表13とSDPの例の改善を支援しました。
The work of Thomas Schierl has been supported by the European Commission under contract number FP7-ICT-248036, project COAST.
Thomas Schierlの仕事は、Project Coastの契約番号FP7-ICT-248036の下で欧州委員会によって支援されています。
[H.264] ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services", March 2010.
[H.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] Wang、Y.-K。、veven、R.、Kristensen、T。、およびR. Jesup、「H.264ビデオのRTPペイロード形式」、RFC 6184、2011年5月。
[ISO/IEC14496-10] ISO/IEC International Standard 14496-10:2005.
[ISO/IEC14496-10] ISO/IEC International Standard 14496-10：2005。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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.、Frederick、R。、およびV. Jacobson、「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] Freed、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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Lennox、J.、Ott、J。、およびT. Schierl、「セッション説明プロトコル（SDP）のソース固有のメディア属性」、RFC 5576、2009年6月。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, July 2009.
[RFC5583] Schierl、T。およびS. Wenger、「セッション説明プロトコル（SDP）のシグナリングメディアデコード依存関係」、RFC 5583、2009年7月。
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
[RFC6051] Perkins、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 -Digital Video Broadcasting（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. Shapiro、「スケーラブルなビデオコーディングを使用したマルチポイントビデオ会議」、Journal of Zejiang University 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 rec。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 rec。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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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] Ohm J.-R.、Koenen、R。、およびChiariglione、L。（ed。）、「MPEG（ISO/IEC JTC1 SC29 WG11）によって指定されたSVC要件」、JVT-N026、httpから入手可能：//ftp3.itu.ch/av-arch/ jvt-site/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] Sullivan、G。およびWiegand、T。（ed。）、「VCEG（ITU-T SG16 Q.6）で指定されたSVC要件」、JVT-N027、http：//ftp3.ituから入手可能。INT/AV-ARCH/JVT-SITE/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.
[McCanne] McCanne、S.、Jacobson、V。、およびVetterli、M。、「受信機駆動型の層状マルチキャスト」、Proc。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 International Standard 13818-2：1993。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTP Topologies」、RFC 5117、2008年1月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775] Luby、M.、Watson、M。、およびL. Vicisano、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 5775、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.
[Yan] Yan、J.、Katrinis、K.、May、M。、およびPlattner、R。、「スケーラブルなビデオストリームのメディアとTCPに優しい混雑制御」、IEEE Trans。マルチメディア、196〜206ページ、2006年4月。
Authors' Addresses
著者のアドレス
Stephan Wenger 2400 Skyfarm Dr. Hillsborough, CA 94010 USA
Stephan Wenger 2400 Skyfarm Dr. Hillsborough、CA 94010 USA
Phone: +1-415-713-5473
EMail: stewe@stewe.org
Ye-Kui Wang Huawei Technologies 400 Crossing Blvd, 2nd Floor Bridgewater, NJ 08807 USA
Ye-Kui Wang Huawei Technologies 400 Crossing Blvd、2階のブリッジウォーター、ニュージャージー08807 USA
Phone: +1-908-541-3518
EMail: yekui.wang@huawei.com
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587 Berlin Germany
Thomas Schierl Fraunhofer HHI Einsteinufer 37 D-10587ベルリンドイツ
Phone: +49-30-31002-227
EMail: ts@thomas-schierl.de
Alex Eleftheriadis Vidyo, Inc. 433 Hackensack Ave. Hackensack, NJ 07601 USA
Alex Eleftheriadis Vidyo、Inc。433 Hackensack Ave. Hackensack、NJ 07601 USA
Phone: +1-201-467-5135
EMail: alex@vidyo.com