ビデオ コーデックはどのように機能しますか? パート 2. 何が、なぜ、どのように

最初の部分： ビデオと画像の操作の基本

何？ ビデオ コーデックは、デジタル ビデオを圧縮および/または解凍するソフトウェア/ハードウェアです。

何のために？ 帯域幅と帯域幅の両方の点で一定の制限があるにもかかわらず、
データ ストレージ スペースに関しては、市場ではますます高品質のビデオが求められています。 前回の投稿で、解像度 30x24、480 秒あたり 240 フレーム、ピクセルあたり 82,944 ビットに必要な最小値をどのように計算したか覚えていますか? 圧縮なしで 4 Mbit/s を受信しました。 現在、一般的に HD/FullHD/XNUMXK をテレビ画面やインターネットに送信する唯一の方法は圧縮です。 これはどのようにして達成されるのでしょうか? それでは、主な方法を簡単に見てみましょう。

翻訳は EDISON Software のサポートを受けて行われました。

私たちは婚約しています ビデオ監視システムの統合と 私たちは顕微鏡断層撮影装置を開発しています.

コーデックとコンテナ

初心者が犯すよくある間違いは、デジタル ビデオ コーデックとデジタル ビデオ コンテナーを混同することです。 コンテナは特定の形式です。 ビデオ (および場合によってはオーディオ) メタデータを含むラッパー。 圧縮されたビデオは、コンテナーのペイロードと考えることができます。

通常、ビデオ ファイルの拡張子は、そのコンテナのタイプを示します。 たとえば、ファイル video.mp4 はおそらくコンテナです MPEG-4パート14、video.mkv という名前のファイルが考えられます。 マトリョーシカ。 コーデックとコンテナ形式を完全に確認するには、次を使用できます。 FFmpegの または MediaInfoを.

歴史を少し

到着する前に どうやって？、いくつかの古いコーデックをもう少し詳しく理解するために、歴史を少し掘り下げてみましょう。

ビデオコーデック H.261 1990 年 (技術的には 1988 年) に登場し、64 Kbps のデータ転送速度で動作するように作成されました。 カラーサブサンプリング、マクロブロックなどのアイデアがすでに使用されています。 ビデオ コーデック標準は 1995 年に発行されました H.263、2001年まで開発されました。

最初のバージョンは 2003 年に完成しました H.264 / AVC。 同年、TrueMotion は、無料の非可逆ビデオ コーデックをリリースしました。 VP3。 Googleは2008年に同社を買収し、 VP8 同じ年に。 2012 年 XNUMX 月、Google は VP9であり、ブラウザ市場 (モバイル デバイスを含む) の約 XNUMX/XNUMX でサポートされています。

AV1 によって開発された新しい無料のオープンソースビデオコーデックです。 オープンメディアのためのアライアンス (AOメディア)、これには、Google、Mozilla、Microsoft、Amazon、Netflix、AMD、ARM、NVidia、Intel、Cisco などの最も有名な企業が含まれます。 コーデックの最初のバージョン 0.1.0 は、7 年 2016 月 XNUMX 日に公開されました。

AV1の誕生

2015 年の初めに、Google は次のことに取り組んでいました。 VP10Xiph (Mozilla が所有) が取り組んでいました ダアラCisco は、独自の無料ビデオ コーデックを作成しました。 トール.

その後 MPEG LA 最初に発表された年間制限数 HEVC (H.265) と H.8 の 264 倍の料金がかかりましたが、すぐにルールが再び変更されました。

年間制限はありませんが、
コンテンツ料金 (収益の 0,5%) および
単価はH.10の約264倍です。

オープンメディアのためのアライアンス は、機器メーカー (Intel、AMD、ARM、Nvidia、Cisco)、コンテンツ プロバイダー (Google、Netflix、Amazon)、ブラウザ作成者 (Google、Mozilla) など、さまざまな分野の企業によって作成されました。

両社には、ロイヤリティフリーのビデオ コーデックという共通の目標がありました。 すると現れます AV1 はるかに簡単な特許ライセンスを使用できます。 Timothy B. Terryberry は、現在の AV1 コンセプトとそのライセンス モデルの起源となった素晴らしいプレゼンテーションを行いました。

ブラウザを通じて AV1 コーデックを分析できることを知ると驚くでしょう (興味のある方は、次のリンクを参照してください)。 aomanalyzer.org).

ユニバーサルコーデック

