動画のビットレートの目安。解像度別の推奨値とファイルサイズの計算方法

ビットレートとは何を決める数値か

書き出し設定の解像度とフレームレートは、迷わず決められます。撮ったとおりの4K、タイムラインどおりの30fpsと、根拠が手元にあるからです。ところがビットレートの欄には、その根拠がありません。10Mbpsなのか、50Mbpsなのか。前回と同じ数値をなんとなく入れて書き出している人が、少なくないはずです。

この欄に入れるビットレートは、動画の1秒間に割り当てるデータ量です。大きくするほど圧縮が緩み、画質は上がり、そのぶんファイルは重くなります。そして1秒あたりの量なので、尺を掛ければファイル全体の大きさになります。画質と容量の両方を、この一つの数値が同時に決めているわけです。

だから「目安」と呼べる数値にも、二つの側面があります。画質が足りるかという側面と、容量が扱える範囲に収まるかという側面です。前者はプラットフォームの推奨値でほぼ答えが出ます。後者は、掛け算を一つ覚えれば自分で出せるようになります。

単位はbps(ビット毎秒)

ビットレートの単位はbps(bits per second)です。1秒あたりに使うビット数を表し、1,000bpsが1kbps、1,000kbpsが1Mbpsです。動画の設定では、映像に主にMbps、音声にkbpsが使われます。

紛らわしいのは、ファイルサイズの単位との関係です。ビット(bit)とバイト(Byte)は別物で、8ビットが1バイトにあたります。ファイルサイズのMB(メガバイト)はバイトを、ビットレートのMbps(メガビット毎秒)はビットを数えています。同じ「メガ」でも、数えているものが8倍違います。この「8」は、後半の容量計算にそのまま出てきます。

映像、音声、総合の3種類がある

一口にビットレートと言っても、書き出し設定に関わる値は3つあります。

• 映像ビットレート：映像トラックに使うデータ量です。書き出し設定で入力する中心はこれで、目安として紹介される数値も通常こちらを指します。
• 音声ビットレート：音声トラックに使うデータ量です。単位はkbpsで、映像より2〜3桁小さい値になります。
• 総合ビットレート：映像と音声の合計です。オーバーオールビットレートとも呼ばれ、ファイル全体の容量を決めるのはこの値です。

以降、単に「ビットレート」と書くときは映像ビットレートを指します。容量の計算に使うのは総合のほうです。

解像度やフレームレートとの関係

そもそも、なぜ目安は解像度ごとに分かれているのでしょうか。解像度は1枚の絵の画素数、フレームレートは1秒に描く枚数です。どちらが増えても、1秒間に描くべき情報の量が増えます。フルHD(1920×1080)と4K(3840×2160)では画素数がちょうど4倍、30fpsと60fpsでは枚数が2倍です。

描く情報が増えたのにビットレートが同じなら、画素1つあたりに使えるデータは減ります。圧縮が強くかかり、平坦な部分がブロック状に割れたり、暗部がざらついたりします。逆に、低い解像度へ過剰なビットレートを与えても、描くべき情報がそもそも少ないため、画質は途中で頭打ちになります。ビットレートの目安が解像度とフレームレートの組み合わせごとの表になっているのは、この釣り合いを取るためです。

解像度別のビットレートの目安

YouTube公式の推奨アップロードビットレート(SDR)

具体的な数値は、プラットフォーム自身が公開している推奨値がいちばん信頼できます。YouTubeが公開している推奨アップロードビットレート(SDR)は次のとおりです。

解像度	標準フレームレート(24/25/30fps)	高フレームレート(48/50/60fps)
2160p(4K)	35〜45Mbps	53〜68Mbps
1440p(2K)	16Mbps	24Mbps
1080p(フルHD)	8Mbps	12Mbps
720p	5Mbps	7.5Mbps
480p	2.5Mbps	4Mbps
360p	1Mbps	1.5Mbps

あわせて、コンテナはMP4、映像コーデックはH.264、音声はAAC-LC(サンプルレート48kHz)が推奨されています。この表はSDRの値で、HDRには別の推奨値が用意されています。HDRで書き出す場合はYouTubeのヘルプで確認してください。

表から読み取れる圧縮の性質

数値を縦横に見比べると、規則性が見えてきます。高フレームレート(枚数が2倍)の推奨値は、標準の2倍ではなく1.5倍前後です。1080pは8Mbpsに対して12Mbps、720pは5Mbpsに対して7.5Mbps。動画の圧縮は前後のフレームの似た部分を使い回すため、枚数が2倍になっても、記録すべき差分は2倍にならないからです。一方で、画素数4倍の4Kの推奨値は1080pの4倍から5倍あまりで、こちらはほぼ画素数なりに増えています。同じ「重くする」でも、解像度を上げるほうがフレームレートを上げるより、ずっと高くつきます。

