ビットレート/サイズ計算機

ビットレート設定を最終的なファイルサイズの予測に変換する

計算例 — ビットレート/サイズ計算機

合計ビットレート	6.192 Mbps
最終サイズ	478.33 MB
目標と交差するビットレート	6.539 Mbps
目標達成に必要な動画ビットレート	6.539 Mbps
ピークビットレート	6.192 Mbps
ペイロードサイズ	464.4 MB
目標との差	-41.67 MB
音声の割合	3.1%

ページを開いたときに計算機が表示する値です。上の入力を変えると再計算されます。

インタラクティブシミュレーションを読み込んでいます...

ビットレートは流量、サイズは積分 🖖

ビットレートは変化率、ファイルサイズはその時間積分です。覚えておきたい数値は一つ。映像の内容にかかわらず、ビットレートが1 Mbit/s増えるごとに、1時間当たりのサイズはちょうど450 MB増えます。長さの影響も同じように積み重なります。「長時間講義」は控えめな3.2 Mbit/sですが、それでも18 Mbit/sの「4K」より大きなファイルになります。90分は15分を上回るからです。音声とコンテナのオーバーヘッドは小さく、この八つのプリセットでは完成ファイルの5～10パーセントを占めます。

ファイルがビットレートの8分の1になる理由 🖖

ビットレートは1秒あたりのビット数で表しますが、ファイルサイズはバイト単位であり、1バイトは8ビットです。そのためエンコーダーが示す毎秒メガビットは、毎秒メガバイトの容量に直すには8で割る必要があります。目安として、8 Mbpsはおよそ毎秒1 MBなので、10分のクリップは音声やオーバーヘッドを加える前で約600 MBになります。この係数8を正しく扱えるかどうかで、計画が収まるか8倍あふれるかが決まります。

一つの計算に潜む二種類の「メガ」 🖖

ビットレートは常にSIのメガを使い、1 Mbpsはちょうど10⁶ビット毎秒です。しかしファイルサイズの「MB」は曖昧で、ストレージメーカーやこの計算機は10⁶バイトとして扱う一方、Windowsは今も2進法で数え、そこでの「MB」は実際には2²⁰ = 1,048,576バイト（正しくはメビバイト、MiB）です。そのため同じ700 MBのファイルもエクスプローラーでは668 MBと表示され、この差は接頭辞ごとに積み重なり、「1 TB」のドライブは約931 GBしか表示しません。

連鎖のひとつの段 — 何が入り、何が出て、後段で何が壊れるか

この段はエンコード処理のどこに位置するか

動画エンコーダは単一のアルゴリズムではなく、順序の決まった 8 つの段です。その順序は恣意的ではありません。どの段も、直前の段が仕事を可能にしてくれたからこそ存在します。このツールはそのうちの 1 つを扱います。下の連鎖から残りの 7 つに移動できます。

ビットレート/サイズ計算機 — 連鎖が生んだビットレートをファイル容量に、つまり配信の制約に変換する

入ってくるもの: 符号化された流れの平均ビットレート。
出ていくもの: ファイル容量と、それが収まるかどうかの答え。
次の段が前提とすること: 後段には何もありません。ただし制約がもともと出てきたのはここです。第 07 段でレート制御に渡される目標がそれです。
ここで壊れるもの: 容量はビットレート×長さなので、コーデックの判断ではなく算術です。有用なのは逆向きです。容量の上限を長さで割れば、それが前のすべての段が収まらなければならないビットレートの予算になります。

前の段: レート制御

全プロセスの詳細解説

映像が6 Mbit/sの10分間の動画のファイルサイズ 5 ステップ
映像が 6 Mbit/s、音声が 192 kbit/s の10分間の動画。ファイルサイズを計算し、エンコーダーの設定を左右する問いに答えよ。そのうち音声はどれだけを占めているか。
1. ビットレートは足し合わされる。コンテナは両方のストリームを格納するため、サイズに関して重要な数値はそれらの合計である。
  
  $bitrate = 6 + 0.192 = 6.192 Mbit/s$
