同じ解像度とフレームレートでビットレートはどう違うのですか？

ビデオの品質について読むと、解像度、1秒あたりのフレーム数、ビットレートがビデオのサイズを決定するために決まることがわかりました。

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

ビデオの解像度が360 x 240であるとしましょう。 1フレームあたり86400ピクセルかかります。 フレームレートは30 Hzです。したがって、ビデオは1秒あたり86400×30 = 2592000ピクセルかかります。

1ピクセルが3バイト（24ビット）のデータであるとしましょう：私たちは毎秒2592000×24ビットのビデオ（62208000ビット）を持っています。

しかし、それはどう違うのでしょうか。

計算したのは、生の非圧縮ビデオのビットレートです。あなたは通常、研究や他の特殊な用途を除いてこれらを見つけることができません。通常のYouTubeビデオよりもはるかに高いビットレートではありますが、放送局でも圧縮ビデオを使用しています。

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

これがなぜであるか理解するためには、ビデオ圧縮が使用する2つの主要な原則に気づく必要があります。これらは「空間的」および「時間的冗長性」と呼ばれます。

空間的な冗長性

自然な内容を示す画像には、空間的な冗長性があります。という訳だ JPEG ピクセルブロックをまとめてコーディングできるため、画像データを圧縮できます。これらは、例えば８×８画素である。これらは「マクロブロック」と呼ばれます。

最近のビデオコーデックも同じことをしています。基本的には、ブロックごとにフレームを圧縮するために、JPEGと同様のアルゴリズムを使用しています。そのため、ピクセルあたりのビット数を格納するのではなく、マクロブロックあたりのビット数を格納する必要がなくなります。これは、ピクセルをより大きなグループに「まとめる」ためです。それらを要約することによって、アルゴリズムはまた人間の目に見えない情報を捨てます - これはあなたがほとんどのビットレートを減らすことができるところです。それはによって働きます 量子化 データ。これは、私たちが見ることができないより知覚可能で「捨てる」周波数を保持します。量子化係数は、ほとんどのコーデックでは「QP」と表現されています。これは、品質を左右する主なコントロールノブです。

あなたは今も進むことができます 予測する 同じ画像内で以前に符号化されたマクロブロックからのマクロブロック。これはと呼ばれます イントラ予測 。たとえば、灰色の壁の一部はすでにフレームの左上隅にエンコードされているので、同じフレーム内のそのマクロブロックを再び使用することができます。たとえば、その隣のマクロブロックなどです。前のものとの違いを保存してデータを保存します。このように、互いに非常によく似た2つのマクロブロックをエンコードする必要はありません。

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

時間的冗長性

これは、他のフレームに続くフレームがおそらくその前のフレームと非常によく似ているからです。ほとんどの場合、ほんの少しだけ変更がありますが、完全にエンコードしても意味がありません。ビデオエンコーダがすることはただエンコードすることです 差 マクロブロックの場合と同じように、2つの後続フレーム間。

上のウィキペディアの記事から例を挙げる 動き補償 これがあなたのオリジナルのフレームだとしましょう。

それから次のフレームとの違いはまさにこれです：

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

• Iフレーム （別名キーフレーム） - これらは完全にエンコードされたものです
• Pフレーム - これらは違いを保存するだけのものです

ときどきビデオにIフレームを挿入する必要があります。実際のビットレートは、使用されているIフレームの数によっても異なります。さらに、２つの後続のフレーム間の動きの差が大きいほど、エンコーダはより多く記憶しなければならない。 「無」移動のビデオはスポーツビデオよりもエンコードが簡単で、フレームあたりのビット数が少なくて済みます。

私はあなたの数学は実際に正しいと思いますが、それについてはもう少しあります。ここで欠けているのは圧縮です。

あなたは非圧縮ビットレートを計算し、そして圧縮が存在するという理由を思い付きました。ビットレートは、非圧縮ビデオでは信じられないほど大きくなります。そのため、ビデオをソースで圧縮し、レシーバで圧縮解除すると、ビットレートが管理しやすくなります。ハードウェアでもソフトウェアでも、十分に高速なデコンプレッサが必要です。

それで、問題はどれだけの圧縮が許容されるかになります - それは無損失ではない、通常あなたが情報を失っています、しかし彼らはそれほど目立たない重要性の低いデータを失うのに十分知的にしようとします。多くの動きがあるまで、それは通常かなり簡単です、そしてそれはより複雑になります。

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