音声ビットレートの目安

YouTubeの推奨値では、音声はモノラル128kbps、ステレオ384kbps、5.1chサラウンド512kbpsです。ステレオの384kbpsをMbpsに直すと約0.4Mbps。1080pの映像8Mbpsと比べて5%ほどにすぎません。仮にステレオを128kbpsまで下げても、映像と合わせた総量は3%しか減りません。音声を削ってもファイルはほとんど軽くならないので、ここを節約する理由がありません。迷ったら推奨値どおりに設定して、音の情報はそのまま残しておくのが得策です。

ほかのプラットフォームは公式の推奨値を確認する

配信サービスやSNSにも、それぞれ推奨値や上限が定められています。数値はサービスごとに違ううえ、たびたび改定されます。まとめ記事の古い数値を写すより、「サービス名 推奨ビットレート」で公式ヘルプを引くのが確実です。ライブ配信では、画質のための推奨値だけでなく、サービス側が受け入れる上限が別に定められている場合もあるので、両方を確認してから設定してください。

ファイルサイズはビットレートから計算できる

表のとおりに書き出せば、画質の側はほぼ片づきます。残っているのは容量の側です。その動画、何GBになるのか。書き出しが終わってプロパティを開くまで分からない、と思われがちですが、書き出す前に計算できます。

「ビットレート×秒数÷8」で見積もる

見積もりの式は一行です。

総合ビットレート(Mbps) × 尺(秒) ÷ 8 ≒ ファイルサイズ(MB)

8で割るのは、ビットレートがビットを、ファイルサイズがバイトを数えているためです(8ビット=1バイト)。コンテナの管理情報などで実際の値は少し上下しますが、見積もりとしては十分な精度が出ます。

フルHD10分の動画で試す

1080p30fpsの動画を、表のとおり映像8Mbps、音声384kbpsで書き出すとします。総合ビットレートは約8.4Mbps、尺10分は600秒です。

8.4 × 600 ÷ 8 = 630MB

重いほうの例も出します。4K60fpsの30分の動画を、推奨レンジ内の60Mbpsで書き出すなら(音声を足しても誤差の範囲です)、

60 × 1,800 ÷ 8 = 13,500MB(約13.5GB)

どちらも、書き出しボタンを押す前に分かる数字です。

逆算すると使えるビットレートも出る

式は逆向きにも使えます。納品先から「4GB以内で」と言われた20分の動画なら、4,000MBをビットに直して秒数で割ります。

4,000 × 8 ÷ 1,200 ≒ 26.7

総合で26Mbpsあまりまで使える計算です。1080pなら推奨値の8〜12Mbpsに対して余裕がたっぷりあります。4Kでは推奨レンジの下限35Mbpsに届かないので、尺を分けるか、容量の上限を交渉するか、書き出す前に相談を始められます。

納品前に容量と転送時間が読める

この計算で先に読めるのは、容量だけではありません。回線速度の単位もビットレートと同じbpsなので、転送時間まで同じ土俵で見積もれます。

さきほどの13.5GBは、ビットに直すと108,000Mbitです。実効100Mbpsの回線なら単純計算で1,080秒、およそ18分。実効20Mbpsの回線なら90分かかります。しかもこの時間は、アップロードする自分の側と、ダウンロードする相手の側の両方で発生します。

納品日の夕方にこの見積もりがあるかないかで、夜の過ごし方が変わります。「書き出しに1時間、アップロードに20分、先方の回線次第でダウンロードにも同じくらい」と読めていれば、設定の段階で手を打てます。計算の結果が数十GBだと分かったときの渡し方は、容量の大きい動画を送る方法に別途まとめています。

用途で目安は変わる

同じ完成データでも、YouTubeに上げるのか、クライアントに納めるのか、手元に残すのかで、選ぶべき数値は変わります。分かれ目は、その動画が「見るためのもの」か「この先も使うためのもの」かです。

公開用はプラットフォームの推奨値でよい

YouTubeをはじめ、多くのプラットフォームは、アップロードされた動画を自社の配信用形式に再エンコードします。視聴者に届くのはアップロードした元ファイルではなく、変換後のデータです。推奨値は「変換の元として十分な品質」の目安なので、そこから大きく盛っても、増えたぶんがそのまま視聴画質に反映されるわけではありません。確実に増えるのは書き出し時間とアップロード時間のほうです。公開用は推奨値どおりで書き出すのが、品質と時間の釣り合いの取れた選択です。

納品用は先方の指定と使い方で決まる