2. サイズはビットレートに再生時間を掛けたものであり、唯一の落とし穴は単位にある。ビットレートの単位はビットであり、ファイルのサイズはバイトで測定される。8で割ることを誰もが忘れがちだが、それこそが見積もりを8倍も大きくしてしまう原因そのものである。
  
  $payload = \frac{6.192 \times 600}{8} = 464.4 MB (8 bits per byte)$
3. さらに、コンテナ自体にもヘッダー、インデックス、インターリーブといったオーバーヘッドが存在し、ここでは3%としてモデル化されている。
  
  $file = 464.4 \times 1.03 = 478.33 MB$
4. 音声が占める割合は興味深い比率である。これはビットレートの3.1%であり、この3.1%は完成したファイルの14.4 MBに相当する。
  
  $\frac{0.192}{6.192} = 3.1% of the bitrate = \frac{0.192 \times 600}{8} = 14.4 MB$
5. 520 MBの制限に対して、このファイルには41.67 MBの余裕があるため、音声を削減するのではなく、映像のビットレートを少し上げることができる。
  
  $478.33 - 520 = - 41.67 MB ⟹ under a 520 MB cap$
解答

ツールには、合計ビットレート 6.192 Mbit/s、ペイロード 464.4 MB、最終サイズ 478.33 MB と表示される。判断を変える数値は 3.1% である。音声ビットレートを半分にすること（人々が真っ先に手をつけること）は、478 MBのファイルのうち約 7 MB を節約するに過ぎないが、すべての聴き手に対して聞き取れるレベルの音質低下をもたらす。映像から同じ 7 MB を削った場合、ビットレートのカットは 1.5% に過ぎず、誰も気づかないレベルである。この計算は単純であるが、結論はしばしば逆にとらえられがちである。なぜなら、192 kbit/s は 6 Mbit/s の隣に並ぶと、いかにも大きそうに聞こえるが、どちらが小さい数値であるかに気づくまでの話に過ぎないからである。

$size = \frac{bitrate \times duration}{8} \times (1 + overhead) = 478.33 MB$

参考文献 (1)

The binary prefixes block 3 separates from the SI ones: IEC 80000-13:2008, Quantities and units — Part 13: Information science and technology, which defines the kibibyte, mebibyte and gibibyte precisely so that "MB" need not be ambiguous.

42Math チーム · 更新 2026-05-26

公表された資料と照合しています。訂正のご指摘を歓迎します。編集方針 · 訂正

コンピューティングのレッスン一覧 →

例題

短いSNS動画 - 8 Mbit/sで30秒なら、わずか31.70 MBです。この長さなら、ビットレートを高めにしても予算を気にするほどの負担にはなりません。
1080pストリーム - 6 Mbit/sで10分。例題で計算を最後まで追う設定です。上限520 MBに対して478.33 MBとなり、41.67 MBの余裕があります。
4Kストリーム - 予算を超える唯一のプリセットですが、超過はわずかです。目標1900 MBに対して1925.35 MB。VBRではスライダー値の90%が平均となるため、18 Mbit/sは実質16.20 Mbit/sです。
長い講義 - スライダーを3.2 Mbit/sに設定して90分にすると、2048.98 MBになります。18 Mbit/sの「4K」より大きなファイルです。ここではビットレートより長さが効きます。
ポッドキャスト動画 - 1.8 Mbit/sで1時間なら802.33 MBで、そのうち音声が7.3%を占めます。音声を軽くする効果が無視できないのは、このプリセットだけです。
高品質 - 18 Mbit/sで20分なら2875.32 MB。一覧で最も大きなファイルになり、音声の割合は1.4%です。
モバイル通信 - 1.2 Mbit/sで15分なら132.56 MBに収まり、上限180 MBを大きく下回ります。30%の余裕を取り崩す必要もありません。
ライブ配信の余裕 - 4.5 Mbit/sで1時間のライブ配信では、ペイロード2082.60 MBにコンテナのオーバーヘッド6%が加わり、2207.56 MBになります。ここではオーバーヘッドが最大です。

YouTube

Axinom·How to Optimize Video Encoding (with Per-Scene Encoding)