動画圧縮計算ツール

容量の上限が何を残すのか、解像度が何を要求するのかを算出します。ビットレートは正確な計算、解像度の判定は推奨値——このページは両者を分けたうえで、そのビットレートで 3 種類の 1080p 素材に対して実際に計測した結果を示します。

秒
MB
合計ビットレート
3,425 kbps
正確値
映像に残る分
3,297 kbps
音声 128 kbps を差し引いた後
1080p では
視聴可だが軟らかい
推奨値

25 MB を 1 分に配分すると、映像に 3,297 kbps 残ります。 余裕ある基準を満たす最も高い解像度は 720p です。 1080p が視聴可に留まる最も高い解像度です。

25 MB で通る上限

  • WhatsApp Video in chat (mobile) 16 MB
  • Gmail の実際 18 MB· base64 で約 +37%
  • Discord Free 20 MB
  • Gmail 25 MB
  • TikTok Android app 72 MB
  • X (Twitter) Standard 512 MB

このビットレートでの実測値

自前のエンコードによる VMAF。1080p、libx264 preset medium、計測日 2026-09-14。素材ごとに 1 クリップのみなので、これらは許容誤差ではなく相対的な位置として扱ってください——意味があるのは各値そのものではなく、その差です。

  • Screen recording
    ≥ 99.99VMAF
    この素材で計測したどのビットレートより高い（最上位は 835 kbps → 99.99）。外挿はしていません
  • Animation
    84.3VMAF
    実測値 3,232 kbps → 84.07 と 4,140 kbps → 87.68 の間
  • Camera footage
    86.3VMAF
    実測値 3,157 kbps → 85.61 と 3,878 kbps → 89.42 の間

計算式

容量と長さが決まれば答えはひとつで、それは意見ではなく厳密な上限です。計算ツールが「正確値」と示すものはすべて、以下の 2 行から出ています。

total kbps  = size_MiB × 8,388,608 × 0.98 ÷ seconds ÷ 1,000
video kbps  = total kbps − audio kbps
  • 8,388,608 は 1 メビバイトあたりのビット数です。アップロード上限はメガバイトと呼ばれながら実際にはメビバイトで運用されているため、1,000,000 で計算すると実際に適用される値より約 5% 大きい目標が出てしまいます。
  • 0.98 はコンテナと多重化のオーバーヘッド分です。MP4 では概ね 1–2% ですが、ここでは悲観側を確保します——避けたい失敗は、厳密な上限をわずかに超えることだからです。
  • 128 kbps は音声の既定の想定値、つまり妥当な品質のステレオ AAC です。音声は約 96 kbps を下回ると薄く聞こえ始めます。

解像度の基準値の出どころ

計算ツールがあなたの予算と比較している数値です。これらは実測ではなく推奨値です。公開されている H.264 のビットレート階梯——YouTube の推奨アップロードビットレートと Apple の HLS オーサリング仕様——を基に、全体を約 3 分の 1 引き下げています。それらの階梯はクリーンなマスターに対する 1 回目のエンコードを想定していますが、既存の MP4 を圧縮する場合は既に 1 度の非可逆圧縮を経た素材から始まるため、マスターより低いビットレートでも耐えます。意図的に保守的です。避けたい失敗は、実際には問題があるのに「画質は大丈夫」と伝えてしまうことです。

30 fps における解像度別 H.264 ビットレート基準値
解像度余裕あり視聴可
4K20,000 kbps12,000 kbps
1440p9,000 kbps5,500 kbps
1080p4,000 kbps2,000 kbps
720p2,200 kbps1,100 kbps
480p1,000 kbps500 kbps
360p600 kbps300 kbps

30 fps 基準です。同じ解像度でも 60 fps ならより多く必要になります。またフレームレートを下げるのは通常は誤った選択です——代償が動きに現れ、視聴者が最も気づく部分だからです。

何を計測したか、そしてなぜ単一のビットレートでは足りないか

18 回のエンコード：3 種類の 1080p 素材をそれぞれ 6 段階の画質設定で、libx264 preset medium、毎回オリジナルに対して VMAF を採点しました。計測日 2026-09-14。これをこのページに置く理由は、そのばらつきです——同じビットレートで 3 種類の素材が全く異なる位置に着地するため、ひとつの判定しか返さない計算ツールは、多くても 3 つのうち 1 つにしか真実を伝えていません。

Screen recording

計測範囲 389–835 kbps

  • 835 kbps99.99
  • 752 kbps99.99
  • 637 kbps99.98
  • 543 kbps99.97
  • 488 kbps99.71
  • 389 kbps96.92

Animation

計測範囲 1,945–10,864 kbps

  • 10,864 kbps94.86
  • 8,337 kbps93.76
  • 5,855 kbps91.42
  • 4,140 kbps87.68
  • 3,232 kbps84.07
  • 1,945 kbps73.94

Camera footage

計測範囲 2,051–8,406 kbps

  • 8,406 kbps97.98
  • 6,926 kbps96.62
  • 5,210 kbps93.74
  • 3,878 kbps89.42
  • 3,157 kbps85.61
  • 2,051 kbps75.44

