ビデオコーディングフォーマット

ビデオ コーディング形式[ ^a] (またはビデオ圧縮形式と呼ばれることもあります)は、データ ファイルやビットストリームなどのデジタル ビデオコンテンツのコンテンツ表現形式です。通常、標準化されたビデオ圧縮アルゴリズム (最も一般的には離散コサイン変換(DCT) コーディングと動き補償に基づくもの) を使用します。特定のビデオ コーディング形式を圧縮または解凍するコンピューターソフトウェアまたはハードウェアコンポーネントは、ビデオ コーデックです。

一部のビデオ コーディング形式は、ビデオ コーディング仕様と呼ばれる詳細な技術仕様書で文書化されています。このような仕様の一部は、標準化組織によって技術標準として作成および承認されており、ビデオ コーディング標準と呼ばれています。事実上の標準と正式な標準 があります。

特定のビデオコーディング形式を使用してエンコードされたビデオコンテンツは通常、AVI、MP4、FLV、RealMedia、Matroskaなどのマルチメディアコンテナ形式内のオーディオストリーム（オーディオコーディング形式を使用してエンコード）とバンドルされています。そのため、ユーザーが持つのは通常H.264ファイルではなく、通常はAACでエンコードされたオーディオとともに、 H.264 でエンコードされたビデオの MP4 コンテナであるビデオファイルです。マルチメディアコンテナ形式には、いくつかの異なるビデオコーディング形式のいずれかを含めることができます。たとえば、 MP4 コンテナ形式には、MPEG-2 Part 2や H.264 などのビデオコーディング形式を含めることができます。もう1つの例は、ファイルタイプWebMの最初の仕様です。この仕様では、コンテナ形式（Matroska）が指定されていますが、 Matroska コンテナ内にあるビデオ（ VP8）とオーディオ（Vorbis ）の圧縮形式も正確に指定されています。ただし、 Matroska はVP9ビデオを含めることができ、Opusオーディオのサポートは後にWebM仕様に追加されました。

フォーマットとは、コーデックによって生成または消費されるデータのレイアウト プランです。

H.264 などのビデオ コーディング形式はコーデックと呼ばれることもありますが、仕様とその実装には明確な概念上の違いがあります。ビデオ コーディング形式は仕様で説明され、特定のビデオ コーディング形式のデータを非圧縮ビデオからエンコード/デコードするソフトウェア、ファームウェア、またはハードウェアは、それらの仕様の実装です。類推すると、ビデオ コーディング形式H.264 (仕様) とコーデック OpenH264 (特定の実装)の関係は、 C プログラミング言語(仕様) とコンパイラGCC (特定の実装) の関係と同じです。各仕様 (例: H.264 ) に対して、その仕様を実装するコーデックが多数存在する可能性があることに注意してください(例: x264、OpenH264、H.264/MPEG-4 AVC 製品および実装)。

この区別は、文献の用語では一貫して反映されていません。H.264仕様では、H.261、H.262、H.263、H.264 をビデオコーディング標準と呼んでおり、コーデックという言葉は含まれていません。^[2] Alliance for Open Mediaは、 AV1ビデオコーディング形式と、開発中の付随コーデックを明確に区別していますが、ビデオコーディング形式自体はビデオコーデック仕様と呼んでいます。^[3] VP9仕様では、ビデオコーディング形式VP9自体をコーデックと呼んでいます。^[4]

混同の例として、Chromium ^[5]と Mozilla ^[6]のビデオ形式一覧のページでは、どちらも H.264コーデックなどのビデオコーディング形式と呼ばれています。別の例として、Cisco のビールのように無料のビデオコーデックの発表では、プレスリリースで H.264 ビデオコーディング形式がコーデックと呼ばれていますが(「共通ビデオコーデックの選択」)、その後すぐに Cisco の H.264 エンコーダ/デコーダの実装がコーデックと呼ばれています(「H.264 コーデックをオープンソース化」)。^[7]

