動画ファイルサイズ / ビットレート計算

ビットレート計算は動画制作の意思決定情報を扱う

動画のビットレートとファイルサイズの計算が必要な場面は、クライアントへの動画納品前にファイルサイズを確認する、SNS プラットフォームのアップロード上限に収まるか確認する、動画配信サーバーの容量計算をする、エンコード設定を決めてから収録・エンコード作業を始める、といった映像制作・配信計画の意思決定プロセスに埋め込まれています。入力する数値 (ビットレート・動画長・目標ファイルサイズ) は、制作中または制作予定の動画プロジェクトの仕様そのものです。

「どのビットレートで 60 分の動画をエンコードするか」という計算に必要な情報は、そのプロジェクトの尺・品質方針・配信先の制約を示します。オンラインビットレート計算ツールへの入力は、進行中の案件の技術仕様として読み取れる業務情報です。ビットレート計算は動画データを直接取り扱わないため「センシティブでない」と感じやすいですが、入力の組み合わせが業務情報を示す点では他のツールと変わりません。

算術計算にサーバーは不要 — ブラウザで完結できる

ビットレートとファイルサイズの計算式は ファイルサイズ (bytes) = (映像 kbps + 音声 kbps) × 1000 × 動画長 (秒) / 8 で、逆算は 映像 kbps = (目標サイズ × 8 / 1000 / 動画長) - 音声 kbps です。いずれも四則演算のみで、外部 API や機械学習モデルは一切必要ありません。プラットフォームのプリセット (YouTube・X・TikTok・Instagram の推奨ビットレート) も、公開仕様に基づく固定値をブラウザ内に持っています。

にもかかわらず、オンラインツールの中にはビットレート計算を「入力 → サーバー送信 → 結果返却」の形で実装しているものがあります。算術計算のためにサーバーへ入力値を送る必要は技術的にゼロです。ブラウザ内で完結させることで、プロジェクト仕様を示す入力情報が外部のサーバーに届くことを防げます。

すべてブラウザ内の JavaScript 演算、ネットワーク通信ゼロ

このツールのビットレート計算・サイズ計算・逆算・プラットフォームプリセット表示はすべてブラウザ内の JavaScript で実行されます。ファイルサイズ (bytes) = (videoBps + audioBps) × durationSec / 8 で求め、バイナリ MB (1024²) 換算で表示します。逆算は videoKbps = (targetBytes × 8 / 1000 / durationSec) - audioKbps です。プラットフォームプリセットのビットレート値は公開仕様に基づく定数として実装に含まれており、外部 API は使いません。

DevTools の Network タブを開いた状態で計算を実行しても、ツール本体の読み込み以外にリクエストが発生しないことを目視で確認できます。入力した数値・計算結果はブラウザのページ内だけに存在し、サーバーへは送信されません。ソースコードは GitHub で公開されており、計算ロジックと定数を第三者が確認できます。

制作仕様の試算は手元のブラウザで、動画データと同じプライバシーレベルで

映像制作のビットレート計算は、プロジェクトの仕様決定の一部です。その計算をブラウザ内で完結させることで、クライアント案件の制作仕様・配信計画・エンコード方針が外部のサーバーに記録されることなく、手元の意思決定ツールとして使えます。計算ツールでも、扱う情報の業務的な文脈に応じたプライバシー保護が有効です。

CBR / VBR / CRF / ABR の違いと CRF を超えた最適化

ビットレート制御モードには大きく分けて 4 種類あります。CBR (Constant Bit Rate) は全シーンで同じビットレートを使う方式で、ライブ配信や放送など帯域が固定されている環境で必須。VBR (Variable Bit Rate) は動きの激しいシーンで多くのビットを割り当て、静止シーンで節約する方式で、平均ビットレート (average) と最大ビットレート (max) で挟む形で指定します。CRF (Constant Rate Factor) は libx264 / libx265 / libaom-av1 の品質目標方式で、ビットレートではなく「同じ視覚品質」を維持するよう各フレームの量子化パラメータ (QP) を動的に変動させます。ABR (Average Bit Rate) は CBR と VBR の中間で、平均ビットレートだけを目標として制約します。

Two-pass encoding (-pass 1 -pass 2) は VBR / ABR の精度を高める手法で、1 パス目で全フレームの複雑度を解析して .log を生成し、2 パス目でビット配分を最適化します。同じ目標ファイルサイズに対して single-pass より 10〜20% 高い品質が得られる代わりに、エンコード時間がほぼ倍になります。配信プラットフォームへの納品 (Netflix / Amazon Prime Video) では Two-pass が事実上の必須となっており、x264 slow プリセット以上での Two-pass が一般的です。B-pyramid (B フレームを階層的に参照させる) や psy-rd (psycho-visual rate distortion、見た目の最適化) も同じ CRF / 同じビットレートでさらに品質を引き上げる手段で、-tune film -tune animation などのチューニングプリセットでまとめて指定できます。

配信プラットフォームの推奨ビットレートと現場での運用

YouTube SDR の推奨ビットレートは 2160p (4K) で 35〜45 Mbps、1440p で 16 Mbps、1080p で 8 Mbps、720p で 5 Mbps、480p で 2.5 Mbps、360p で 1 Mbps。HDR は SDR の 1.25 倍程度。フレームレートが 50/60 fps の場合は表内の値の 1.5 倍を推奨しています。これらは YouTube 側の再エンコードが行われる際の「入力品質を保つための余裕」で、最終的な配信ビットレートはユーザーの帯域に応じて自動調整されます。

X (旧 Twitter) は 1080p で 25 Mbps が上限、TikTok は 9:16 で 4.5〜6 Mbps、Instagram Reels は 3.5 Mbps 推奨。Vimeo は YouTube より高めの 1080p で 10〜20 Mbps を推奨。OBS Studio でのライブ配信は 4500〜6000 Kbps が Twitch の上限、YouTube Live は 9000 Kbps まで可。映画館上映 (DCP) は JPEG 2000 で 250 Mbps と圧倒的に高ビットレートで、Web 配信とは別次元。ライブ配信を前提とする場合は CBR で安定したビット供給が、オンデマンド配信なら CRF + Two-pass が最適 — 本ツールで逆算したビットレートで実際にエンコードしたい場合は video-compress、現在の動画コンテナがどのコーデック・どのビットレートで収録されているかを先に確認したい場合は video-codec-info を組み合わせるのが定番です。