このデータが扱っていない範囲（この上に主張を組み立てないために）：素材ごとに 1 クリップ、各 10 秒、すべて 1080p、すべて H.264。3 種類が全く異なる位置にあることを示すには十分ですが、個々の数値に許容誤差を付けるには不十分で、H.265 については何も語っていません。計算ツールはこれらの点の間を補間し、外側への外挿は行いません。

クイックリファレンス

よく使う容量とよく使う長さの組み合わせで、余裕ある基準を満たす最も高い解像度です。音声は 128 kbps を想定しています。最も多く尋ねられる組み合わせについて、計算ツールの答えをあらかじめ出したものです。

目標容量とクリップ長による最適な「余裕あり」解像度
容量15s30s1 min2 min5 min10 min
8 MB1080p480p360p———
10 MB1080p720p480p———
16 MB1080p1080p480p360p——
25 MB1440p1080p720p480p——
50 MB4K1440p1080p720p480p—
100 MB4K4K1440p1080p720p480p
200 MB4K4K4K1440p1080p720p

ダッシュは、その組み合わせではどの解像度も余裕ある基準を満たさないことを示します——容量に対してクリップが長すぎます。短く切るか、軟らかい結果を受け入れてください。

計算ツールについての質問

目標容量に対するビットレートはどう計算しますか？

容量（メビバイト）に 8,388,608 を掛けてビット数を出し、秒数で割り、さらに 1,000 で割ると kbps になります。音声ビットレートを引いたものが映像に残る分で、そこからコンテナのオーバーヘッド約 2% を差し引きます。計算はこれだけで、答えはひとつです——判断が始まるのは「そのビットレートで足りるのか」を問うところからです。

解像度の推奨は実測ですか、推定ですか？

推定であり、全体を通してそう明示しています。基準値は公開されている H.264 のビットレート階梯——YouTube の推奨アップロードビットレートと Apple の HLS オーサリング仕様——を約 3 分の 1 引き下げたものです。それらの階梯はクリーンなマスターへの 1 回目のエンコードを想定している一方、既存の MP4 の圧縮は既に 1 度の非可逆圧縮を経た素材から始まります。このページのビットレートの数値は計算であり、合否の判定は推奨です。

なぜ同じビットレートでも動画によって良し悪しが変わるのですか？

素材がビットレートの届く範囲を決めるからです。3 種類の 1080p 素材をそれぞれ 6 段階でエンコードし、18 本すべてに VMAF を付けました：3,300 kbps 付近では、画面録画はこの素材で計測したどのビットレートより上に位置し、アニメーションは 89 前後、手持ちの実写は 85 前後です。範囲の下端では差が 15 ポイント以上に広がります。単一の推奨ビットレートで 3 つすべてに応えることはできないため、このページは 3 つすべてを示します。

解像度を下げるべきか、画質設定を下げるべきか？

ほぼ常に解像度で、しかも感覚より早めに下げるべきです。画素数は 2 次元なので、720p は 1080p の約 44% の画素で済みます。したがって一段下げることは画質設定を絞るよりはるかに効き、しかも過圧縮によるブロックノイズや滲みを伴いません。動画が実際に見られる場所に解像度を合わせ、そのうえで画質を調整してください。

音声トラックは影響しますか？

短いクリップでは大きく影響します。2 MB 以内の 15 秒動画では合計で約 1,090 kbps しか使えず、128 kbps のステレオトラックは 1 フレーム目の前に約 12% を消費します。1 分を超えると丸め誤差に近づきます。ナレーションのないクリップなら、無音のステレオトラックを丸ごと運んでいないか確認してください——外すのは無料です。

なぜ 1 MB は 1,000,000 ではなく 1,048,576 バイトなのですか？

アップロード上限がそれで運用されているからです。プラットフォームや OS の大半はメガバイトと呼びながらメビバイトで計測するため、1,000,000 を使う計算ツールは実際に適用される上限より約 5% 大きい目標を示します——それはまさに、表示された上限を満たしているのにアップロードが失敗する差分です。

計算ツールは圧縮後のファイルサイズを正確に保証できますか？

いいえ。ビットレート予算は正確な計算ですが、動画の複雑さ、音声、コンテナのオーバーヘッド、エンコーダーの動作が変わるため、実際のファイルは推定値です。厳密な上限には、表示上限より数パーセント低い目標を使ってください。

なぜプラットフォームのアップロード上限より低く設定するのですか？

エンコード結果が指定サイズをわずかに超える場合があり、プラットフォームは上限でファイルを拒否するからです。少しの安全余裕がその差を吸収します。VidSmaller のプラットフォームプリセットは、表示上限より低い安全目標を使用しています。

元の解像度を保ったまま目標サイズにできますか？

その解像度と長さに十分なビットレートが残る場合に限ります。1080p が視聴可能なビットレートを下回るなら、1080p を維持するより 720p に下げる方が良好です。サイズ、長さ、解像度をすべて独立して固定することはできません。

この数値の裏付けとなる実測

計算を省く

よく突き当たる数値については、答えを算出済みで、圧縮ツールもその値にあらかじめ設定したページがあります。