ビデオ コーディング形式は、その形式を実装するコーデックが使用するすべてのアルゴリズムを規定するものではありません。たとえば、ビデオ圧縮の一般的な仕組みの大部分は、ビデオ フレーム間の類似点(ブロック マッチング) を見つけ、以前にコーディングされた類似のサブイメージ (マクロブロックなど) をコピーして、必要に応じて小さな差異を追加することで圧縮を実現するというものです。このような予測子と差異の最適な組み合わせを見つけることはNP 困難な問題であり、^[8]最適なソリューションを見つけることは事実上不可能であることを意味します。ビデオ コーディング形式は、ビットストリーム形式のフレーム間でこのような圧縮をサポートする必要がありますが、このようなブロック マッチやその他のエンコード手順を見つけるための特定のアルゴリズムを不必要に義務付けないことで、ビデオ コーディング仕様を実装するコーデックには、アルゴリズムの選択を最適化および革新する自由がいくらかあります。たとえば、H.264 仕様のセクション 0.5 では、エンコード アルゴリズムは仕様の一部ではないとされています。^[2]アルゴリズムを自由に選択することで、同じビデオコーディング形式で異なる空間と時間の複雑さのトレードオフが可能になります。そのため、ライブフィードでは高速だが空間効率の悪いアルゴリズムを使用でき、後で大量生産するための1回限りのDVDエンコードでは、長いエンコード時間と空間効率の良いエンコードをトレードオフできます。

アナログビデオ圧縮の概念は、1929年にイギリスのRDケルがフレームごとに変化するシーンの部分だけを伝送するという概念を提案したときに遡ります。デジタルビデオ圧縮の概念は、ベル研究所の研究者BMオリバーとCWハリソンがビデオコーディングに差分パルス符号変調（DPCM）の使用を提案した1952年に遡ります。1959年には、 NHKの研究者Y.タキ、M.ハトリ、S.タナカがフレーム間 動き補償の概念を提案し、時間次元での予測フレーム間ビデオコーディングを提案しました。^[9] 1967年には、ロンドン大学の研究者AHロビンソンとC.チェリーが、アナログテレビ信号の伝送帯域幅を削減するためのロスレス圧縮方式であるランレングス符号化（RLE）を提案しました。^[10]

最も初期のデジタルビデオコーディングアルゴリズムは、非圧縮ビデオ用かロスレス圧縮を使用していましたが、どちらの方法もデジタルビデオコーディングには非効率的で実用的ではありませんでした。^{[11] [ 12]}デジタルビデオは1970年代に導入され、^[11]最初は非圧縮パルス符号変調(PCM) を使用していましたが、標準解像度(SD) ビデオでは約 45～200 Mbit/sの高いビットレートが必要でした。 ^{[11] [12]}これは、 1990 年代まで利用可能だった通信帯域幅(最大 100 kbit/s )の最大 2,000 倍でした。 ^[12]同様に、非圧縮の高解像度(HD) 1080pビデオでは 1 Gbit/sを超えるビットレートが必要で、2000 年代に利用可能な帯域幅を大幅に上回ります。^[13]   

実用的なビデオ圧縮は、動き補償 DCT（MC DCT）符号化^{[12] [11]}の開発によって登場しました。これはブロック動き補償（BMC）^[9]またはDCT動き補償とも呼ばれます。これはハイブリッド符号化アルゴリズム^[9]であり、空間次元での離散コサイン変換（DCT）符号化^{[12] [11]}と時間次元での予測動き補償^[9]という2つの主要なデータ圧縮技術を組み合わせたものです。

DCT符号化は、1972年にカンザス州立大学に勤務していたナシル・アハメドによって最初に提案された非可逆ブロック圧縮変換符号化技術であり、当初は画像圧縮を目的としていました。その後、1973年にテキサス大学のT.ナタラジャンとKRラオとともにアハメドによって実用的な画像圧縮アルゴリズムに開発され、1974年に発表されました。^{[14] [15] [16]}

もう一つの重要な開発は、動き補償ハイブリッド符号化でした。^[9] 1974年、南カリフォルニア大学のAli Habibiがハイブリッド符号化を導入しました。 ^{[17] [18] [19]}これは、予測符号化と変換符号化を組み合わせたものです。^{[9] [20]}彼は、DCT、アダマール変換、フーリエ変換、傾斜変換、カルーネン・レーベ変換など、いくつかの変換符号化手法を検討しました。^[17]しかし、彼のアルゴリズムは当初、空間次元でのフレーム内符号化に限定されていました。1975年、John A. RoeseとGuner S. Robinsonは、Habibiのハイブリッド符号化アルゴリズムを時間次元に拡張し、空間次元では変換符号化、時間次元では予測符号化を使用して、フレーム間動き補償ハイブリッド符号化を開発しました。^{[9] [21]}空間変換符号化については、DCTや高速フーリエ変換（FFT）などのさまざまな変換を試し、それらのフレーム間ハイブリッド符号化器を開発し、DCTは複雑さが少ないため最も効率的であり、ビデオ電話のシーンでは1ピクセルあたり0.25ビットまで画像データを圧縮でき、1ピクセルあたり2ビットを必要とする一般的なフレーム内符号化器に匹敵する画質を実現できることを発見しました。^{[22] [21]}

