同じ解像度とフレームレートでビットレートはどのように異なりますか？
ビデオ品質について読んでいると、ビデオのサイズを決定する解像度、1秒あたりのフレーム数、ビットレートに依存することがわかりました。
私の質問は、ビットレートがどのように計算され、どのように異なることができるかです。
動画の解像度が360x240であるとしましょう。フレームあたり86400ピクセルかかります。フレームレートは30 Hzです。したがって、ビデオは86400×30 = 2592000ピクセル/秒です。
したがって、1ピクセルが3バイト（24ビット）のデータであるとします。ビデオは2592000×24ビット/秒（62208000ビット）、つまり62208 kビットです（これは正しく聞こえません。おそらく私の計算に問題があるでしょう）。
しかし、どのように違いがあり、どのように品質に違いがあるのでしょうか。
計算したのは、生の非圧縮ビデオのビットレートです。研究や他の特殊なアプリケーション以外では、通常これらは見つかりません。一般のYouTubeビデオよりもはるかに高いビットレートではありますが、放送局でさえ圧縮ビデオを使用しています。
したがって、ビデオの品質は、ビデオの圧縮方法に大きく関係します。圧縮するほど、フレームあたりのビット数が少なくなります。また、圧縮するほど品質が低下します。現在、一部のビデオは他のビデオよりもはるかに簡単に圧縮できます。つまり、同じ解像度とフレームレートであっても、ビットレートが低いのはこのためです。
これがなぜであるかを理解するには、ビデオ圧縮が使用する2つの主要な原則に注意する必要があります。これらは「空間的」および「時間的冗長性」と呼ばれます。
空間的冗長性
自然なコンテンツを示す画像には、空間的な冗長性があります。これが [〜＃〜] jpeg [〜＃〜] がうまく機能する理由です。ピクセルのブロックを一緒にコーディングできるため、画像データが圧縮されます。これらは、たとえば8×8ピクセルです。これらは「マクロブロック」と呼ばれます。
最新のビデオコーデックも同じです。基本的には、ブロックごとにフレームを圧縮するために、JPEGと同様のアルゴリズムを使用します。したがって、ピクセルをビットごとに格納するのではなく、マクロブロックごとのビットを格納します。これは、ピクセルをより大きなグループに「要約」するためです。それらを要約することにより、アルゴリズムは人間の目には見えない情報も破棄します—ここで、ビットレートのほとんどを減らすことができます。 quantizing データによって機能します。これにより、認識しやすい周波数が保持され、見えない周波数が「捨てられます」。量子化係数は、ほとんどのコーデックで「QP」として表され、品質を制御する主な要素です。
同じ画像で以前にエンコードされたマクロブロックから、predictマクロブロックに進むこともできます。これはイントラ予測と呼ばれます。たとえば、灰色の壁の一部はすでにフレームの左上隅にエンコードされているため、同じマクロフレームで、たとえばそのすぐ隣のマクロブロックで、そのマクロブロックを再び使用できます。前回との違いを保存し、データを保存します。この方法では、互いに非常に似ている2つのマクロブロックをエンコードする必要はありません。
同じ画像サイズでビットレートが変わるのはなぜですか？まあ、いくつかの画像は他よりもエンコードが簡単です。空間アクティビティが高いほど、実際にエンコードする必要があります。滑らかなテクスチャは、詳細なテクスチャよりもビットが少なくて済みます。同じことがイントラ予測にも当てはまります。灰色の壁のフレームでは、1つのマクロブロックを使用して他のすべてのマクロブロックを予測できますが、流れる水のフレームはそれほどうまく機能しない可能性があります。
時間的冗長性
これは、別のフレームの次のフレームがおそらく前のフレームと非常に似ているために存在します。ほとんどの場合、ほんの少しの変更であり、完全にエンコードしても意味がありません。ビデオエンコーダーは、マクロブロックの場合と同様に、後続の2つのフレーム間のdifferenceをエンコードするだけです。
ウィキペディアの 動き補償 に関する記事の例を見てみましょう。これが元のフレームだとしましょう。
次に、次のフレームとの違いはこれだけです：
エンコーダーはactualの差分のみを保存し、ピクセルごとの値は保存しません。これが、各フレームに使用されるビットが毎回同じではない理由です。これらの「差分」フレームは完全にエンコードされたフレームに依存しているため、最新のコーデックには少なくとも2種類のフレームがあります。
ビデオにIフレームを挿入する必要がある場合があります。実際のビットレートは、使用されるIフレームの数にも依存します。さらに、2つの後続のフレーム間で動きの違いが大きくなるほど、エンコーダーが保存する必要があります。 「何もない」動きのビデオは、スポーツビデオよりもエンコードが簡単で、フレームあたりのビット数が少なくなります。
あなたの数学は実際には正しいと思いますが、それはもう少しあります。圧縮はここで欠けているリンクです。
圧縮されていないビットレートを計算し、圧縮が存在する理由を考え出しました。非圧縮ビデオでは、ビットレートが非常に大きくなります。したがって、ソースでビデオを圧縮し、レシーバーでビデオを解凍すると、ビットレートが管理可能になります。ハードウェアでもソフトウェアでもかまいませんが、十分に高速な解凍プログラムが必要です。
したがって、問題はどの程度の圧縮を許容できるかになります-通常、それはロスレスではないので、情報を失いますが、それほど目立たない重要度の低いデータを失うほどインテリジェントにしようとします。動きが多くなるまでは、通常はかなり簡単で、その後はさらに複雑になります。
編集：追加するのを忘れましたが、圧縮方法を実装する部分はコーデックです。これを投稿のタグとして使用しているようです。