同じ解像度とフレームレートの場合、ビットレートはどのように異なりますか?

同じ解像度とフレームレートの場合、ビットレートはどのように異なりますか?

ビデオ品質について調べてみると、ビデオのサイズは解像度、1秒あたりのフレーム数、ビットレートによって決まることがわかりました。

私の質問は、ビットレートがどのように計算され、どのように異なる可能性があるかということです。

ビデオの解像度が 360 x 240 だとします。1 フレームあたり 86,400 ピクセルを使用します。フレーム レートは 30 Hz です。したがって、ビデオは 1 秒あたり 86,400 × 30 = 2,592,000 ピクセルを使用します。

したがって、1 ピクセルが 3 バイト (24 ビット) のデータであるとすると、2592000 × 24 ビット/秒のビデオ (62208000 ビット)、つまり 62208 kBits になります (これは正しくないように思えますが、私の計算に問題があるのか​​もしれません)。

しかし、どのように違いが生まれ、品質にどのような違いが生まれるのでしょうか?

答え1

計算したのは、生の非圧縮ビデオのビットレートです。通常、研究やその他の特殊なアプリケーション以外では、このようなビットレートは見つかりません。放送局でも、一般的な YouTube ビデオよりもはるかに高いビットレートではありますが、圧縮ビデオを使用しています。

つまり、ビデオの品質はビデオの圧縮方法に大きく関係しています。圧縮すればするほど、フレームあたりのビット数は少なくなります。また、圧縮すればするほど、品質は低下します。さて、一部のビデオは他のビデオよりも圧縮がはるかに簡単です。本質的には、解像度とフレームレートが同じであっても、ビットレートが低くなるのはそのためです。

なぜそうなるのかを理解するには、ビデオ圧縮で使用される 2 つの主な原則を知っておく必要があります。これらは「空間的冗長性」と「時間的冗長性」と呼ばれます。

空間冗長性

自然な内容を示す画像には空間的な冗長性が存在します。これが理由ですJPEG非常にうまく機能します。ピクセルのブロックをまとめてコード化できるため、画像データを圧縮できます。たとえば、8 × 8 ピクセルです。これらは「マクロブロック」と呼ばれます。

現代のビデオコーデックも同じです。基本的にJPEGと同様のアルゴリズムを使用して、フレームをブロックごとに圧縮します。つまり、ピクセルごとにビットを保存するのではなく、マクロブロックごとにビットを保存します。これは、ピクセルをより大きなグループに「まとめる」ためです。まとめることで、アルゴリズムは人間の目に見えない情報も破棄します。これが、ビットレートの大部分を削減できる部分です。量子化データを変換します。これにより、より知覚可能な周波数が保持され、知覚できない周波数は「破棄」されます。量子化係数は、ほとんどのコーデックで「QP」として表現され、品質の主な制御ノブです。

これからは、予測する同じ画像内で以前にエンコードされたマクロブロックからマクロブロックを分離する。これはイントラ予測たとえば、灰色の壁の一部はフレームの左上隅にすでにエンコードされているため、そのマクロブロックを同じフレームで再度使用できます。たとえば、そのマクロブロックのすぐ隣にあるマクロブロックに使用できます。前のマクロブロックとの差分を保存してデータを保存するだけです。この方法では、互いに非常によく似た 2 つのマクロブロックをエンコードする必要がありません。

同じ画像サイズでビットレートが変わるのはなぜでしょうか。画像によっては、他の画像よりもエンコードしやすいものがあります。空間アクティビティが高いほど、実際にエンコードする必要がある量が多くなります。滑らかなテクスチャは、詳細なテクスチャよりもビット数が少なくなります。同じことがイントラ予測にも当てはまります。灰色の壁のフレームでは、1 つのマクロブロックを使用して他のすべてのマクロブロックを予測できますが、流れる水のフレームではそれほどうまく機能しない可能性があります。

時間的冗長性

これは、次のフレームが前のフレームと非常に似ている可能性が高いためです。ほとんどの場合、ほんの少ししか変化しないので、完全にエンコードするのは意味がありません。ビデオエ​​ンコーダーは、違いマクロブロックの場合と同様に、2 つの連続するフレーム間でも機能します。

Wikipediaの記事を例に挙げると、動き補償これが元のフレームだとしましょう:

次のフレームとの違いは次のようになります。

エンコーダーは、実際のピクセルごとの値ではなく、差分です。これが、各フレームに使用されるビットが毎回同じではない理由です。これらの「差分」フレームは、完全にエンコードされたフレームに依存しており、これが、最新のコーデックに少なくとも 2 種類のフレームがある理由です。

  • Iフレーム(別名キーフレーム)—これらは完全にエンコードされたもの
  • Pフレーム— これらは単に差を保存するものです

時々、ビデオに I フレームを挿入する必要があります。実際のビットレートは、使用される I フレームの数によっても異なります。さらに、2 つの連続するフレーム間の動きの違いが大きいほど、エンコーダーが保存しなければならないデータも多くなります。何も動いていないビデオは、スポーツ ビデオよりもエンコードが簡単で、フレームあたりのビット数も少なくなります。

答え2

あなたの計算は実際正しいと思いますが、もう少し意味があります。圧縮がここで欠けているリンクです。

非圧縮ビット レートを計算し、圧縮が存在する理由を突き止めました。非圧縮ビデオではビット レートが信じられないほど大きくなります。そのため、ソースでビデオを圧縮し、受信側で解凍すると、ビット レートが管理可能になります。必要なのは、ハードウェアまたはソフトウェアの十分に高速な解凍装置だけです。

したがって、問題はどの程度の圧縮が許容されるかということになります。通常はロスレスではないため、情報は失われますが、それほど目立たない重要度の低いデータを失うほどインテリジェントにしようとします。通常は、動きが激しいまでは比較的簡単ですが、動きが激しいと複雑になります。

編集: 追加するのを忘れましたが、圧縮方法を実装する部分はコーデックです。投稿でこれをタグとして使用していることに気付きました。

関連情報