DCTはウェン・シウン・チェン^[23]によってビデオエンコーディングに応用されました。[23]は1977年にCHスミスおよびSCフラリックと共に高速DCTアルゴリズムを開発し、^{[24] [25]}、DCT技術を商品化するためにCompression Labsを設立しました。 ^[23] 1979年に、アニル・K・ジェインとジャスワント・R・ジェインは動き補償DCTビデオ圧縮をさらに開発しました。^{[26] [9]}これにより、チェンは1981年に動き補償DCTまたは適応シーンコーディングと呼ばれる実用的なビデオ圧縮アルゴリズムを開発しました。^[9]動き補償DCTは、1980年代後半以降、ビデオ圧縮の標準的なコーディング手法になりました。^{[11] [27]}

最初のデジタルビデオ符号化規格は、 1984年にCCITT（現在のITU-T）によって開発されたH.120でした。 ^[28] H.120はパフォーマンスが低すぎたため、実際には使用できませんでした。^[28] H.120は動き補償DPCM符号化を使用していましたが、^[9]ロスレス圧縮アルゴリズムはビデオ符号化には非効率的でした。^[11] 1980年代後半には、多くの企業が離散コサイン変換（DCT）符号化の実験を開始しました。これは、ビデオ符号化用のはるかに効率的な圧縮形式です。CCITTは、ベクトル量子化（VQ）圧縮に基づく1つの提案とは対照的に、DCTベースのビデオ圧縮形式の提案を14件受け取りました。H.261規格は、動き補償DCT圧縮に基づいて開発されました。^{[11] [27]} H.261は最初の実用的なビデオコーディング規格であり、^[28]日立、PictureTel、NTT、BT、東芝など多くの企業からライセンスを受けた特許を使用しています。 ^[29] H.261以降、動き補償DCT圧縮は、その後に続くすべての主要なビデオコーディング規格（H.26xおよびMPEG形式を含む）で採用されています。^{[11] [27]}

1991年には、 Moving Picture Experts Group （MPEG）によって開発されたMPEG-1が続き、VHS品質のビデオを圧縮するように設計されました。^[28] 1994年にはMPEG-2 / H.262 ^[28 ] が後継となり、これは、主にソニー、トムソン、三菱電機など多くの企業からライセンスを受けた特許を使用して開発されました。^{[30] MPEG-2は、} DVDやSDデジタルテレビの標準ビデオ形式になりました。^[28]動き補償DCTアルゴリズムは、最大100：1の圧縮率を達成することができ、ビデオオンデマンド（VOD）^[12]や高精細テレビ（HDTV）などのデジタルメディア技術の開発を可能にしました。^{[31] 1999年に}は、ビデオ圧縮技術にとって大きな飛躍であったMPEG-4 / H.263が続きました。 ^{[28] [32]}

2019年現在、最も広く使用されているビデオコーディング形式はH.264 / MPEG-4 AVC^{[アップデート]}です。^{[33]これは2003年に開発され、主にパナソニック、}合同会社IPブリッジ、LGエレクトロニクスなど、多くの組織からライセンスされた特許を使用しています。^[34]先行者が使用した標準DCTとは対照的に、AVCは整数DCTを使用します。^{[23] [35] H.264は}Blu-rayディスクのビデオエンコーディング規格の1つであり、すべてのBlu-rayディスクプレーヤーはH.264をデコードできる必要があります。また、 YouTube、Netflix、Vimeo、iTunes Storeなどの動画ストリーミングインターネットソース、Adobe Flash PlayerやMicrosoft Silverlightなどのウェブソフトウェア、地上波（ATSC規格、ISDB-T、DVB-TまたはDVB-T2）、ケーブル（DVB-C）、衛星（DVB-S2 ）を介したさまざまなHDTV放送でも広く使用されています。^[36]

多くのビデオコーディング形式の主な問題は特許であり、使用に費用がかかったり、サブマリン特許のために特許訴訟のリスクが生じたりする可能性があります。 Theora、VP8、VP9など、最近設計された多くのビデオコーディング形式の背後にある動機は、ロイヤリティフリーの特許のみでカバーされる（自由な）ビデオコーディング標準を作成することでした。 ^{[37]特許の状況は、主流の}WebブラウザーがHTMLビデオタグ内でどのビデオ形式をサポートするかを選択する際の大きな論点でもあります。

