[要約] RFC 8761は、ビデオコーデックの要件と評価方法に関するガイドラインです。その目的は、ビデオコーデックの開発や評価において一貫性と透明性を提供することです。
Internet Engineering Task Force (IETF) A. Filippov
Request for Comments: 8761 Huawei Technologies
Category: Informational A. Norkin
ISSN: 2070-1721 Netflix
J.R. Alvarez
Huawei Technologies
April 2020
Video Codec Requirements and Evaluation Methodology
ビデオコーデックの要件と評価方法
Abstract
概要
This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled.
このドキュメントでは、主にインターネット経由で使用するために設計されたビデオコーデックの要件について説明します。さらに、このドキュメントでは、指定された要件が満たされているかどうかを判断するために圧縮効率を測定するための評価方法について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8761.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8761で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology Used in This Document
2.1. Definitions
2.2. Abbreviations
3. Applications
3.1. Internet Video Streaming
3.2. Internet Protocol Television (IPTV)
3.3. Video Conferencing
3.4. Video Sharing
3.5. Screencasting
3.6. Game Streaming
3.7. Video Monitoring and Surveillance
4. Requirements
4.1. General Requirements
4.1.1. Coding Efficiency
4.1.2. Profiles and Levels
4.1.3. Bitstream Syntax
4.1.4. Parsing and Identification of Sample Components
4.1.5. Perceptual Quality Tools
4.1.6. Buffer Model
4.1.7. Integration
4.2. Basic Requirements
4.2.1. Input Source Formats
4.2.2. Coding Delay
4.2.3. Complexity
4.2.4. Scalability
4.2.5. Error Resilience
4.3. Optional Requirements
4.3.1. Input Source Formats
4.3.2. Scalability
4.3.3. Complexity
4.3.4. Coding Efficiency
5. Evaluation Methodology
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
This document presents the requirements for a video codec designed mainly for use over the Internet. The requirements encompass a wide range of applications that use data transmission over the Internet, including Internet video streaming, IPTV, peer-to-peer video conferencing, video sharing, screencasting, game streaming, and video monitoring and surveillance. For each application, typical resolutions, frame rates, and picture-access modes are presented. Specific requirements related to data transmission over packet-loss networks are considered as well. In this document, when we discuss data-protection techniques, we only refer to methods designed and implemented to protect data inside the video codec since there are many existing techniques that protect generic data transmitted over networks with packet losses. From the theoretical point of view, both packet-loss and bit-error robustness can be beneficial for video codecs. In practice, packet losses are a more significant problem than bit corruption in IP networks. It is worth noting that there is an evident interdependence between the possible amount of delay and the necessity of error-robust video streams:
このドキュメントでは、主にインターネット経由で使用するために設計されたビデオコーデックの要件について説明します。要件には、インターネットビデオストリーミング、IPTV、ピアツーピアビデオ会議、ビデオ共有、スクリーンキャスティング、ゲームストリーミング、ビデオモニタリング、監視など、インターネットを介したデータ伝送を使用する幅広いアプリケーションが含まれます。各アプリケーションについて、一般的な解像度、フレームレート、および画像アクセスモードが表示されます。パケット損失ネットワークを介したデータ伝送に関連する特定の要件も考慮されます。このドキュメントでは、データ保護技術について説明するとき、ビデオコーデック内のデータを保護するために設計および実装された方法のみを参照します。これは、パケット損失を伴うネットワーク経由で送信される一般的なデータを保護する既存の技術が多いためです。理論的な観点から見ると、パケット損失とビットエラーの両方の堅牢性は、ビデオコーデックにとって有益です。実際には、パケット損失はIPネットワークのビット破損よりも重大な問題です。可能な遅延量とエラーに強いビデオストリームの必要性の間に明白な相互依存性があることは注目に値します：
* If the amount of delay is not crucial for an application, then reliable transport protocols such as TCP that retransmit undelivered packets can be used to guarantee correct decoding of transmitted data.
* 遅延の量がアプリケーションにとって重要でない場合は、未配信のパケットを再送信するTCPなどの信頼できるトランスポートプロトコルを使用して、送信されたデータの正しいデコードを保証できます。
* If the amount of delay must be kept low, then either data transmission should be error free (e.g., by using managed networks) or the compressed video stream should be error resilient.
* 遅延の量を低く抑える必要がある場合は、データ管理でエラーが発生しないようにするか（管理されたネットワークを使用するなど）、圧縮されたビデオストリームにエラー耐性を持たせる必要があります。
Thus, error resilience can be useful for delay-critical applications to provide low delay in a packet-loss environment.
したがって、エラー回復力は、遅延が重要なアプリケーションがパケット損失環境で低遅延を提供するのに役立ちます。
High dynamic range imaging A set of techniques that allows a greater dynamic range of exposures or values (i.e., a wider range of values between light and dark areas) than normal digital imaging techniques. The intention is to accurately represent the wide range of intensity levels found in examples such as exterior scenes that include light-colored items struck by direct sunlight and areas of deep shadow [7].
ハイダイナミックレンジイメージング通常のデジタルイメージングテクニックよりも広い範囲の露出または値（つまり、明るい領域と暗い領域の間の広い範囲の値）を可能にする一連のテクニック。その目的は、直射日光が当たる明るい色のアイテムや深い影のエリアを含む明るい色のアイテムを含む屋外シーンなどの例で見られる広範囲の強度レベルを正確に表すことです[7]。
Random access period The period of time between the two closest independently decodable frames (pictures).
ランダムアクセス期間2つの最も近い独立してデコード可能なフレーム（画像）の間の期間。
RD-point A point in a two-dimensional rate-distortion space where the values of bitrate and quality metric are used as x- and y-coordinates, respectively.
RDポイント2次元のレート歪み空間内のポイントで、ビットレートと品質メトリックの値がそれぞれx座標とy座標として使用されます。
Visually lossless compression A form or manner of lossy compression where the data that are lost after the file is compressed and decompressed is not detectable to the eye; the compressed data appear identical to the uncompressed data [8].
視覚的に損失のない圧縮ファイルの圧縮および解凍後に失われたデータが目に見えない、不可逆圧縮の形式または方法。圧縮データは、非圧縮データと同じように見えます[8]。
Wide color gamut A certain complete color subset (e.g., considered in ITU-R BT.2020 [1]) that supports a wider range of colors (i.e., an extended range of colors that can be generated by a specific input or output device such as a video camera, monitor, or printer and can be interpreted by a color model) than conventional color gamuts (e.g., considered in ITU-R BT.601 [17] or BT.709 [20]).
広い色域より広い範囲の色（つまり、特定の入力または出力デバイスなどで生成できる拡張された範囲の色）をサポートする特定の完全な色のサブセット（たとえば、ITU-R BT.2020 [1]で検討）ビデオカメラ、モニター、またはプリンターとして、従来の色域（たとえば、ITU-R BT.601 [17]またはBT.709 [20]で検討）よりもカラーモデルで解釈できます）。
AI All-Intra (each picture is intra-coded)
AIオールイントラ（各画像はイントラコード化されています）
BD-Rate Bjontegaard Delta Rate
BD-Rate Bjontegaard Delta Rate
FIZD just the First picture is Intra-coded, Zero structural Delay
FIZDは最初の画像だけがイントラコード化され、構造遅延がゼロ
FPS Frames per Second
1秒あたりのFPSフレーム
GOP Group of Picture
画像のGOPグループ
GPU Graphics Processing Unit
GPUグラフィックプロセッシングユニット
HBR High Bitrate Range
HBR高ビットレート範囲
HDR High Dynamic Range
HDRハイダイナミックレンジ
HRD Hypothetical Reference Decoder
HRD仮説参照デコーダー
HEVC High Efficiency Video Coding
HEVC高効率ビデオコーディング
IPTV Internet Protocol Television
IPTVインターネットプロトコルテレビ
LBR Low Bitrate Range
LBR低ビットレート範囲
MBR Medium Bitrate Range
MBR中ビットレート範囲
MOS Mean Opinion Score
MOS平均オピニオンスコア
MS-SSIM Multi-Scale Structural Similarity quality index
MS-SSIMマルチスケール構造類似性品質指数
PAM Picture Access Mode
PAM画像アクセスモード
PSNR Peak Signal-to-Noise Ratio
PSNRピーク信号対雑音比
QoS Quality of Service
QoS QoS
QP Quantization Parameter
QP量子化パラメーター
RA Random Access
ら らんどｍ あっせっｓ
RAP Random Access Period
RAPランダムアクセス期間
RD Rate-Distortion
RDレート歪み
SEI Supplemental Enhancement Information
SEI補足の拡張情報
SIMD Single Instruction, Multiple Data
Sind単一命令、複数データ
SNR Signal-to-Noise Ratio
SNR信号対ノイズ比
UGC User-Generated Content
UGCユーザー生成コンテンツ
VDI Virtual Desktop Infrastructure
VDI仮想デスクトップインフラストラクチャ
VUI Video Usability Information
FUNビデオのユーザビリティ情報
WCG Wide Color Gamut
WCG広色域
In this section, an overview of video codec applications that are currently available on the Internet market is presented. It is worth noting that there are different use cases for each application that define a target platform; hence, there are different types of communication channels involved (e.g., wired or wireless channels) that are characterized by different QoS as well as bandwidth; for instance, wired channels are considerably more free from error than wireless channels and therefore require different QoS approaches. The target platform, the channel bandwidth, and the channel quality determine resolutions, frame rates, and either quality or bitrates for video streams to be encoded or decoded. By default, color format YCbCr 4:2:0 is assumed for the application scenarios listed below.
このセクションでは、インターネット市場で現在利用可能なビデオコーデックアプリケーションの概要を示します。ターゲットプラットフォームを定義するアプリケーションごとに異なる使用例があることに注意してください。したがって、帯域幅だけでなく異なるQoSを特徴とする、さまざまなタイプの通信チャネル（たとえば、有線または無線チャネル）があります。たとえば、有線チャネルは無線チャネルよりもエラーが大幅に少ないため、さまざまなQoSアプローチが必要です。ターゲットプラットフォーム、チャネル帯域幅、およびチャネル品質によって、エンコード、デコードされるビデオストリームの解像度、フレームレート、および品質またはビットレートが決まります。下記のアプリケーションシナリオでは、デフォルトでカラーフォーマットYCbCr 4：2：0が想定されています。
Typical content for this application is movies, TV series and shows, and animation. Internet video streaming uses a variety of client devices and has to operate under changing network conditions. For this reason, an adaptive streaming model has been widely adopted. Video material is encoded at different quality levels and different resolutions, which are then chosen by a client depending on its capabilities and current network bandwidth. An example combination of resolutions and bitrates is shown in Table 1.
このアプリケーションの一般的なコンテンツは、映画、テレビシリーズと番組、アニメーションです。インターネットビデオストリーミングは、さまざまなクライアントデバイスを使用し、変化するネットワーク条件の下で動作する必要があります。このため、アダプティブストリーミングモデルが広く採用されています。ビデオ素材はさまざまな品質レベルとさまざまな解像度でエンコードされ、その機能と現在のネットワーク帯域幅に応じてクライアントによって選択されます。解像度とビットレートの組み合わせの例を表1に示します。
A video encoding pipeline in on-demand Internet video streaming typically operates as follows:
オンデマンドインターネットビデオストリーミングのビデオエンコーディングパイプラインは、通常、次のように動作します。
* Video is encoded in the cloud by software encoders.
* ビデオはソフトウェアエンコーダーによってクラウドでエンコードされます。
* Source video is split into chunks, each of which is encoded separately, in parallel.
* ソースビデオはチャンクに分割され、各チャンクは並行して別々にエンコードされます。
* Closed-GOP encoding with intrapicture intervals of 2-5 seconds (or longer) is used.
* 画像内の間隔が2〜5秒（またはそれ以上）のクローズドGOPエンコーディングが使用されます。
* Encoding is perceptually optimized. Perceptual quality is important and should be considered during the codec development.
* エンコーディングは知覚的に最適化されています。知覚品質は重要であり、コーデック開発中に考慮する必要があります。
+------------+-----+------------------------------------------------+
| Resolution | PAM | Frame Rate, FPS ** |
| * | | |
+============+=====+================================================+
| 4K, | RA | 24/1.001, 24, 25, |
| 3840x2160 | | 30/1.001, 30, 50, |
+------------+-----+ 60/1.001, 60, 100, |
| 2K | RA | 120/1.001, 120 |
| (1080p), | | |
| 1920x1080 | | |
+------------+-----+ |
| 1080i, | RA | |
| 1920x1080* | | |
+------------+-----+ |
| 720p, | RA | |
| 1280x720 | | |
+------------+-----+ |
| 576p | RA | |
| (EDTV), | | |
| 720x576 | | |
+------------+-----+ |
| 576i | RA | |
| (SDTV), | | |
| 720x576* | | |
+------------+-----+ |
| 480p | RA | |
| (EDTV), | | |
| 720x480 | | |
+------------+-----+ |
| 480i | RA | |
| (SDTV), | | |
| 720x480* | | |
+------------+-----+ |
| 512x384 | RA | |
+------------+-----+ |
| QVGA, | RA | |
| 320x240 | | |
+------------+-----+------------------------------------------------+
Table 1: Internet Video Streaming: Typical Values of Resolutions, Frame Rates, and PAMs
表1：インターネットビデオストリーミング：解像度、フレームレート、およびPAMの一般的な値
*Note: Interlaced content can be handled at the higher system level and not necessarily by using specialized video coding tools. It is included in this table only for the sake of completeness, as most video content today is in the progressive format.
*注意：インターレースされたコンテンツはより高いシステムレベルで処理できますが、専用のビデオコーディングツールを使用する必要はありません。今日のほとんどのビデオコンテンツはプログレッシブ形式であるため、完全を期すためにこの表に含まれています。
**Note: The set of frame rates presented in this table is taken from Table 2 in [1].
**注：この表に示されているフレームレートのセットは、[1]の表2から取得されています。
The characteristics and requirements of this application scenario are as follows:
このアプリケーションシナリオの特性と要件は次のとおりです。
* High encoder complexity (up to 10x and more) can be tolerated since encoding happens once and in parallel for different segments.
* 異なるセグメントに対してエンコードが一度かつ並行して行われるため、エンコーダーの複雑度が高い（最大10倍以上）場合は許容できます。
* Decoding complexity should be kept at reasonable levels to enable efficient decoder implementation.
* 効率的なデコーダーの実装を可能にするには、デコードの複雑さを合理的なレベルに保つ必要があります。
* Support and efficient encoding of a wide range of content types and formats is required:
* 幅広いコンテンツタイプとフォーマットのサポートと効率的なエンコーディングが必要です。
- High Dynamic Range (HDR), Wide Color Gamut (WCG), high-resolution (currently, up to 4K), and high-frame-rate content are important use cases; the codec should be able to encode such content efficiently.
- ハイダイナミックレンジ（HDR）、広色域（WCG）、高解像度（現在、最大4K）、および高フレームレートのコンテンツは、重要な使用例です。コーデックは、そのようなコンテンツを効率的にエンコードできる必要があります。
- Improvement of coding efficiency at both lower and higher resolutions is important since low resolutions are used when streaming in low-bandwidth conditions.
- 低帯域幅条件でストリーミングする場合は低解像度を使用するため、低解像度と高解像度の両方でコーディング効率を向上させることが重要です。
- Improvement on both "easy" and "difficult" content in terms of compression efficiency at the same quality level contributes to the overall bitrate/storage savings.
- 同じ品質レベルでの圧縮効率の観点から、「簡単」および「難しい」コンテンツの両方を改善すると、全体的なビットレート/ストレージの節約に貢献します。
- Film grain (and sometimes other types of noise) is often present in movies and similar content; this is usually part of the creative intent.
- フィルムグレイン（場合によっては他の種類のノイズ）は、映画や同様のコンテンツによく見られます。これは通常、クリエイティブインテントの一部です。
* Significant improvements in compression efficiency between generations of video standards are desirable since this scenario typically assumes long-term support of legacy video codecs.
* このシナリオは通常、レガシービデオコーデックの長期サポートを想定しているため、ビデオ標準の世代間の圧縮効率の大幅な改善が望まれます。
* Random access points are inserted frequently (one per 2-5 seconds) to enable switching between resolutions and fast-forward playback.
* ランダムアクセスポイントが頻繁に挿入され（2〜5秒に1つ）、解像度と早送り再生を切り替えることができます。
* The elementary stream should have a model that allows easy parsing and identification of the sample components.
* エレメンタリーストリームには、サンプルコンポーネントの簡単な解析と識別を可能にするモデルが必要です。
* Middle QP values are normally used in streaming; this is also the range where compression efficiency is important for this scenario.
* 中間のQP値は通常、ストリーミングで使用されます。これは、このシナリオで圧縮効率が重要な範囲でもあります。
* Scalability or other forms of supporting multiple quality representations are beneficial if they do not incur significant bitrate overhead and if mandated in the first version.
* 複数の品質表現をサポートするスケーラビリティやその他の形式は、ビットレートのオーバーヘッドが大幅に発生しない場合、および最初のバージョンで義務付けられている場合に有益です。
This is a service for delivering television content over IP-based networks. IPTV may be classified into two main groups based on the type of delivery, as follows:
IPベースのネットワークでテレビコンテンツを配信するサービスです。 IPTVは、配信のタイプに基づいて、次の2つの主要なグループに分類できます。
* unicast (e.g., for video on demand), where delay is not crucial; and
* ユニキャスト（ビデオオンデマンドなど）。遅延は重要ではありません。そして
* multicast/broadcast (e.g., for transmitting news) where zapping (i.e., stream changing) delay is important.
* ザッピング（ストリームの変更など）の遅延が重要なマルチキャスト/ブロードキャスト（ニュースの送信など）。
In the IPTV scenario, traffic is transmitted over managed (QoS-based) networks. Typical content used in this application is news, movies, cartoons, series, TV shows, etc. One important requirement for both groups is that random access to pictures (i.e., the random access period (RAP)) should be kept small enough (approximately 1-5 seconds). Optional requirements are as follows:
IPTVシナリオでは、トラフィックは管理された（QoSベースの）ネットワークを介して送信されます。このアプリケーションで使用される一般的なコンテンツは、ニュース、映画、漫画、シリーズ、テレビ番組などです。両方のグループの1つの重要な要件は、画像へのランダムアクセス（つまり、ランダムアクセス期間（RAP））を十分に小さく保つことです（およそ） 1〜5秒）。オプションの要件は次のとおりです。
* Temporal (frame-rate) scalability; and
* 時間的（フレームレート）スケーラビリティ。そして
* Resolution and quality (SNR) scalability.
* 解像度と品質（SNR）のスケーラビリティ。
For this application, typical values of resolutions, frame rates, and PAMs are presented in Table 2.
このアプリケーションの場合、解像度、フレームレート、およびPAMの一般的な値を表2に示します。
+------------+-----+------------------------------------------------+
| Resolution | PAM | Frame Rate, FPS ** |
| * | | |
+============+=====+================================================+
| 2160p | RA | 24/1.001, 24, 25, |
| (4K), | | 30/1.001, 30, 50, |
| 3840x2160 | | 60/1.001, 60, 100, |
+------------+-----+ 120/1.001, 120 |
| 1080p, | RA | |
| 1920x1080 | | |
+------------+-----+ |
| 1080i, | RA | |
| 1920x1080* | | |
+------------+-----+ |
| 720p, | RA | |
| 1280x720 | | |
+------------+-----+ |
| 576p | RA | |
| (EDTV), | | |
| 720x576 | | |
+------------+-----+ |
| 576i | RA | |
| (SDTV), | | |
| 720x576* | | |
+------------+-----+ |
| 480p | RA | |
| (EDTV), | | |
| 720x480 | | |
+------------+-----+ |
| 480i | RA | |
| (SDTV), | | |
| 720x480* | | |
+------------+-----+------------------------------------------------+
Table 2: IPTV: Typical Values of Resolutions, Frame Rates, and PAMs
表2：IPTV：解像度、フレームレート、およびPAMの一般的な値
*Note: Interlaced content can be handled at the higher system level and not necessarily by using specialized video coding tools. It is included in this table only for the sake of completeness, as most video content today is in a progressive format.
*注意：インターレースされたコンテンツはより高いシステムレベルで処理できますが、専用のビデオコーディングツールを使用する必要はありません。今日のほとんどのビデオコンテンツはプログレッシブ形式であるため、完全を期すためにこの表に含まれています。
**Note: The set of frame rates presented in this table is taken from Table 2 in [1].
**注：この表に示されているフレームレートのセットは、[1]の表2から取得されています。
This is a form of video connection over the Internet. This form allows users to establish connections to two or more people by two-way video and audio transmission for communication in real time. For this application, both stationary and mobile devices can be used. The main requirements are as follows:
これは、インターネットを介したビデオ接続の一種です。このフォームを使用すると、ユーザーは、双方向のビデオとオーディオの伝送によって2人以上の人との接続を確立し、リアルタイムで通信できます。このアプリケーションでは、据え置き型デバイスとモバイルデバイスの両方を使用できます。主な要件は次のとおりです。
* Delay should be kept as low as possible (the preferable and maximum end-to-end delay values should be less than 100 ms [9] and 320 ms [2], respectively);
* 遅延は可能な限り低く保つ必要があります（望ましいエンドツーエンドの最大遅延値は、それぞれ100ミリ秒[9]および320ミリ秒[2]未満である必要があります）。
* Temporal (frame-rate) scalability; and
* 時間的（フレームレート）スケーラビリティ。そして
* Error robustness.
* エラーの堅牢性。
Support of resolution and quality (SNR) scalability is highly desirable. For this application, typical values of resolutions, frame rates, and PAMs are presented in Table 3.
解像度と品質（SNR）のスケーラビリティのサポートが強く望まれます。このアプリケーションの場合、解像度、フレームレート、PAMの一般的な値を表3に示します。
+------------------+-----------------+------+
| Resolution | Frame Rate, FPS | PAM |
+==================+=================+======+
| 1080p, 1920x1080 | 15, 30 | FIZD |
+------------------+-----------------+------+
| 720p, 1280x720 | 30, 60 | FIZD |
+------------------+-----------------+------+
| 4CIF, 704x576 | 30, 60 | FIZD |
+------------------+-----------------+------+
| 4SIF, 704x480 | 30, 60 | FIZD |
+------------------+-----------------+------+
| VGA, 640x480 | 30, 60 | FIZD |
+------------------+-----------------+------+
| 360p, 640x360 | 30, 60 | FIZD |
+------------------+-----------------+------+
Table 3: Video Conferencing: Typical Values of Resolutions, Frame Rates, and PAMs
表3：ビデオ会議：解像度、フレームレート、およびPAMの一般的な値
This is a service that allows people to upload and share video data (using live streaming or not) and watch those videos. It is also known as video hosting. A typical User-Generated Content (UGC) scenario for this application is to capture video using mobile cameras such as GoPros or cameras integrated into smartphones (amateur video). The main requirements are as follows:
これは、ビデオデータをアップロードして共有し（ライブストリーミングを使用しているかどうかに関係なく）、それらのビデオを視聴できるサービスです。ビデオホスティングとしても知られています。このアプリケーションの一般的なユーザー生成コンテンツ（UGC）シナリオは、GoProなどのモバイルカメラやスマートフォンに統合されたカメラ（アマチュアビデオ）を使用してビデオをキャプチャすることです。主な要件は次のとおりです。
* Random access to pictures for downloaded video data;
* ダウンロードしたビデオデータの写真へのランダムアクセス。
* Temporal (frame-rate) scalability; and
* 時間的（フレームレート）スケーラビリティ。そして
* Error robustness.
* エラーの堅牢性。
Support of resolution and quality (SNR) scalability is highly desirable. For this application, typical values of resolutions, frame rates, and PAMs are presented in Table 4.
解像度と品質（SNR）のスケーラビリティのサポートが強く望まれます。このアプリケーションの場合、解像度、フレームレート、およびPAMの一般的な値を表4に示します。
Typical values of resolutions and frame rates in Table 4 are taken from [10].
表4の解像度とフレームレートの一般的な値は、[10]から取得されます。
+-----------------------+------------------------+-----+
| Resolution | Frame Rate, FPS | PAM |
+=======================+========================+=====+
| 2160p (4K), 3840x2160 | 24, 25, 30, 48, 50, 60 | RA |
+-----------------------+------------------------+-----+
| 1440p (2K), 2560x1440 | 24, 25, 30, 48, 50, 60 | RA |
+-----------------------+------------------------+-----+
| 1080p, 1920x1080 | 24, 25, 30, 48, 50, 60 | RA |
+-----------------------+------------------------+-----+
| 720p, 1280x720 | 24, 25, 30, 48, 50, 60 | RA |
+-----------------------+------------------------+-----+
| 480p, 854x480 | 24, 25, 30, 48, 50, 60 | RA |
+-----------------------+------------------------+-----+
| 360p, 640x360 | 24, 25, 30, 48, 50, 60 | RA |
+-----------------------+------------------------+-----+
Table 4: Video Sharing: Typical Values of Resolutions, Frame Rates, and PAMs
表4：ビデオ共有：解像度、フレームレート、およびPAMの一般的な値
This is a service that allows users to record and distribute video data from a computer screen. This service requires efficient compression of computer-generated content with high visual quality up to visually and mathematically (numerically) lossless [11]. Currently, this application includes business presentations (PowerPoint, Word documents, email messages, etc.), animation (cartoons), gaming content, and data visualization. This type of content is characterized by fast motion, rotation, smooth shade, 3D effect, highly saturated colors with full resolution, clear textures and sharp edges with distinct colors [11], virtual desktop infrastructure (VDI), screen/desktop sharing and collaboration, supervisory control and data acquisition (SCADA) display, automotive/ navigation display, cloud gaming, factory automation display, wireless display, display wall, digital operating room (DiOR), etc. For this application, an important requirement is the support of low-delay configurations with zero structural delay for a wide range of video formats (e.g., RGB) in addition to YCbCr 4:2:0 and YCbCr 4:4:4 [11]. For this application, typical values of resolutions, frame rates, and PAMs are presented in Table 5.
パソコンの画面から動画データを記録・配信できるサービスです。このサービスは、視覚的および数学的に（数値的に）ロスレス[11]までの高品質のコンピューター生成コンテンツの効率的な圧縮を必要とします。現在、このアプリケーションには、ビジネスプレゼンテーション（PowerPoint、Wordドキュメント、電子メールメッセージなど）、アニメーション（漫画）、ゲームコンテンツ、およびデータの視覚化が含まれています。このタイプのコンテンツは、高速モーション、回転、スムーズシェード、3D効果、フル解像度の非常に彩度の高い色、明確なテクスチャと明確な色の鋭いエッジ[11]、仮想デスクトップインフラストラクチャ（VDI）、画面/デスクトップ共有とコラボレーションが特徴です、監視制御およびデータ収集（SCADA）ディスプレイ、自動車/ナビゲーションディスプレイ、クラウドゲーム、ファクトリオートメーションディスプレイ、ワイヤレスディスプレイ、ディスプレイウォール、デジタル手術室（DiOR）など。このアプリケーションでは、重要な要件は低-YCbCr 4：2：0およびYCbCr 4：4：4 [11]に加えて、幅広いビデオ形式（RGBなど）の構造的遅延がゼロの遅延構成。このアプリケーションの場合、解像度、フレームレート、およびPAMの一般的な値を表5に示します。
+-----------------------+-----------------+--------------+
| Resolution | Frame Rate, FPS | PAM |
+=======================+=================+==============+
| Input color format: RGB 4:4:4 |
+-----------------------+-----------------+--------------+
| 5k, 5120x2880 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| 4k, 3840x2160 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| WQXGA, 2560x1600 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| WUXGA, 1920x1200 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| WSXGA+, 1680x1050 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| WXGA, 1280x800 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| XGA, 1024x768 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| SVGA, 800x600 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| VGA, 640x480 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| Input color format: YCbCr 4:4:4 |
+-----------------------+-----------------+--------------+
| 5k, 5120x2880 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| 4k, 3840x2160 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| 1440p (2K), 2560x1440 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| 1080p, 1920x1080 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
| 720p, 1280x720 | 15, 30, 60 | AI, RA, FIZD |
+-----------------------+-----------------+--------------+
Table 5: Screencasting for RGB and YCbCr 4:4:4 Format:
Typical Values of Resolutions, Frame Rates, and PAMs
This is a service that provides game content over the Internet to different local devices such as notebooks and gaming tablets. In this category of applications, the server renders 3D games in a cloud server and streams the game to any device with a wired or wireless broadband connection [12]. There are low-latency requirements for transmitting user interactions and receiving game data with a turnaround delay of less than 100 ms. This allows anyone to play (or resume) full-featured games from anywhere on the Internet [12]. An example of this application is Nvidia Grid [12]. Another application scenario of this category is broadcast of video games played by people over the Internet in real time or for later viewing [12]. There are many companies, such as Twitch and YY in China, that enable game broadcasting [12]. Games typically contain a lot of sharp edges and large motion [12]. The main requirements are as follows:
これは、ノートブックやゲームタブレットなどのさまざまなローカルデバイスにインターネット経由でゲームコンテンツを提供するサービスです。このカテゴリのアプリケーションでは、サーバーはクラウドサーバーで3Dゲームをレンダリングし、有線またはワイヤレスのブロードバンド接続を備えた任意のデバイスにゲームをストリーミングします[12]。 100ミリ秒未満のターンアラウンド遅延でユーザーインタラクションを送信し、ゲームデータを受信するための低遅延要件があります。これにより、誰でもインターネット上のどこからでもフル機能のゲームをプレイ（または再開）することができます[12]。このアプリケーションの例は、Nvidia Grid [12]です。このカテゴリの別のアプリケーションシナリオは、インターネット上でリアルタイムまたは後で視聴するために人々がプレイするビデオゲームのブロードキャストです[12]。中国では、TwitchやYYなど、ゲームの放送を可能にする多くの企業があります[12]。ゲームには通常、鋭いエッジと大きなモーションが多く含まれています[12]。主な要件は次のとおりです。
* Random access to pictures for game broadcasting;
* ゲーム放送用の写真へのランダムアクセス。
* Temporal (frame-rate) scalability; and
* 時間的（フレームレート）スケーラビリティ。そして
* Error robustness.
* エラーの堅牢性。
Support of resolution and quality (SNR) scalability is highly desirable. For this application, typical values of resolutions, frame rates, and PAMs are similar to ones presented in Table 3.
解像度と品質（SNR）のスケーラビリティのサポートが強く望まれます。このアプリケーションの場合、解像度、フレームレート、およびPAMの一般的な値は、表3に示すものと同様です。
This is a type of live broadcasting over IP-based networks. Video streams are sent to many receivers at the same time. A new receiver may connect to the stream at an arbitrary moment, so the random access period should be kept small enough (approximately, 1-5 seconds). Data are transmitted publicly in the case of video monitoring and privately in the case of video surveillance. For IP cameras that have to capture, process, and encode video data, complexity -- including computational and hardware complexity, as well as memory bandwidth -- should be kept low to allow real-time processing. In addition, support of a high dynamic range and a monochrome mode (e.g., for infrared cameras) as well as resolution and quality (SNR) scalability is an essential requirement for video surveillance. In some use cases, high video signal fidelity is required even after lossy compression. Typical values of resolutions, frame rates, and PAMs for video monitoring and surveillance applications are presented in Table 6.
これは、IPベースのネットワークを介したライブブロードキャストの一種です。ビデオストリームは同時に多くのレシーバーに送信されます。新しいレシーバーは任意のタイミングでストリームに接続する可能性があるため、ランダムアクセス期間は十分に小さく（約1〜5秒）保つ必要があります。データはビデオ監視の場合は公に送信され、ビデオ監視の場合は私的に送信されます。ビデオデータをキャプチャ、処理、およびエンコードする必要があるIPカメラの場合、リアルタイム処理を可能にするために、計算およびハードウェアの複雑さを含む複雑さ、ならびにメモリ帯域幅を低く保つ必要があります。さらに、高ダイナミックレンジとモノクロモード（赤外線カメラなど）のサポート、および解像度と品質（SNR）のスケーラビリティのサポートは、ビデオ監視の必須要件です。一部の使用例では、非可逆圧縮後でも高いビデオ信号忠実度が必要です。ビデオモニタリングおよび監視アプリケーションの解像度、フレームレート、およびPAMの一般的な値を表6に示します。
+-----------------------+-----------------+----------+
| Resolution | Frame Rate, FPS | PAM |
+=======================+=================+==========+
| 2160p (4K), 3840x2160 | 12, 25, 30 | RA, FIZD |
+-----------------------+-----------------+----------+
| 5Mpixels, 2560x1920 | 12, 25, 30 | RA, FIZD |
+-----------------------+-----------------+----------+
| 1080p, 1920x1080 | 25, 30 | RA, FIZD |
+-----------------------+-----------------+----------+
| 1.23Mpixels, 1280x960 | 25, 30 | RA, FIZD |
+-----------------------+-----------------+----------+
| 720p, 1280x720 | 25, 30 | RA, FIZD |
+-----------------------+-----------------+----------+
| SVGA, 800x600 | 25, 30 | RA, FIZD |
+-----------------------+-----------------+----------+
Table 6: Video Monitoring and Surveillance: Typical Values of Resolutions, Frame Rates, and PAMs
表6：ビデオの監視と監視：解像度、フレームレート、およびPAMの標準的な値
Taking the requirements discussed above for specific video applications, this section proposes requirements for an Internet video codec.
上記の特定のビデオアプリケーションの要件を踏まえて、このセクションではインターネットビデオコーデックの要件を提案します。
The most fundamental requirement is coding efficiency, i.e., compression performance on both "easy" and "difficult" content for applications and use cases in Section 3. The codec should provide higher coding efficiency over state-of-the-art video codecs such as HEVC/H.265 and VP9, at least 25%, in accordance with the methodology described in Section 5 of this document. For higher resolutions, the improvements in coding efficiency are expected to be higher than for lower resolutions.
最も基本的な要件は、コーディング効率です。つまり、セクション3のアプリケーションとユースケースの「簡単な」コンテンツと「難しい」コンテンツの両方での圧縮パフォーマンスです。コーデックは、次のような最新のビデオコーデックよりも高いコーディング効率を提供する必要があります。このドキュメントのセクション5で説明されている方法論に従って、少なくとも25％のHEVC / H.265およびVP9。高解像度の場合、コーディング効率の向上は、低解像度の場合よりも高くなると予想されます。
Good-quality specification and well-defined profiles and levels are required to enable device interoperability and facilitate decoder implementations. A profile consists of a subset of entire bitstream syntax elements; consequently, it also defines the necessary tools for decoding a conforming bitstream of that profile. A level imposes a set of numerical limits to the values of some syntax elements. An example of codec levels to be supported is presented in Table 7. An actual level definition should include constraints on features that impact the decoder complexity. For example, these features might be as follows: maximum bitrate, line buffer size, memory usage, etc.
デバイスの相互運用性を実現し、デコーダーの実装を容易にするには、高品質の仕様と明確に定義されたプロファイルおよびレベルが必要です。プロファイルは、ビットストリーム構文要素全体のサブセットで構成されています。したがって、そのプロファイルの適合ビットストリームをデコードするために必要なツールも定義します。レベルは、いくつかの構文要素の値に一連の数値制限を課します。サポートされるコーデックレベルの例を表7に示します。実際のレベル定義には、デコーダーの複雑さに影響を与える機能の制約を含める必要があります。たとえば、これらの機能は次のとおりです。最大ビットレート、ラインバッファーサイズ、メモリ使用量など。
+-------+-----------------------------------------------------------+
| Level | Example picture resolution at highest frame rate |
+=======+===========================================================+
| 1 | 128x96(12,288*)@30.0 |
| | 176x144(25,344*)@15.0 |
+-------+-----------------------------------------------------------+
| 2 | 352x288(101,376*)@30.0 |
+-------+-----------------------------------------------------------+
| 3 | 352x288(101,376*)@60.0 |
| | 640x360(230,400*)@30.0 |
+-------+-----------------------------------------------------------+
| 4 | 640x360(230,400*)@60.0 |
| | 960x540(518,400*)@30.0 |
+-------+-----------------------------------------------------------+
| 5 | 720x576(414,720*)@75.0 |
| | 960x540(518,400*)@60.0 |
| | 1280x720(921,600*)@30.0 |
+-------+-----------------------------------------------------------+
| 6 | 1,280x720(921,600*)@68.0 |
| | 2,048x1,080(2,211,840*)@30.0 |
+-------+-----------------------------------------------------------+
| 7 | 1,280x720(921,600*)@120.0 |
+-------+-----------------------------------------------------------+
| 8 | 1,920x1,080(2,073,600*)@120.0 |
| | 3,840x2,160(8,294,400*)@30.0 |
| | 4,096x2,160(8,847,360*)@30.0 |
+-------+-----------------------------------------------------------+
| 9 | 1,920x1,080(2,073,600*)@250.0 |
| | 4,096x2,160(8,847,360*)@60.0 |
+-------+-----------------------------------------------------------+
| 10 | 1,920x1,080(2,073,600*)@300.0 |
| | 4,096x2,160(8,847,360*)@120.0 |
+-------+-----------------------------------------------------------+
| 11 | 3,840x2,160(8,294,400*)@120.0 |
| | 8,192x4,320(35,389,440*)@30.0 |
+-------+-----------------------------------------------------------+
| 12 | 3,840x2,160(8,294,400*)@250.0 |
| | 8,192x4,320(35,389,440*)@60.0 |
+-------+-----------------------------------------------------------+
| 13 | 3,840x2,160(8,294,400*)@300.0 |
| | 8,192x4,320(35,389,440*)@120.0 |
+-------+-----------------------------------------------------------+
Table 7: Codec Levels
表7：コーデックレベル
*Note: The quantities of pixels are presented for applications in which a picture can have an arbitrary size (e.g., screencasting).
*注：ピクセル数は、画像が任意のサイズにできるアプリケーション（スクリーンキャストなど）の場合に表示されます。
Bitstream syntax should allow extensibility and backward compatibility. New features can be supported easily by using metadata (such as SEI messages, VUI, and headers) without affecting the bitstream compatibility with legacy decoders. A newer version of the decoder shall be able to play bitstreams of an older version of the same or lower profile and level.
ビットストリーム構文は、拡張性と下位互換性を可能にする必要があります。新しい機能は、レガシーデコーダーとのビットストリームの互換性に影響を与えることなく、メタデータ（SEIメッセージ、VUI、ヘッダーなど）を使用して簡単にサポートできます。デコーダの新しいバージョンは、同じまたはより低いプロファイルとレベルの古いバージョンのビットストリームを再生できる必要があります。
A bitstream should have a model that allows easy parsing and identification of the sample components (such as Annex B of ISO/IEC 14496-10 [18] or ISO/IEC 14496-15 [19]). In particular, information needed for packet handling (e.g., frame type) should not require parsing anything below the header level.
ビットストリームには、サンプルコンポーネントの簡単な解析と識別を可能にするモデル（ISO / IEC 14496-10 [18]またはISO / IEC 14496-15 [19]のAnnex Bなど）が必要です。特に、パケット処理に必要な情報（フレームタイプなど）では、ヘッダーレベル以下の解析は必要ありません。
Perceptual quality tools (such as adaptive QP and quantization matrices) should be supported by the codec bitstream.
知覚品質ツール（適応QPや量子化行列など）は、コーデックビットストリームでサポートされている必要があります。
The codec specification shall define a buffer model such as hypothetical reference decoder (HRD).
コーデック仕様は、仮想参照デコーダー（HRD）などのバッファーモデルを定義します。
Specifications providing integration with system and delivery layers should be developed.
システムと配信層との統合を提供する仕様を開発する必要があります。
Input pictures coded by a video codec should have one of the following formats:
ビデオコーデックでコーディングされた入力画像は、次のいずれかの形式である必要があります。
* Bit depth: 8 and 10 bits (up to 12 bits for a high profile) per color component.
* ビット深度：カラーコンポーネントごとに8および10ビット（ハイプロファイルの場合は最大12ビット）。
* Color sampling formats:
* カラーサンプリング形式：
- YCbCr 4:2:0
- YCbCr 4：2：0
- YCbCr 4:4:4, YCbCr 4:2:2, and YCbCr 4:0:0 (preferably in different profile(s))
- YCbCr 4：4：4、YCbCr 4：2：2、およびYCbCr 4：0：0（できれば異なるプロファイル）
* For profiles with bit depth of 10 bits per sample or higher, support of high dynamic range and wide color gamut.
* サンプルあたり10ビット以上のビット深度を持つプロファイルの場合、高ダイナミックレンジと広い色域のサポート。
* Support of arbitrary resolution according to the level constraints for applications in which a picture can have an arbitrary size (e.g., in screencasting).
* 画像が任意のサイズになり得るアプリケーション（スクリーンキャストなど）のレベルの制約に応じた任意の解像度のサポート。
Exemplary input source formats for codec profiles are shown in Table 8.
コーデックプロファイルの入力ソース形式の例を表8に示します。
+---------+--------------------------------+------------------------+
| Profile | Bit depths per color component | Color sampling |
| | | formats |
+=========+================================+========================+
| 1 | 8 and 10 | 4:0:0 and 4:2:0 |
+---------+--------------------------------+------------------------+
| 2 | 8 and 10 | 4:0:0, 4:2:0, |
| | | and 4:4:4 |
+---------+--------------------------------+------------------------+
| 3 | 8, 10, and 12 | 4:0:0, 4:2:0, |
| | | 4:2:2, and 4:4:4 |
+---------+--------------------------------+------------------------+
Table 8: Exemplary Input Source Formats for Codec Profiles
表8：コーデックプロファイルの入力ソース形式の例
In order to meet coding delay requirements, a video codec should support all of the following:
コーディング遅延要件を満たすために、ビデオコーデックは次のすべてをサポートする必要があります。
* Support of configurations with zero structural delay, also referred to as "low-delay" configurations.
* 「低遅延」構成とも呼ばれる、構造遅延ゼロの構成のサポート。
- Note: End-to-end delay should be no more than 320 ms [2], but it is preferable for its value to be less than 100 ms [9].
- 注：エンドツーエンドの遅延は320ミリ秒以下である必要がありますが[2]、その値は100ミリ秒未満であることが望ましいです[9]。
* Support of efficient random access point encoding (such as intracoding and resetting of context variables), as well as efficient switching between multiple quality representations.
* 効率的なランダムアクセスポイントエンコーディング（コンテキスト変数のイントラコーディングやリセットなど）のサポート、および複数の品質表現間の効率的な切り替え。
* Support of configurations with nonzero structural delay (such as out-of-order or multipass encoding) for applications without low-delay requirements, if such configurations provide additional compression efficiency improvements.
* 低遅延要件のないアプリケーションでの非ゼロの構造遅延（順序外れやマルチパスエンコーディングなど）の構成のサポート（圧縮構成でさらに圧縮効率が向上する場合）。
Encoding and decoding complexity considerations are as follows:
エンコードとデコードの複雑さに関する考慮事項は次のとおりです。
* Feasible real-time implementation of both an encoder and a decoder supporting a chosen subset of tools for hardware and software implementation on a wide range of state-of-the-art platforms. The subset of real-time encoder tools should provide meaningful improvement in compression efficiency at reasonable complexity of hardware and software encoder implementations as compared to real-time implementations of state-of-the-art video compression technologies such as HEVC/H.265 and VP9.
* 幅広い最先端のプラットフォームでハードウェアとソフトウェアを実装するために選択されたツールのサブセットをサポートするエンコーダーとデコーダーの両方の実現可能なリアルタイム実装。リアルタイムエンコーダーツールのサブセットは、HEVC / H.265などの最新のビデオ圧縮技術のリアルタイム実装と比較して、ハードウェアおよびソフトウェアのエンコーダー実装の合理的な複雑さで、圧縮効率を大幅に改善する必要があります。 VP9。
* High-complexity software encoder implementations used by offline encoding applications can have a 10x or more complexity increase compared to state-of-the-art video compression technologies such as HEVC/H.265 and VP9.
* オフラインエンコーディングアプリケーションで使用される複雑度の高いソフトウェアエンコーダーの実装では、HEVC / H.265やVP9などの最新のビデオ圧縮テクノロジーと比較して、10倍以上の複雑さの増加が見られます。
The mandatory scalability requirement is as follows:
必須のスケーラビリティ要件は次のとおりです。
* Temporal (frame-rate) scalability should be supported.
* 時間的（フレームレート）スケーラビリティがサポートされている必要があります。
In order to meet the error resilience requirement, a video codec should satisfy all of the following conditions:
エラー耐性の要件を満たすために、ビデオコーデックは次のすべての条件を満たす必要があります。
* Tools that are complementary to the error-protection mechanisms implemented on the transport level should be supported.
* トランスポートレベルで実装されたエラー保護メカニズムを補完するツールをサポートする必要があります。
* The codec should support mechanisms that facilitate packetization of a bitstream for common network protocols.
* コーデックは、一般的なネットワークプロトコルのビットストリームのパケット化を容易にするメカニズムをサポートする必要があります。
* Packetization mechanisms should enable frame-level error recovery by means of retransmission or error concealment.
* パケット化メカニズムは、再送信またはエラー隠蔽によってフレームレベルのエラー回復を可能にする必要があります。
* The codec should support effective mechanisms for allowing decoding and reconstruction of significant parts of pictures in the event that parts of the picture data are lost in transmission.
* コーデックは、画像データの一部が送信中に失われた場合に、画像の重要な部分のデコードと再構成を可能にする効果的なメカニズムをサポートする必要があります。
* The bitstream specification shall support independently decodable subframe units similar to slices or independent tiles. It shall be possible for the encoder to restrict the bitstream to allow parsing of the bitstream after a packet loss and to communicate it to the decoder.
* ビットストリーム仕様は、スライスまたは独立したタイルと同様に、独立してデコード可能なサブフレームユニットをサポートします。エンコーダーがビットストリームを制限して、パケット損失後のビットストリームの解析を可能にし、それをデコーダーに通信することが可能です。
It is a desired but not mandatory requirement for a video codec to support some of the following features:
ビデオコーデックが次の機能のいくつかをサポートすることは望ましいことですが、必須ではありません。
* Bit depth: up to 16 bits per color component.
* ビット深度：カラーコンポーネントあたり最大16ビット。
* Color sampling formats: RGB 4:4:4.
* カラーサンプリング形式：RGB 4：4：4。
* Auxiliary channel (e.g., alpha channel) support.
* 補助チャネル（アルファチャネルなど）のサポート。
Desirable scalability requirements are as follows:
望ましいスケーラビリティ要件は次のとおりです。
* Resolution and quality (SNR) scalability that provides a low-compression efficiency penalty (increase of up to 5% of BD-rate [13] per layer with reasonable increase of both computational and hardware complexity) can be supported in the main profile of the codec being developed by the NETVC Working Group. Otherwise, a separate profile is needed to support these types of scalability.
* 低圧縮効率のペナルティを提供する解像度と品質（SNR）のスケーラビリティー（計算とハードウェアの両方の複雑さの合理的な増加によるレイヤーごとのBDレート[13]の最大5％の増加）は、メインプロファイルでサポートできます。 NETVCワーキンググループによって開発されているコーデック。それ以外の場合、これらのタイプのスケーラビリティをサポートするには、別のプロファイルが必要です。
* Computational complexity scalability (i.e., computational complexity is decreasing along with degrading picture quality) is desirable.
* 計算の複雑さのスケーラビリティー（つまり、計算の複雑さが画像品質の低下に伴って減少している）が望ましい。
Tools that enable parallel processing (e.g., slices, tiles, and wave-front propagation processing) at both encoder and decoder sides are highly desirable for many applications.
エンコーダー側とデコーダー側の両方で並列処理（スライス、タイル、波面伝播処理など）を可能にするツールは、多くのアプリケーションにとって非常に望ましいものです。
* High-level multicore parallelism: encoder and decoder operation, especially entropy encoding and decoding, should allow multiple frames or subframe regions (e.g., 1D slices, 2D tiles, or partitions) to be processed concurrently, either independently or with deterministic dependencies that can be efficiently pipelined.
* 高レベルのマルチコア並列処理：エンコーダーとデコーダーの操作、特にエントロピーエンコーディングとデコーディングでは、複数のフレームまたはサブフレーム領域（たとえば、1Dスライス、2Dタイル、またはパーティション）を、独立してまたは決定論的な依存関係で同時に処理できるようにする必要があります効率的にパイプライン化。
* Low-level instruction-set parallelism: favor algorithms that are SIMD/GPU friendly over inherently serial algorithms
* 低レベルの命令セット並列処理：本質的にシリアルなアルゴリズムよりもSIMD / GPUフレンドリーなアルゴリズムを優先
Compression efficiency on noisy content, content with film grain, computer generated content, and low resolution materials is desirable.
ノイズの多いコンテンツ、フィルム粒子のあるコンテンツ、コンピュータで生成されたコンテンツ、低解像度の素材の圧縮効率が望ましい。
As shown in Figure 1, compression performance testing is performed in three overlapped ranges that encompass ten different bitrate values:
図1に示すように、圧縮パフォーマンステストは、10の異なるビットレート値を含む3つの重複した範囲で実行されます。
* Low bitrate range (LBR) is the range that contains the four lowest bitrates of the ten specified bitrates (one of the four bitrate values is shared with the neighboring range).
* 低ビットレート範囲（LBR）は、指定された10個のビットレートのうち4つの最低ビットレートを含む範囲です（4つのビットレート値の1つが隣接する範囲と共有されます）。
* Medium bitrate range (MBR) is the range that contains the four medium bitrates of the ten specified bitrates (two of the four bitrate values are shared with the neighboring ranges).
* 中程度のビットレート範囲（MBR）は、指定された10個のビットレートのうち4つの中程度のビットレートを含む範囲です（4つのビットレート値のうち2つは、隣接する範囲と共有されます）。
* High bitrate range (HBR) is the range that contains the four highest bitrates of the ten specified bitrates (one of the four bitrate values is shared with the neighboring range).
* 高ビットレート範囲（HBR）は、指定された10個のビットレートのうち4つの最高ビットレートを含む範囲です（4つのビットレート値の1つが隣接範囲と共有されます）。
Initially, for the codec selected as a reference one (e.g., HEVC or VP9), a set of ten QP (quantization parameter) values should be specified as in [14], and corresponding quality values should be calculated. In Figure 1, QP and quality values are denoted as "QP0"-"QP9" and "Q0"-"Q9", respectively. To guarantee the overlaps of quality levels between the bitrate ranges of the reference and tested codecs, a quality alignment procedure should be performed for each range's outermost (left- and rightmost) quality levels Qk of the reference codec (i.e., for Q0, Q3, Q6, and Q9) and the quality levels Q'k (i.e., Q'0, Q'3, Q'6, and Q'9) of the tested codec. Thus, these quality levels Q'k, and hence the corresponding QP value QP'k (i.e., QP'0, QP'3, QP'6, and QP'9), of the tested codec should be selected using the following formulas:
最初に、参照コーデックとして選択されたコーデック（HEVCやVP9など）に対して、10のQP（量子化パラメーター）値のセットを[14]のように指定し、対応する品質値を計算する必要があります。図1では、QPと品質の値は、それぞれ「QP0」-「QP9」と「Q0」-「Q9」として示されています。参照コーデックとテスト済みコーデックのビットレート範囲の間の品質レベルのオーバーラップを保証するには、参照コーデックの各範囲の最も外側（左と右）の品質レベルQk（つまり、Q0、Q3、 Q6、およびQ9）およびテストされたコーデックの品質レベルQ'k（つまり、Q'0、Q'3、Q'6、およびQ'9）。したがって、テストされたコーデックのこれらの品質レベルQ'k、および対応するQP値QP'k（つまり、QP'0、QP'3、QP'6、およびQP'9）は、次の式を使用して選択する必要があります。 ：
Q'k = min { abs(Q'i - Qk) },
i in R
QP'k = argmin { abs(Q'i(QP'i) - Qk(QPk)) },
i in R
where R is the range of the QP indexes of the tested codec, i.e., the candidate Internet video codec. The inner quality levels (i.e., Q'1, Q'2, Q'4, Q'5, Q'7, and Q'8), as well as their corresponding QP values of each range (i.e., QP'1, QP'2, QP'4, QP'5, QP'7, and QP'8), should be as equidistantly spaced as possible between the left- and rightmost quality levels without explicitly mapping their values using the procedure described above.
ここで、Rはテストされたコーデック、つまり候補のインターネットビデオコーデックのQPインデックスの範囲です。内部品質レベル（つまり、Q'1、Q'2、Q'4、Q'5、Q'7、およびQ'8）、および各範囲の対応するQP値（つまり、QP'1 QP'2、QP'4、QP'5、QP'7、およびQP'8）は、上記の手順を使用して値を明示的にマッピングすることなく、左端と右端の品質レベルの間で可能な限り等間隔に配置する必要があります。
QP'9 QP'8 QP'7 QP'6 QP'5 QP'4 QP'3 QP'2 QP'1 QP'0 <+-----
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | Tested
| | | | | | | | | | | codec
Q'0 Q'1 Q'2 Q'3 Q'4 Q'5 Q'6 Q'7 Q'8 Q'9 <+-----
^ ^ ^ ^
| | | |
Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 <+-----
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | Reference
| | | | | | | | | | | codec
QP9 QP8 QP7 QP6 QP5 QP4 QP3 QP2 QP1 QP0 <+-----
+----------------+--------------+--------------+--------->
^ ^ ^ ^ Bitrate
|-------LBR------| |-----HBR------|
^ ^
|------MBR-----|
Figure 1: Quality/QP Alignment for Compression Performance Evaluation
図1：圧縮性能評価のための品質/ QP調整
Since the QP mapping results may vary for different sequences, this quality alignment procedure eventually needs to be performed separately for each quality assessment index and each sequence used for codec performance evaluation to fulfill the requirements described above.
QPマッピングの結果はシーケンスによって異なる可能性があるため、最終的にこの品質アラインメント手順は、上記の要件を満たすために、コーデックのパフォーマンス評価に使用される各品質評価インデックスと各シーケンスに対して個別に実行する必要があります。
To assess the quality of output (decoded) sequences, two indexes (PSNR [3] and MS-SSIM [3] [15]) are separately computed. In the case of the YCbCr color format, PSNR should be calculated for each color plane, whereas MS-SSIM is calculated for the luma channel only. In the case of the RGB color format, both metrics are computed for R, G, and B channels. Thus, for each sequence, 30 RD-points for PSNR (i.e., three RD-curves, one for each channel) and 10 RD-points for MS-SSIM (i.e., one RD-curve, for luma channel only) should be calculated in the case of YCbCr. If content is encoded as RGB, 60 RD-points (30 for PSNR and 30 for MS-SSIM) should be calculated (i.e., three RD-curves, one for each channel) are computed for PSNR as well as three RD-curves (one for each channel) for MS-SSIM.
出力（デコード）シーケンスの品質を評価するために、2つのインデックス（PSNR [3]およびMS-SSIM [3] [15]）が別々に計算されます。 YCbCrカラーフォーマットの場合、PSNRはカラープレーンごとに計算する必要がありますが、MS-SSIMはルーマチャネルに対してのみ計算されます。 RGBカラーフォーマットの場合、R、G、Bチャネルの両方のメトリックが計算されます。したがって、各シーケンスについて、PSNRの30のRDポイント（つまり、3つのRDカーブ、各チャネルに1つ）とMS-SSIMの10のRDポイント（つまり、1つのRDカーブ、輝度チャネルのみ）を計算する必要があります。 YCbCrの場合。コンテンツがRGBとしてエンコードされている場合、60のRDポイント（PSNRに30、MS-SSIMに30）を計算する必要があります（つまり、3つのRDカーブ、各チャネルに1つ）がPSNRと3つのRDカーブ（ MS-SSIMの場合、チャネルごとに1つ）。
Finally, to obtain an integral estimation, BD-rate savings [13] should be computed for each range and each quality index. In addition, average values over all three ranges should be provided for both PSNR and MS-SSIM. A list of video sequences that should be used for testing, as well as the ten QP values for the reference codec, are defined in [14]. Testing processes should use the information on the codec applications presented in this document. As the reference for evaluation, state-of-the-art video codecs such as HEVC/H.265 [4][5] or VP9 must be used. The reference source code of the HEVC/ H.265 codec can be found at [6]. The HEVC/H.265 codec must be configured according to [16] and Table 9.
最後に、積分推定を取得するには、BDレート節約[13]を各範囲と各品質インデックスに対して計算する必要があります。さらに、PSNRとMS-SSIMの両方について、3つの範囲すべての平均値を提供する必要があります。テストに使用する必要があるビデオシーケンスのリスト、および参照コーデックの10個のQP値は、[14]で定義されています。テストプロセスでは、このドキュメントに記載されているコーデックアプリケーションに関する情報を使用する必要があります。評価の基準として、HEVC / H.265 [4] [5]またはVP9などの最新のビデオコーデックを使用する必要があります。 HEVC / H.265コーデックのリファレンスソースコードは、[6]にあります。 HEVC / H.265コーデックは、[16]および表9に従って構成する必要があります。
+----------------------+--------------------------------------------+
| Intra-period, second | HEVC/H.265 encoding |
| | mode according to [16] |
+======================+============================================+
| AI | Intra Main or Intra |
| | Main10 |
+----------------------+--------------------------------------------+
| RA | Random access Main or |
| | Random access Main10 |
+----------------------+--------------------------------------------+
| FIZD | Low delay Main or |
| | Low delay Main10 |
+----------------------+--------------------------------------------+
Table 9: Intraperiods for Different HEVC/H.265 Encoding Modes According to [16]
表9：[16]によるさまざまなHEVC / H.265エンコーディングモードの期間内
According to the coding efficiency requirement described in Section 4.1.1, BD-rate savings calculated for each color plane and averaged for all the video sequences used to test the NETVC codec should be, at least,
セクション4.1.1で説明されているコーディング効率要件に従って、各カラープレーンに対して計算され、NETVCコーデックのテストに使用されるすべてのビデオシーケンスに対して平均化されたBDレートの節約は、少なくとも、
* 25% if calculated over the whole bitrate range; and
* ビットレート範囲全体で計算すると25％。そして
* 15% if calculated for each bitrate subrange (LBR, MBR, HBR).
* 各ビットレートサブレンジ（LBR、MBR、HBR）に対して計算した場合、15％。
Since values of the two objective metrics (PSNR and MS-SSIM) are available for some color planes, each value should meet these coding efficiency requirements. That is, the final BD-rate saving denoted as S is calculated for a given color plane as follows:
2つの客観的メトリック（PSNRとMS-SSIM）の値は一部のカラープレーンで使用できるため、各値はこれらのコーディング効率要件を満たす必要があります。つまり、Sで表される最終的なBDレートの節約は、次のように特定のカラープレーンに対して計算されます。
S = min { S_psnr, S_ms-ssim }
where S_psnr and S_ms-ssim are BD-rate savings calculated for the given color plane using PSNR and MS-SSIM metrics, respectively.
ここで、S_psnrおよびS_ms-ssimは、それぞれPSNRおよびMS-SSIMメトリックを使用して、特定のカラープレーンに対して計算されたBDレート節約です。
In addition to the objective quality measures defined above, subjective evaluation must also be performed for the final NETVC codec adoption. For subjective tests, the MOS-based evaluation procedure must be used as described in Section 2.1 of [3]. For perception-oriented tools that primarily impact subjective quality, additional tests may also be individually assigned even for intermediate evaluation, subject to a decision of the NETVC WG.
上記で定義された客観的な品質測定に加えて、主観的な評価も最終的なNETVCコーデックの採用のために実行する必要があります。主観テストの場合、[3]のセクション2.1に記載されているように、MOSベースの評価手順を使用する必要があります。主に主観的な品質に影響を与える知覚指向のツールの場合、NETVC WGの決定に従って、中間評価のために追加のテストを個別に割り当てることもできます。
This document itself does not address any security considerations. However, it is worth noting that a codec implementation (for both an encoder and a decoder) should take into consideration the worst-case computational complexity, memory bandwidth, and physical memory size needed to process the potentially untrusted input (e.g., the decoded pictures used as references).
このドキュメント自体は、セキュリティに関する考慮事項については触れていません。ただし、コーデックの実装（エンコーダーとデコーダーの両方）では、信頼できない可能性のある入力（たとえば、デコードされた画像）を処理するために必要な最悪の場合の計算の複雑さ、メモリ帯域幅、および物理メモリサイズを考慮する必要があることに注意してください。参照として使用されます）。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[1] ITU-R, "Parameter values for ultra-high definition television systems for production and international programme exchange", ITU-R Recommendation BT.2020-2, October 2015, <https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en>.
[1] ITU-R、「制作および国際番組交換用の超高精細テレビシステムのパラメーター値」、ITU-R勧告BT.2020-2、2015年10月、<https://www.itu.int/rec/R- REC-BT.2020-2-201510-I / en>。
[2] ITU-T, "Quality of Experience requirements for telepresence services", ITU-T Recommendation G.1091, October 2014, <https://www.itu.int/rec/T-REC-G.1091/en>.
[2] ITU-T、「テレプレゼンスサービスのQuality of Experience要件」、ITU-T勧告G.1091、2014年10月、<https://www.itu.int/rec/T-REC-G.1091/en>。
[3] ISO, "Information technology -- Advanced image coding and evaluation -- Part 1: Guidelines for image coding system evaluation", ISO/IEC TR 29170-1:2017, October 2017, <https://www.iso.org/standard/63637.html>.
[3] ISO、「情報技術-高度な画像コーディングと評価-パート1：画像コーディングシステム評価のガイドライン」、ISO / IEC TR 29170-1：2017、2017年10月、<https://www.iso.org/standard /63637.html>。
[4] ISO, "Information technology -- High efficiency coding and media delivery in heterogeneous environments -- Part 2: High efficiency video coding", ISO/IEC 23008-2:2015, May 2018, <https://www.iso.org/standard/67660.html>.
[4] ISO、「情報技術-異種環境での高効率コーディングとメディア配信-パート2：高効率ビデオコーディング」、ISO / IEC 23008-2：2015、2018年5月、<https://www.iso.org/ standard / 67660.html>。
[5] ITU-T, "High efficiency video coding", ITU-T Recommendation H.265, November 2019, <https://www.itu.int/rec/T-REC-H.265>.
[5] ITU-T、「高効率ビデオコーディング」、ITU-T勧告H.265、2019年11月、<https://www.itu.int/rec/T-REC-H.265>。
[6] Fraunhofer Institute for Telecommunications, "High Efficiency Video Coding (HEVC) reference software (HEVC Test Model also known as HM)", <https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/>.
[6] Fraunhofer Institute for Telecommunications、「High Efficiency Video Coding（HEVC）reference software（HEVC Test Model別名HM）」、<https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/>。
[7] Federal Agencies Digital Guidelines Initiative, "Term: High dynamic range imaging", <http://www.digitizationguidelines.gov/ term.php?term=highdynamicrangeimaging>.
[7] 連邦政府機関のデジタルガイドラインイニシアチブ、「期間：ハイダイナミックレンジイメージング」、<http://www.digitizationguidelines.gov/term.php?term=highdynamicrangeimaging>。
[8] Federal Agencies Digital Guidelines Initiative, "Term: Compression, visually lossless", <http://www.digitizationguidelines.gov/ term.php?term=compressionvisuallylossless>.
[8] 連邦政府機関のデジタルガイドラインイニシアチブ、「期間：圧縮、視覚的にロスレス」、<http://www.digitizationguidelines.gov/ term.php？term = compressionvisuallylossless>。
[9] Wenger, S., "The case for scalability support in version 1 of Future Video Coding", SG 16 (Study Period 2013) Contribution 988, September 2015, <https://www.itu.int/md/T13-SG16-C-0988/en>.
[9] Wenger、S。、「Future Video Codingのバージョン1でのスケーラビリティサポートのケース」、SG 16（2013年の調査期間）Contribution 988、2015年9月、<https://www.itu.int/md/T13-SG16- C-0988 / en>。
[10] YouTube, "Recommended upload encoding settings", <https://support.google.com/youtube/answer/1722171?hl=en>.
[10] YouTube、「推奨アップロードエンコーディング設定」、<https://support.google.com/youtube/answer/1722171?hl=ja>。
[11] Yu, H., Ed., McCann, K., Ed., Cohen, R., Ed., and P. Amon, Ed., "Requirements for an extension of HEVC for coding of screen content", ISO/IEC JTC 1/SC 29/WG 11 Moving Picture Experts Group MPEG2013/N14174, San Jose, USA, January 2014, <https://mpeg.chiariglione.org/standards/mpeg-h/ high-efficiency-video-coding/requirements-extension-hevc-coding-screen-content>.
[11] Yu、H.、Ed。、McCann、K.、Ed。、Cohen、R.、Ed。、およびP. Amon、Ed。、「画面コンテンツのコーディングのためのHEVCの拡張の要件」、ISO / IEC JTC 1 / SC 29 / WG 11ムービングピクチャーエキスパートグループMPEG2013 / N14174、サンノゼ、米国、2014年1月、<https://mpeg.chiariglione.org/standards/mpeg-h/ high-efficiency-video-coding / requirements- extension-hevc-coding-screen-content>。
[12] Parhy, M., "Game streaming requirement for Future Video Coding", ISO/IEC JTC 1/SC 29/WG 11 Moving Picture Experts Group N36771, Warsaw, Poland, June 2015.
[12] Parhy、M。、「Future Video Codingのゲームストリーミング要件」、ISO / IEC JTC 1 / SC 29 / WG 11、Moving Picture Experts Group N36771、ポーランド、ワルシャワ、2015年6月。
[13] Bjontegaard, G., "Calculation of average PSNR differences between RD-curves", SG 16 VCEG-M33, April 2001, <https://www.itu.int/wftp3/av-arch/video-site/0104_Aus/>.
[13] Bjontegaard、G。、「RDカーブ間の平均PSNR差の計算」、SG 16 VCEG-M33、2001年4月、<https://www.itu.int/wftp3/av-arch/video-site/0104_Aus/> 。
[14] Daede, T., Norkin, A., and I. Brailovskiy, "Video Codec Testing and Quality Measurement", Work in Progress, Internet-Draft, draft-ietf-netvc-testing-09, 31 January 2020, <https://tools.ietf.org/html/draft-ietf-netvc-testing-09>.
[14] Daede、T.、Norkin、A。、およびI. Brailovskiy、「Video Codec Testing and Quality Measurement」、Work in Progress、Internet-Draft、draft-ietf-netvc-testing-09、31、2020年1月、<https：/ /tools.ietf.org/html/draft-ietf-netvc-testing-09>。
[15] Wang, Z., Simoncelli, E.P., and A.C. Bovik, "Multiscale structural similarity for image quality assessment", IEEE Thirty-Seventh Asilomar Conference on Signals, Systems and Computers, DOI 10.1109/ACSSC.2003.1292216, November 2003, <https://ieeexplore.ieee.org/document/1292216>.
[15] Wang、Z.、Simoncelli、EP、およびAC Bovik、「画質評価のためのマルチスケール構造類似性」、IEEE第37回信号、システム、およびコンピューターに関するAsilomar会議、DOI 10.1109 / ACSSC.2003.1292216、2003年11月、<https：/ /ieeexplore.ieee.org/document/1292216>。
[16] Bossen, F., "Common HM test conditions and software reference configurations", Joint Collaborative Team on Video Coding (JCT-VC) of the ITU-T Video Coding Experts Group (ITU-T Q.6/SG 16) and ISO/IEC Moving Picture Experts Group (ISO/IEC JTC 1/SC 29/WG 11) , Document JCTVC-L1100, April 2013, <http://phenix.it-sudparis.eu/jct/doc_end_user/ current_document.php?id=7281>.
[16] Bossen、F。、「Common HM test conditions and software reference configuration」、Joint Collaborative Team on Video Coding（JCT-VC）of the ITU-T Video Coding Experts Group（ITU-T Q.6 / SG 16）およびISO / IECムービングピクチャーエキスパートグループ（ISO / IEC JTC 1 / SC 29 / WG 11）、ドキュメントJCTVC-L1100、2013年4月、<http://phenix.it-sudparis.eu/jct/doc_end_user/ current_document.php？id = 7281>。
[17] ITU-R, "Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios", ITU-R Recommendation BT.601, March 2011, <https://www.itu.int/rec/R-REC-BT.601/>.
[17] ITU-R、「標準4：3およびワイドスクリーン16：9アスペクト比のデジタルテレビのスタジオエンコーディングパラメーター」、ITU-R勧告BT.601、2011年3月、<https://www.itu.int/rec/ R-REC-BT.601 />。
[18] ISO/IEC, "Information technology -- Coding of audio-visual objects -- Part 10: Advanced video coding", ISO/IEC DIS 14496-10, <https://www.iso.org/standard/75400.html>.
[18] ISO / IEC、「情報技術-視聴覚オブジェクトのコーディング-パート10：高度なビデオコーディング」、ISO / IEC DIS 14496-10、<https://www.iso.org/standard/75400.html> 。
[19] ISO/IEC, "Information technology -- Coding of audio-visual objects -- Part 15: Carriage of network abstraction layer (NAL) unit structured video in the ISO base media file format", ISO/IEC 14496-15, <https://www.iso.org/standard/74429.html>.
[19] ISO / IEC、「情報技術-視聴覚オブジェクトのコーディング-パート15：ISO抽象メディアファイル形式のネットワークアブストラクションレイヤー（NAL）ユニット構造化ビデオのキャリッジ」、ISO / IEC 14496-15、<https： //www.iso.org/standard/74429.html>。
[20] ITU-R, "Parameter values for the HDTV standards for production and international programme exchange", ITU-R Recommendation BT.709, June 2015, <https://www.itu.int/rec/R-REC-BT.709>.
[20] ITU-R、「制作および国際プログラム交換のためのHDTV標準のパラメーター値」、ITU-R勧告BT.709、2015年6月、<https://www.itu.int/rec/R-REC-BT.709 >。
Acknowledgments
謝辞
The authors would like to thank Mr. Paul Coverdale, Mr. Vasily Rufitskiy, and Dr. Jianle Chen for many useful discussions on this document and their help while preparing it, as well as Mr. Mo Zanaty, Dr. Minhua Zhou, Dr. Ali Begen, Mr. Thomas Daede, Mr. Adam Roach, Dr. Thomas Davies, Mr. Jonathan Lennox, Dr. Timothy Terriberry, Mr. Peter Thatcher, Dr. Jean-Marc Valin, Mr. Roman Danyliw, Mr. Jack Moffitt, Mr. Greg Coppa, and Mr. Andrew Krupiczka for their valuable comments on different revisions of this document.
著者は、Paul Coverdale氏、Vasily Rufitskiy氏、およびJianle Chen博士に、この文書に関する多くの有益な議論と、その準備中の支援、ならびにMo Zanaty氏、Minhua Zhou博士、Dr。アリ・ベゲン氏、トーマス・デーデ氏、アダム・ローチ氏、トーマス・デイビス氏、ジョナサン・レノックス氏、ティモシー・テリーベリー氏、ピーター・サッチャー氏、ジャン・マーク・ヴァリン氏、ロマン・ダニーリウ氏、ジャック・モフィット氏、このドキュメントのさまざまな改訂に関する貴重なコメントをくださったGreg Coppa氏とAndrew Krupiczka氏。
Authors' Addresses
著者のアドレス
Alexey Filippov Huawei Technologies
Alexey Filippov Huawei Technologies
Email: alexey.filippov@huawei.com
Andrey Norkin Netflix
アンドレイノーキンネットフリックス
Email: anorkin@netflix.com
Jose Roberto Alvarez Huawei Technologies
ホセ・ロベルト・アルバレス・ファーウェイ・テクノロジーズ
Email: j.alvarez@ieee.org