ユニバーサル ビデオ コーデックの基礎となる主なメカニズムを見てみましょう。 これらの概念のほとんどは有用であり、次のような最新のコーデックで使用されています。 VP9, AV1 и HEVC。 説明されている内容の多くは簡略化されていることに注意してください。 場合によっては、実際の例 (H.264 など) を使用してテクノロジーを実証することもあります。

最初のステップ - 画像の分割

最初のステップは、フレームをいくつかのセクション、サブセクションなどに分割することです。

何のために？ 理由はたくさんあります。 画像を分割するとき、小さな可動部分に小さなセクションを使用することで、動きベクトルをより正確に予測できます。 静的な背景の場合は、より大きなセクションに制限することができます。

コーデックは通常、これらのセクションをセクション (またはチャンク)、マクロブロック (またはコーディング ツリー ブロック)、および複数のサブセクションに編成します。 これらのパーティションの最大サイズはさまざまで、HEVC では 64x64 に設定されますが、AVC では 16x16 が使用され、サブパーティションは最大 4x4 サイズまで分割できます。

前回の記事のフレームの種類を覚えていますか?! 同じことがブロックにも適用できるため、I フラグメント、B ブロック、P マクロブロックなどを持つことができます。

練習したい人は、画像がどのようにセクションやサブセクションに分割されるかを見てください。 これを行うには、前の記事ですでに説明したものを使用できます。 インテル ビデオ プロ アナライザー (有料ですが、最初の 10 フレームに制限されている無料試用版が付いています)。 ここで分析されるセクション VP9:

第 2 ステップ - 予測

セクションを作成したら、それらに対して占星術的な予測を行うことができます。 のために インテルの予想 転送する必要があります 動きベクトル および残り、および INTRA 予測の場合は送信されます 予測方向 そして残り。

第 3 ステップ - 変革

残差ブロック (予測セクション → 実際のセクション) を取得したら、全体の品質を維持しながらどのピクセルを破棄できるかを知る方法でそれを変換することができます。 正確な動作を提供する変換がいくつかあります。