クライアントワークでは、まず納品仕様の指定を確認します。放送や広告の案件ではコーデックからビットレートまで指定されていることが多く、その場合は指定に従うだけです。

指定がないときに確認したいのは、相手がそのファイルを「見る」のか「使う」のかです。試写や確認用なら、YouTubeの推奨値程度で画質は足り、軽いぶん相手も受け取りやすくなります。相手側でテロップを足す、再編集する、切り出して別の媒体に使うなら、事情が変わります。納品ファイルを元にもう一度エンコードが走り、劣化が二重にかかるからです。素材として使われる前提のファイルは、視聴用よりビットレートを高めに取っておくのが安全です。

アーカイブ用は高めに残す

書き出しで捨てた情報は、後から戻せません。低いビットレートで書き出した動画を高いビットレートで書き出し直しても、容量が増えるだけで、失われたディテールは復元されないからです。逆方向はいつでもできます。高品質のマスターが1本あれば、公開用の軽い版は必要になったときに作れます。この先も使う可能性のある完成データは、保管容量が許す範囲でビットレートを高めに取っておくのが定石です。

CBR(固定)とVBR(可変)の違い

書き出し設定には、ビットレートの数値の近くにもう一つ選択肢があります。レート制御をCBRにするか、VBRにするかです。

CBR(固定ビットレート)の仕組み

CBR(固定ビットレート)は、映像の内容にかかわらず常に一定のデータ量を使い続ける方式です。静止画に近いシーンにも動きの激しいシーンにも同じ量を割り当てるため、データの使い方としては無駄が出ます。その代わり、1秒あたりに流れる量をいつでも予測できます。ライブ配信のように、限られた帯域の回線へリアルタイムに送り出す用途では、この予測のしやすさが優先されます。

VBR(可変ビットレート)の仕組み

VBR(可変ビットレート)は、動きの激しいシーンに多く、変化の少ないシーンに少なくと、内容に応じてデータ量を配分する方式です。同じ平均ビットレートで比べれば、CBRより画質の面で有利です。ファイルとして書き出して渡す動画、つまりライブ配信以外のほとんどの用途では、VBRが基本になります。

容量の計算はどちらでも成り立つ

配分が変わるVBRだと、さきほどの容量計算が崩れそうに思えます。実際には、VBRで設定する平均(ターゲット)ビットレートを式に入れれば、見積もりとして十分機能します。CBRなら、計算はほぼそのまま実測と一致します。どちらを選んでも、「ビットレート×秒数÷8」は使えます。

ビットレートを上げても画質が上がらない場合

元素材の情報量が上限になる

「高いほど高画質」が成り立つのは、元素材にまだ情報が残っている間だけです。圧縮は元の情報をどこまで保つかという処理なので、元素材が持っていない情報は、ビットレートをいくら盛っても現れません。1080pで撮った素材を4Kの45Mbpsで書き出しても、ディテールは1080pのまま、容量だけがおよそ4倍になります。一度書き出した動画や強く圧縮された素材を編集し直す場合も同じで、すでに失われた情報が仕上がりの上限になります。

画質を決めるのはビットレートだけではない

同じビットレートでも、条件によって仕上がりは大きく変わります。

• コーデック：新しい世代のコーデックほど、同じ画質をより少ないデータ量で実現します。ただし、納品先や再生環境が対応しているかの確認が先です。
• 被写体の動き：画面全体が動き続ける映像(手持ち撮影、紙吹雪、水面など)は前後フレームの使い回しが効きにくく、同じビットレートでも破綻しやすくなります。
• ノイズ：高感度撮影のノイズは毎フレーム変わるランダムな情報なので、圧縮と相性が最悪です。ノイズの多い素材はビットレートを余計に消費します。撮影時の露出設計や編集でのノイズ処理が、結果としてビットレートの節約になります。

数値の欄だけを上下させて悩むより、素材の状態とコーデックを含めて考えるほうが、同じ容量でよい画にたどり着けます。

迷ったときの決め方

書き出し画面のビットレートの欄に戻ります。入れる数値は、この順で決められます。

1. 公開先が決まっているなら、その公式推奨値。YouTubeなら上の表、ほかのサービスは公式ヘルプを確認します。
2. 納品なら、先方の指定が最優先。指定がなければ、見るためのファイルか、素材として使うためのファイルかを確認して決めます。
3. 決めた数値に尺(秒)を掛けて8で割り、容量を先に出す。渡し方と転送時間まで見積もり、無理があれば数値か段取りを直します。

案件ごとに映像の中身は違っても、この手順は変わりません。容量と時間が書き出す前に読めていれば、ビットレートの欄で手が止まることは、もうないはずです。