現世代のビデオコーディング形式は、2013年に導入されたHEVC （H.265）です。AVCは4x4と8x8のブロックサイズで整数DCTを使用し、HEVCは4x4から32x32までのさまざまなブロックサイズで整数DCTとDST変換を使用します。^[38] HEVCは、主にサムスン電子、GE、NTT、JVCケンウッドによって多数の特許を取得しています。^{[39]フリーライセンスを目的とした}AV1形式 がHEVCに挑戦しています。2019年現在^{[アップデート]}、AVCはビデオコンテンツの録画、圧縮、配信に最も一般的に使用されている形式であり、ビデオ開発者の91％が使用しています。次に開発者の43％が使用するHEVCが続きます。^[33]

消費者向けビデオは、一般的に非可逆 ビデオコーデックを使用して圧縮されます。これは、可逆圧縮よりもファイルサイズが大幅に小さくなるためです。一部のビデオコーディング形式は、非可逆圧縮または可逆圧縮のいずれかに明示的に設計されており、DiracやH.264などの一部のビデオコーディング形式は両方をサポートしています。^[49]

Clean HDMIなどの非圧縮ビデオ形式は、 HDMI接続を介してビデオをディスプレイに送信する場合など、特定の状況で使用されるロスレス ビデオの形式です。一部のハイエンド カメラでは、この形式でビデオを直接キャプチャすることもできます。^{[例が必要]}

フレーム間圧縮は、エンコードされたビデオシーケンスの編集を複雑にします。^[50] 比較的単純なビデオコーディング形式の1つのサブクラスは、 DVなどのフレーム内ビデオ形式です。この形式では、ビデオストリームの各フレームは、ストリーム内の他のフレームを参照せずに独立して圧縮され、より良い圧縮のために時間の経過に伴う連続する画像間の相関関係を利用する試みは行われません。1つの例は、Motion JPEGで、これは単に個別にJPEG圧縮された画像のシーケンスです。このアプローチは迅速かつ簡単ですが、エンコードされたビデオは、フレーム間コーディングをサポートするビデオコーディング形式よりもはるかに大きくなります。

インターフレーム圧縮では、あるフレームから別のフレームにデータをコピーするため、元のフレームが単純にカットされた場合（または伝送中に失われた場合）、次のフレームを正しく再構築することはできません。ビデオ編集中にイントラフレーム圧縮されたビデオをカットすることは、非圧縮ビデオの編集とほぼ同じくらい簡単です。各フレームの先頭と末尾を見つけ、保持したい各フレームをビット単位でコピーし、不要なフレームを破棄するだけです。イントラフレーム圧縮とインターフレーム圧縮のもう1つの違いは、イントラフレームシステムでは、各フレームが同様の量のデータを使用することです。ほとんどのインターフレームシステムでは、特定のフレーム（MPEG-2のIフレームなど）は他のフレームからデータをコピーできないため、近くの他のフレームよりもはるかに多くのデータが必要になります。^[51]

フレームが編集されても他のフレームは必要ないという問題を検出するコンピュータベースのビデオエディタを構築することは可能です。これにより、HDVなどの新しいフォーマットを編集に使用できるようになりました。ただし、このプロセスでは、同じ画質のフレーム内圧縮ビデオを編集するよりもはるかに多くの計算能力が必要です。ただし、この圧縮はどのオーディオフォーマットにもあまり効果的ではありません。^[52]

ビデオコーディングフォーマットは、プロファイルとレベルと呼ばれるエンコードされたビデオに対するオプションの制限を定義することができます。例えば、デコーダプログラム/ハードウェアをより小さく、よりシンプルに、またはより高速にするために、特定のビデオフォーマットのプロファイルとレベルのサブセットのデコードのみをサポートするデコーダを持つことが可能です。^[53]

プロファイルは、許可されるエンコード技術を制限します。たとえば、H.264形式には、ベースライン、メイン、ハイ（およびその他）のプロファイルが含まれます。Pスライス（前のスライスに基づいて予測可能）はすべてのプロファイルでサポートされていますが、Bスライス（前後のスライスの両方に基づいて予測可能）はメインプロファイルとハイプロファイルでサポートされていますが、ベースラインではサポートされていません。^[54]

レベルとは、最大解像度やデータレートなどのパラメータに対する制限である。^[54]

• ビデオコンテナ形式の比較
• データ圧縮 § ビデオ
• ディスプレイ解像度
• ビデオ圧縮形式のリスト
• ビデオファイル形式