他にも方法はありますが、詳しく見ていきましょう。 離散コサイン変換 (DCT -から 離散コサイン変換）。 DCT の主な機能:

• ピクセルのブロックを同じサイズの周波数係数のブロックに変換します。
• 空間的な冗長性を排除するために電力を凝縮します。
• 可逆性を提供します。

2 年 2017 月 14 日シントラ R.J. （シントラ、RJ）およびバイエル F.M. (Bayer FM) は、XNUMX 回の加算のみを必要とする画像圧縮のための DCT に似た変換に関する記事を発表しました。

それぞれのポイントのメリットがわからなくても心配する必要はありません。 次に、具体的な例を使用して、その真の価値を見てみましょう。

この 8x8 ピクセル ブロックを見てみましょう。

このブロックは、次の 8 x 8 ピクセルのイメージにレンダリングされます。

このピクセル ブロックに DCT を適用し、係数の 8x8 ブロックを取得します。

この係数のブロックをレンダリングすると、次の画像が得られます。

ご覧のとおり、元の画像とは異なります。 最初の係数が他の係数と大きく異なることがわかります。 この最初の係数は DC 係数として知られており、入力配列内のすべてのサンプル (平均のようなもの) を表します。

この係数のブロックには興味深い特性があります。つまり、高周波成分を低周波成分から分離します。

画像では、パワーの大部分が低周波数に集中しているため、画像をその周波数成分に変換し、高周波係数を破棄すると、画質をあまり犠牲にすることなく、画像を記述するために必要なデータ量を削減できます。

周波数とは、信号が変化する速さを指します。

DCT を使用して元の画像をその周波数 (係数のブロック) に変換し、最も重要でない係数の一部を破棄することにより、テスト ケースで得られた知識を適用してみます。

まず、周波数領域に変換します。

次に、係数の一部 (67%)、主に右下の部分を破棄します。

最後に、この破棄された係数のブロックから画像を再構成し (反転可能である必要があることに注意してください)、元の画像と比較します。

オリジナルのイメージに似ていることがわかりますが、オリジナルとは多くの違いがあります。 67,1875% を破棄しましたが、それでもオリジナルに似たものが得られました。 さらに優れた品質の画像を取得するために、より慎重に係数を破棄することも可能ですが、それは次のトピックです。

各係数はすべてのピクセルを使用して生成されます

重要: 各係数は XNUMX つのピクセルに直接マッピングされるのではなく、すべてのピクセルの加重合計です。 この驚くべきグラフは、各インデックスに固有の重みを使用して XNUMX 番目と XNUMX 番目の係数がどのように計算されるかを示しています。

DCT に基づく単純な画像形成を見て、DCT を視覚化することもできます。 たとえば、各係数の重みを使用して生成されたシンボル A は次のとおりです。

4 番目のステップ - 量子化

前のステップでいくつかの係数を破棄した後、最後のステップ (変換) で特別な形式の量子化を実行します。 この段階では、情報が失われることは許容されます。 あるいは、もっと単純に、係数を量子化して圧縮を実現します。

係数のブロックを量子化するにはどうすればよいでしょうか? 最も単純な方法の 10 つは均一量子化です。ブロックを取得するときに、それを XNUMX つの値 (XNUMX) で除算し、結果を四捨五入します。

この係数のブロックを逆にできるでしょうか? はい、除算した値と同じ値を乗算することができます。

このアプローチは、各係数の重要性が考慮されていないため、最善のものではありません。 単一の値の代わりに量子化器の行列を使用することもでき、この行列は右下の大部分と左上の少数を量子化することによって DCT 特性を活用できます。

ステップ 5 - エントロピーコーディング

データ (画像ブロック、フラグメント、フレーム) を量子化した後でも、可逆圧縮することができます。 データを圧縮するアルゴリズムの方法は数多くあります。 それらのいくつかを簡単に見ていきます。より深く理解するには、『Understanding Compression: Data Compression for Modern Developers』という本を読むことができます ("圧縮について: 最新の開発者のためのデータ圧縮"）。

VLCを使用したビデオエンコード

文字のストリームがあるとします。 a, e, r и t。 各文字がストリーム内に出現する頻度の確率 (0 から 1 の範囲) がこの表に示されています。

	a	e	r	t
確率	0,3	0,3	0,2	0,2

最も可能性の高いコードには一意のバイナリ コード (できれば小さいコード) を割り当て、可能性の低いコードには大きなコードを割り当てることができます。

	a	e	r	t
確率	0,3	0,3	0,2	0,2
バイナリコード	0	10	110	1110

最終的に各文字に 8 ビットを費やすことを想定して、ストリームを圧縮します。 圧縮しない場合、24 文字あたり XNUMX ビットが必要になります。 各文字をそのコードに置き換えると、節約できます。

最初のステップは文字をエンコードすることです e、これは 10 に等しく、XNUMX 番目の文字は a追加されます (数学的な方法ではありません): [10][0]、そして最後に XNUMX 番目の文字 t、これにより、最終的な圧縮ビットストリームは [10][0][1110] に等しくなります。 1001110、必要なスペースはわずか 7 ビット (元のスペースの 3,4 分の XNUMX) です。

各コードはプレフィックスが付いた一意のコードである必要があることに注意してください。 ハフマンアルゴリズム これらの数字を見つけるのに役立ちます。 この方法には欠陥がないわけではありませんが、このアルゴリズムによる圧縮方法を依然として提供しているビデオ コーデックが存在します。

エンコーダとデコーダの両方が、バイナリ コードを含むシンボル テーブルにアクセスできる必要があります。 したがって、テーブルを入力として送信することも必要です。

算術符号化

文字のストリームがあるとします。 a, e, r, s и t、その確率がこの表に示されています。

	a	e	r	s	t
確率	0,3	0,3	0,15	0,05	0,2

このテーブルを使用して、考えられるすべての文字を含む範囲を最大番号順に並べて構築します。

次に、XNUMX つの文字のストリームをエンコードしましょう。 食べる.

まず最初の文字を選択します e、これは 0,3 から 0,6 の部分範囲内にあります (含まれません)。 この部分範囲を取得し、以前と同じ比率で、この新しい範囲に対して再度分割します。

ストリームのコーディングを続けましょう 食べる。 次に XNUMX 番目の文字を取ります a、これは 0,3 から 0,39 までの新しい部分範囲内にあり、最後の文字を取得します t 同じプロセスをもう一度繰り返すと、最終的なサブ範囲は 0,354 ～ 0,372 になります。

0,354 ～ 0,372 の最後の部分範囲内の数値を選択するだけです。 0,36 を選択しましょう (ただし、この部分範囲内の他の数値を選択することもできます)。 この番号を使用してのみ、元のストリームを復元できます。 ストリームをエンコードするために範囲内に線を引いているようなものです。

逆の操作 (つまり、 デコード) も同様に単純です。数値 0,36 と初期範囲を使用して、同じプロセスを実行できます。 ただし、この番号を使用して、この番号を使用してエンコードされたストリームを識別します。

最初の範囲では、番号がスライスに対応していることがわかります。したがって、これが最初の文字です。 ここで、前と同じプロセスに従って、このサブ範囲を再度分割します。 ここで、0,36 が次の記号に対応していることがわかります。 aというプロセスを繰り返した結果、最後の文字に到達しました。 t (オリジナルのエンコードされたストリームを形成 食べる).

エンコーダとデコーダの両方にシンボル確率のテーブルが必要なので、それを入力データでも送信する必要があります。

とてもエレガントですね。 この解決策を考え出した人は本当に賢いです。 一部のビデオ コーデックでは、この技術が使用されています (または、少なくともオプションとして提供されています)。

そのアイデアは、量子化されたビット ストリームをロスレス圧縮することです。 確かに、この記事には詳細、理由、トレードオフなどが大量に欠落しています。 しかし、開発者であれば、もっと知っておくべきです。 新しいコーデックは、次のような異なるエントロピー エンコード アルゴリズムを使用しようとします。 ANS.

ステップ 6 - ビットストリーム形式

これをすべて実行した後、残っているのは、実行されたステップのコンテキストで圧縮フレームを解凍することだけです。 デコーダは、エンコーダによって行われた決定を明示的に通知される必要があります。 デコーダには、ビット深度、色空間、解像度、予測情報 (動きベクトル、方向性 INTER 予測)、プロファイル、レベル、フレーム レート、フレーム タイプ、フレーム番号など、必要な情報がすべて提供される必要があります。

ビットストリームを簡単に見てみましょう H.264。 最初のステップは、最小限の H.264 ビットストリームを作成することです (FFmpeg はデフォルトで次のようなすべてのエンコード オプションを追加します)。 セイナル — それが何なのかはもう少し詳しく説明します）。 これは、独自のリポジトリと FFmpeg を使用して行うことができます。

./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264

このコマンドは生のビットストリームを生成します H.264 64 フレーム、64×XNUMX 解像度、カラースペース付き YUV420。 今回は以下の画像をフレームとして使用します。

H.264 ビットストリーム

標準 AVC (H.264) 情報が (ネットワークの意味で) マクロフレームで送信されることを決定します。 NAL (これはネットワークの抽象化レベルです)。 NAL の主な目標は、「Web フレンドリーな」ビデオ プレゼンテーションを提供することです。 この規格は、テレビ (ストリームベース) やインターネット (パケットベース) で機能する必要があります。

NAL 要素の境界を定義する同期マーカーがあります。 各同期トークンには値が含まれています 0x00 0x00 0x01, 一番最初のものを除いて、これは以下に等しい 0x00 0x00 0x00 0x01. 立ち上げたら XNUMX進ダンプ 生成された H.264 ビットストリームでは、ファイルの先頭で少なくとも XNUMX つの NAL パターンが識別されます。

前述したように、デコーダは画像データだけでなく、ビデオ、フレーム、色、使用されるパラメータなどの詳細も認識する必要があります。 各 NAL の最初のバイトは、そのカテゴリとタイプを定義します。

NALタイプ識別子	説明
0	<XNUMXxXNUMXD>ет<XNUMXxDXNUMX> пп
1	IDR なしのエンコードされた画像フラグメント
2	コード化されたスライスデータセクション A
3	コード化されたスライスデータセクション B
4	コード化されたスライスデータセクション C
5	IDR イメージのエンコードされた IDR フラグメント
6	SEI 拡張機能の詳細情報
7	SPS シーケンスパラメータセット
8	PPS 画像パラメータのセット
9	アクセス区切り文字
10	シーケンスの終わり
11	スレッドの終わり
...	...

通常、ビットストリームの最初の NAL は次のとおりです。 SPS。 このタイプの NAL は、プロファイル、レベル、解像度などの一般的なエンコード変数について情報を提供する役割を果たします。

最初の同期マーカーをスキップすると、最初のバイトをデコードしてどの NAL タイプが最初であるかを見つけることができます。

たとえば、同期トークンの後の最初のバイトは次のようになります。 01100111、最初のビット (0) はフィールド f にありますorbidden_​​zero_bit。 次の 2 ビット (11) フィールドを教えてくれます nal_ref_idc、 これは、この NAL が参照フィールドであるかどうかを示します。 そして残りの5ビット(00111) フィールドを教えてくれます nal_unit_type、 この場合、それは SPS ブロックです (7）NAL。

XNUMX 番目のバイト (バイナリ=01100100, 16進法=0x64, 12月=100) SPS NAL のフィールドは プロフィールIDC、 これは、エンコーダーが使用したプロファイルを示しています。 この場合、限定されたハイ プロファイル (つまり、双方向 B セグメント サポートのないハイ プロファイル) が使用されました。

ビットストリーム仕様を見ると H.264 SPS NAL の場合、パラメータ名、カテゴリ、説明に多くの値が見つかります。 たとえば、フィールドを見てみましょう pic_width_in_mbs_minus_1 и pic_height_in_map_units_minus_1.

パラメータ名	カテゴリ	説明
pic_width_in_mbs_minus_1	0	うえ(v)
pic_height_in_map_units_minus_1	0	うえ(v)

これらのフィールドの値を使用して数学的演算を実行すると、解像度が得られます。 次を使用して 1920 x 1080 を表すことができます。 pic_width_in_mbs_minus_1 値は 119 ((119 + 1) * Macroblock_size = 120 * 16 = 1920) です。 繰り返しますが、スペースを節約するために、1920 をエンコードする代わりに 119 を使用しました。

作成したビデオをバイナリ形式でチェックし続ける場合 (例: xxd -b -c 11 v/minimal_yuv420.h264)、その後、フレーム自体である最後の NAL に移動できます。

ここでは、最初の 6 バイトの値が表示されます。 01100101 10001000 10000100 00000000 00100001 11111111。 最初のバイトは NAL タイプを示すことがわかっているため、この場合 (00101) は IDR フラグメント (5) であり、さらに詳しく調べることができます。

仕様情報を使用すると、フラグメントのタイプを解読することができます (スライスタイプ) とフレーム番号 (フレーム番号) とりわけ重要な分野です。

いくつかのフィールドの値を取得するには (ue(v), me(v), se(v）または te(v))、以下に基づいて特別なデコーダを使用してフラグメントをデコードする必要があります。 指数関数的なゴロム コード。 この方法は、特にデフォルト値が多数ある場合に、変数値をエンコードする場合に非常に効率的です。

値 スライスタイプ и フレーム番号 このビデオの 7 (I フラグメント) と 0 (最初のフレーム) です。

ビットストリームはプロトコルと考えることができます。 ビットストリームについて詳しく知りたい場合は、仕様を参照してください。 ITU H.264。 これは、画像データがどこにあるかを示すマクロ図です (YUV 圧縮形式で)。

他のビットストリームも調べることができます。 VP9, H.265 (HEVC)、または新しい最高のビットストリームでさえも AV1。 それらはすべて似ていますか？ いいえ、しかし、少なくとも XNUMX つを理解すれば、残りを理解するのははるかに簡単になります。

練習したいですか？ H.264 ビットストリームを探索する

単一フレームのビデオを生成し、MediaInfo を使用してビットストリームを調べることができます。 H.264。 実際、ビットストリームを分析するソースコードを見ることさえ妨げるものは何もありません。 H.264 (AVC).

練習には、Intel Video Pro Analyzer を使用できます (プログラムは有料であるとすでに言いましたが、10 フレームの制限付きの無料試用版があります?)。

Обзор

最新のコーデックの多くは、先ほど説明したものと同じモデルを使用していることに注意してください。 ここで、ビデオコーデックのブロック図を見てみましょう。 トール。 これには、これまでに行ったすべての手順が含まれています。 この投稿の主旨は、少なくともこの分野の技術革新とドキュメントについてより深く理解していただくことです。

以前は、139p 品質、720 fps で 30 時間続くビデオ ファイルを保存するには、0,031 GB のディスク容量が必要と計算されていました。 この記事で説明した方法 (フレーム間および内部予測、変換、量子化、エントロピー コーディングなど) を使用すると、(ピクセルあたり 367,82 ビットを費やすという事実に基づいて) 非常に優れたビデオを実現できます。満足のいく品質で、占有メモリは 139 GB ではなく、わずか XNUMX MB です。

H.265 はどのようにして H.264 よりも優れた圧縮率を実現しますか?

コーデックがどのように機能するかが詳しくわかったので、新しいコーデックがどのようにしてより少ないビット数でより高い解像度を実現できるのかを理解するのが容易になります。

比較すると AVC и HEVC、これはほとんどの場合、より大きな CPU 負荷と圧縮率の間で選択されることを覚えておく価値があります。

HEVC より多くのセクション (およびサブセクション) オプションがあります AVC、内部予測方向の増加、エントロピーコーディングの改善など。 これらすべての改善が行われました H.265 50% 以上圧縮可能 H.264.

最初の部分： ビデオと画像の操作の基本

出所： habr.com