あるクライアントが、バグの短縮画面を記録するように私に依頼しました。 キャプチャは 212 MB で 4 分間でした。これは、1 秒あたり 60 フレームの Retina ディスプレイの費用で、メール サーバーが 2 回バウンドしてからエラー メッセージの 25 MB の制限が、私が勝る必要がなかったと判断しました。 添付ファイルは Base64 エンコードされているため、ファイルは、ファイルが残されたよりも約 3 分の 1 大きくなります。 25 MB 未満である必要がありました。 録音は 6 MB、720p、音声なしで出力され、完全にシャープに見えました。バグの画面記録は、ほとんどが静的なページであり、カーソルが移動し、美しく圧縮されるためです。 役に立つ教訓は設定ではありませんでした。 これらのジョブはすべて同じ 3 行の計算であり、実行できれば推測をやめます。
tl;dr: 一定の速度の要素は品質目標であり、結果のサイズはフッテージがどの程度の動きを運ぶかに依存するため、品質レベルではファイル サイズは得られません。 ハード リミットを達成するには、それから逆方向に作業します。 1 秒あたりの目標ビットレートは、バイト単位の 8 バイト単位で、時間で割ったものを 1000 で割った値です。 次に、通常のビットレートがその数値の下にある解像度を選択します。 1080p から 720p を落とすと、どのスライダーよりも多くの節約ができ、オーディオをドロップする必要はありません。必要なのは、人々が予想以上に節約できます。 ザ・ ビデオコンプレッサー Toolz.dev では、自分のブラウザー タブで WebAssembly にコンパイルされた ffmpeg を介してエンコードを実行し、開始前の見積もりを表示し、ファイルをアップロードしません。
品質設定ではサイズが約束されないのはなぜですか?
ビデオを圧縮する最も一般的な 2 つの方法は、さまざまな質問に答えます。より良い結果をもたらす方法は、事前にサイズを教えてくれないものです。
ターゲット ビットレート モードは次のように述べています。1 秒あたり 2 メガビットを使用してください。 サイズは算術で正確に予測可能であり、品質は大幅に変化します。 タイトル カードとハンドヘルド ショットの雨のショットはどちらも 2 Mbps になるため、タイトル カードはほとんどを無駄にし、雨は濡れた砂利のように見えます。
定率係数 モードは言います: この品質を保持し、必要なビットを使います。 簡単なフレームは少しビットを獲得し、ハード フレームは多くのフレームを取得し、画像は最初から最後まで視覚的にも維持されます。 サイズは何でも構いません。
最新のエンコーダはすべて、ライブでストリーミングされていないものについては 2 番目のエンコーダを推奨しており、ここでコンプレッサーが使用するものです。 コストは、ボタンを押す前のページの数字が、その解像度と品質に対する典型的なビットレートから導き出された推定値であり、実際の数字が映像とともに移動することです。 静的なスクリーン録音は、通常、見積もりの半分に達します。 水が動くハンドヘルド映像は、その上に着陸する可能性があります。 紙吹雪、雪、風の葉、葉は、いずれもランダムなノイズに近く、ノイズは圧縮では何もできないため、見積もりを超えて 4 つを吹き飛ばします。
レベルを選ぶとき、CRF は何を選ぶのですか?
8 ビットの H.264 に対してスケールは 0 から 51 まで実行されます。ここで、0 はロスレスで 51 は見られません。 FFMPeg H.264 エンコーディング ガイド デフォルトは 23 に、正常な動作範囲はおよそ 17 から 28 に設定されます。 記憶に値するプロパティは、スケールが対数であることです。6 を変更すると、ビットレートがほぼ半分になるか、2 倍になります。 その 1 つの事実は、試す前に各レベルが何をするかを示しています。
CRF 26 と 27 の差は見えないのに対し、23 と 33 の差は全体のポイントであるため、コンプレッサーはスライダーではなく 3 つを提供します。
| レベル | H.264 CRF | VP9 CRF | オーディオ | それは何のためにあるのですか |
|---|---|---|---|---|
| 光 | 23 に記載しております | 31 | 160kbps | コピーとフッテージをアーカイブして、もう一度編集します。 視覚的に十分にほぼロスレス。 |
| バランス | 28 に指定されています | 36 | 128kbps | 普通の答え。 約半分の光量で、ラップトップ画面で違いを探す必要があります。 |
| 強い | 33 | 42 に指定されています | 96kbps | ハード制限に達します。 アーティファクトは詳細な映像に表示され始め、チャットのアップロードについては誰も気にしません。 |
VP9 の数値は別の尺度であるため、無関係に見えます。 ライト レベルの 31 は、まさに Google のようです Video On Demand の VP9 エンコーディングの推奨事項 1080p の目標品質としてリストし、その表の残りの部分はブックマークにしておく価値があります。720p の場合は 32、480p の場合は 33 または 34、4k の場合は 15。
より多くのスペースを節約し、品質が低いか、ピクセル数が少ないのはどれですか?
ピクセル数が少なく、余裕があり、それに近いものではありません。
解像度は 2 次元の量です。 1080p から 720p に移行しても 3 分の 1 の差はありません。207 万ピクセル減って 920 万まであるため、エンコーダは、単一の品質決定を下す前に説明するピクセル数が 56% 少なくなります。 ファイルは大まかに続きます。 4K から 1080P になると、4 分の 3 が削除されます。
これは、ツールの推定値からの典型的なビットレートを使用して、1 分間のクリップのソースの高さとレベルによって着陸するものです。 オーディオが含まれています。
| ソース | 光 | バランス | 強い |
|---|---|---|---|
| 4K (2160p) | 106MB | 61MB | 35MB |
| 1080p | 35MB | 20MB | 11MB |
| 720p | 20MB | 12MB | 7MB |
| 480p | 10MB | 6MB | 4MB |
それを間近で読んでください。 品質列を一歩下に移動すると、約 43% 節約できます。 解像度列を 1 段階下に移動すると、約 42% も節約できます。これは、3 度後に高品質のステップがなくなり、目に見えるアーティファクトが表示されるまでは、ほとんどの人が画面上で見ると、何も費用がかかりません。 Slack メッセージで表示される 1080p クリップが、幅約 400 ピクセルのボックスに表示されます。
試す順序: 視聴者が現実的に使用するものに解像度を落とし、品質をバランスよく保ち、まだ達成していない場合にのみ、品質を維持します。
8 MB のようなハード リミットをどのようにして着陸させるのですか?
逆に働きます。 計算全体は 1 行であり、学習に値する唯一のビデオ算術です。
# total bitrate (kbps) = target size (bytes) x 8 / duration (s) / 1000
#
# 8 MB, 45-second clip:
# 8,000,000 x 8 / 45 / 1000 = 1,422 kbps total
# minus 96 kbps of audio = 1,326 kbps for video
#
# 1080p strong is ~1,400 kbps video -> about 8.4 MB. Just over.
# 720p strong is ~800 kbps video -> about 5.0 MB. Comfortable.
#
# the equivalent single pass, if you have ffmpeg installed:
ffmpeg -i input.mp4 -c:v libx264 -crf 33 -preset fast \
-vf scale=-2:720 -c:a aac -b:a 96k \
-movflags +faststart -pix_fmt yuv420p output.mp4
3 つのことが、これを実際に信頼できるものにします。
- ヘッドルームを出る。 制限の 80% を目指します。 CRF はサイズの目標に達していません。オーバーシュートする時間は、ファイルを送信する時間です。
- 電子メールで送信される場合は、エンコーディングのオーバーヘッドを数えます。 Base64 は、入力の 24 ビットごとに 4 文字を表します。 RFC 2045ということで、アタッチメントがワイヤーで 3 分の 1 膨張します。 25 MB のメールボックスの制限は、実際のファイルの約 18 MB です。
- 覚えている番号を信用しないでください。 Discord の無料アップロード制限は 8 MB、25 MB、10 MB、20 MB で、2026 年 8 月現在です。 Gmail は 25 MB で何年も保たれています。 WhatsApp は、あなたが送信したものを何でも再圧縮します。 必要な日に制限を確認してから、算術を行います。
クリップが表示したいものよりも長い場合は、クリップを絞るよりもカットする方がよいでしょう。 期間を半分にすると、サイズが半分になると、設定が一致することはありません。 ザ・ ビデオトリマー カットがキーフレームの近くに着地すると、再エンコードせずに範囲を取り出し、結果は半分のサイズでバイト単位の映像になります。
フレームレートの低下は役に立ちますか?
あなたが思っているよりも少なく、リストにある他の何よりも悪く見えます。
その理由は、連続するフレームが互いに圧縮されているためです。 ビデオ コーデックは 1 つのフル フレームを保存し、次にその違いを説明するため、60 fps クリップのフレーム 31 は、フレーム 30 とほぼ同じであるため、ほぼ自由になります。 捨てても、あなたが想像したビットは保存されません。 通常の速度では、節約は無料というよりは直線に近いため、60 fps から 30 fps で半分ではなく 3 分の 1 を離し、30 fps から 15 fps でカメラの動きに見えるように見える。
正しい呼び出しである場合は 2 つあります。 ほとんど静的コンテンツの画面録画は、15 fps で何も判読できません。これは、通常、制限を下回ろうとするために最も努力している場合に限ります。 そして、あなたがページのアニメーションに変換している映像で、視聴者が動きを見ていないほど動き、12 ～ 15 fps で生き残る。
人物やカメラが動いている場合は、フレーム レートをそのままにして、代わりに解像度を下げてください。
オーディオは生き残るべきですか？
音声は無料ではないので、音声の目的を尋ねます。
128 kbps のオーディオを使用した 10 分間の録音では、1 ビットになる前に 9.6 MB のサウンドが再生されます。 そのオーディオが、部屋のハム音のあるサイレント スクリーン キャプチャ、または置き換える音楽、またはすでに書き起こした音声トラックである場合、それをドロップすることは、最も簡単に節約できるため、視聴者に費用はかかりません。 コンプレッサーにはまさにそのためのスイッチがあり、それは通過します -an オーディオ ストリームを完全に省略します。
音が重要な場合、レベルは 160 から 128 から 96 kbps に低下します。これは、従来のポイントです。 96 Kbps AAC は、音声に適していて、音楽にやさしいほどに薄いです。 ファイルとして、ファイルとして文字起こしや編集だけをしたい場合は、 オーディオエクストラクター ビデオに触れずにトラックを引き出します。 オーディオコンバーター 独自の条件で再エンコードします。
1 つの詳細が人々を惹きつけます。 オーディオ トラックのないビデオは、ほとんどのプレーヤーで静かに再生され、トラックがミュートになると予想されるいくつかの古いモバイル ブラウザーでは自動再生に失敗します。 クリップが Web ページに入っている場合、8 kbps のサイレント トラックは、現在出荷されているすべてのブラウザーがビデオ専用の MP4 を正しく処理しますが、何もないよりも安全な場合があります。
WebM は待つ価値がありますか?
ファイルを開く人に完全に依存します。
WebM コンテナー内の VP9 は、H.264 よりも約 4 分の 1 小さく、同等の目に見える品質で着陸します。 これは本当の利益であり、ブラウザがそれを再生できるという唯一の要件であるあなたのサイトでは、通常、WebM の方が優れたファイルです。 Chrome、Firefox、Edge は 10 年間 VP9 をサポートしており、Safari はバージョン 14 以降をサポートしています。
費用は 2 回表示されます。 VP9 エンコーディングは X264 よりも遅く、ブラウザーではかなり遅く、1 つの詳細がコマンドを実行する人を手で実行します。VP9 は、ビットレートが明示的にゼロの場合にのみ、品質目標を達成します。 過ぎる -crf 36 それ自体で、エンコーダは、代わりにデフォルトのビットレートを静かに使用し、あなたを無視します。 必要です -crf 36 -b:v 0、これは、ツールが送信するものです。
2 番目のコストは、ブラウザ以外のすべてです。 チャット アプリ、CMS アップロード フィールド、ビデオ エディター、パワーポイント、ファイル マネージャーのプレビュー ペイン、クライアントの電話: 多くは MP4 を受け入れ、WebM で肩をすくめます。ファイルが人に送られる場合は、H.264 で MP4 を送信します。 あなたがコントロールするページに入っている場合、webm. 同じ分割がフォーマットの問題全体を通過します。 レマックスガイド 変換側からカバーします。
圧縮された MP4 が時々再生を拒否するのはなぜですか?
インデックスが最終的にどこにあるかという理由で、これは絶対に忘れてはならない唯一のフラグです。
MP4 には、すべてのフレームがどこから始まるかを説明する目次が表示されます。 通常、エンコーダは、そのすべてを検出して、ファイルの最後にテーブルを書き込むときに、そのすべてを検出します。 問題ないディスクからの再生に。 HTTP 経由で配信されると、プレーヤーはファイル全体を取得するまで開始できないことを意味します。そのため、チャット アプリまたは CMS の 40 MB のビデオがそこに座って、ダウンロード中は何もせずに、ダウンロードを開始します。
-movflags +faststart 2 回目は、完成したファイルを渡し、そのテーブルを前面に移動します。 エンコードに時間がかかり、1 秒後にビデオが再生されます。 コンプレッサーが生産するすべての MP4 は、それを備えています。
そのコマンドには、サイズよりも互換性を保つために、さらに 2 つのフラグがあります。 -pix_fmt yuv420p 4:2:0 のクロマ サブサンプリングを強制します。4:2:2 または 4:4:4 の MP4 が有効で、ハードウェア デコーダの長いリストでのプレイを拒否するためです。 そして、スケールフィルタが書かれています scale=-2:720 というより scale=-1:720、H.264 が偶数ピクセルの寸法と必要なため、 -2 計算された幅を偶数に丸めます。 奇数の幅を求めると、エンコードは「幅が割れない」で失敗し、近いものにスケーリングするのではなく、2 で割り切れません。
2 回圧縮すると、なぜさらに悪く見えるのでしょうか。
非可逆圧縮は非対称であるため、世代の損失であり、人々が予想するよりも急激です。
最初のエンコードは、目を見逃すことはないと判断し、エッジのわずかなブロック、滑らかな勾配、高コントラストの周りで鳴り響く、独自のアーティファクトを残します。 2 番目のエンコードは、アーティファクトが写真ではないことを知る方法がありません。 保存する価値のあるコンテンツとしてそれらを扱い、それらを説明するビットを使用して、独自にそれを追加します。 同じクリップで 3 ラウンドのバランスの取れた圧縮は、ファイル サイズが大きくなると、1 ラウンドの強力な圧縮よりも悪く見えます。
ですから、実際のルールは短いです。 オリジナルから圧縮するときは、作成したコピーからは絶対に圧縮しないでください。 軽いアーカイブ バージョンと小さなバージョンの両方を送信する必要がある場合は、両方をソースから作成します。 ファイルがアップロード時に再圧縮するプラットフォームをすでに通過している場合は、そのほとんどがダウンロードされます。ダウンロードしたものは、すでに第 2 世代として扱われます。
これは、支配する算術と同じです。 画像圧縮 JPEG が繰り返し保存した理由は、泥に変わります。 PDF コンプレッサー ドキュメント全体ではなく、ドキュメント内のイメージで動作します。
ファイルはあなたのマシンから離れますか?
いいえ、ツールの使用目的を変更するビデオの場合。
エンコードが通過する ffmpeg が WebAssembly にコンパイルされた、ブラウザータブで実行します。 ファイルはディスクからページ メモリに読み込まれ、そこにエンコードされ、ダウンロードとして返されます。 DevTools を開き、ネットワーク パネルに切り替えて何かを圧縮して、次のようにします。No Request はビデオを運びます。
3 つの結果が続きます。
何もアップロードされないので、何も保持されません。 コピーが作成されていないため、保持ポリシーが削除されるのを待っているサーバー上にコピーはありません。 未発表の製品のデモ、NDA の下の映像、またはサードパーティのアップロードに同意しない人がいるものの場合、それは使用可能かどうかの違いです。
制限はブラウザーであり、計画ではありません。 ファイル全体がタブ メモリに入り、ページは最大 500 MB まで受け入れ、1 回のパスを 30 分で制限します。4 メガバイトのエンジン ダウンロードと 2 分間のエンコーディングの後にファイルを選択すると、両方がチェックされます。 キューも透かしもアカウントもサイズ階層も購入できません。
最初の実行は遅いです。 FFMPeg WebAssembly は、数秒かかるダウンロードを一度にバンドルし、その後キャッシュします。 ツールは、ページが開くときではなく、最初の圧縮でそれをロードするので、ページ自体は高速のままです。
デスクトップ エンコーダが適切なツールになるのはいつですか?
上記の数値が制約ではない場合。 ブラウザー タブは妥当なエンコーダであり、ビデオ パイプラインは不適切であり、どこに線が落ちるかを明確にする価値があります。
500 MB を超えるファイルまたは 30 分以上のクリップでネイティブにします。ここで、タブ メモリが実際の制限です。 シェル内のループを 40 クリップで任意のインターフェイスで 40 回のトリップに打ち勝つため、バッチでネイティブにします。 1 つの CRF パスでは約束できない、正確なサイズを達成するために 2 パス エンコーディングが必要な場合は、ネイティブにしてください。 GPU は、WebAssembly が 4 分かかることを 20 秒で実行します。
ラップトップで、何もインストールしたり、見知らぬ人に映像を渡さずに、次の 5 分で制限を下回る必要がある 1 つのクリップの場合、ブラウザは遠く離れた場所でより高速なパスです。 それが仕事です コンプレッサー と並んで構築されています。 コンバーター フォーマットの変更と 画像圧縮機 同じ問題に対して、1 次元下にあります。
