初めてクライアントの画面録音を変換したとき、私はそれをみんなと同じようにしました。MOV をコンバーターに落とし、11 分待ち、MP4 を送信しました。 ファイルは 40% 小さく、著しく柔らかくなり、クライアントはデモのテキストがファジーに見える理由を尋ねました。 答えは、そもそも変換する必要は何もないということでした。 その MOV 内のビデオは、すでに H.264 であり、MP4 が保持するものです。 11 分間の再エンコードにより、品質が失われ、約 2 秒でバイト単位のファイルが生成されました。 それがその背後にある全体的なアイデアです ビデオコンバーター で Toolz.dev、使用するツールを理解する価値があります。
tl;dr: ほとんどの MOV ファイルには、すでに MP4 に含まれる H.264 ビデオと AAC オーディオが含まれているため、それらを変換するのに再エンコードはまったく必要ありません。 ストリームは、remuxing というプロセスである新しいコンテナーにコピーされます。 ピクセルがデコードまたは再圧縮されないため、数分ではなく数秒かかり、何も失うことはありません。 ツールズ ビデオコンバーター デフォルトでコピーし、フォーマットが本当に必要な場合にのみ再エンコードし、ブラウザー タブ内の WebAssembly にコンパイルされた ffmpeg を介して実行されるため、ビデオはアップロードされません。
コンテナとは何ですか?なぜ重要なのですか?
ビデオ ファイルには 2 つのレイヤーがあり、ビデオ変換について混乱を招くものはほとんどすべて、それらを混同することによって生じます。
ザ・ コンテナ ラッパーです。 ストリームを保持し、どのくらいの長さか、各フレームが開始される場所、オーディオ トラックがどの言語にあるか、どのサムネイルを表示するかを記録します。 MP4、MOV、WebM、AVI、MKV はコンテナです。 ファイルの拡張子は、ビデオではなくコンテナーに名前を付けます。
ザ・ コーデック 内部の圧縮です。 H.264、H.265、VP9、AV1 が画像を圧縮します。 AAC、OPUS、MP3、FLAC がサウンドを圧縮します。 コーデックは、ファイルが特定のデバイスで再生されるかどうかを決定するものであり、変更に時間がかかるものです。
この 2 つのアイデアを分けると、有用な質問は「これは何の形式ですか?」でなくなり、「どのレイヤーを変更するの?」になるのは、コンテナーの変更は安価です。 コーデックの変更は、費用がかかり、損失が大きいです。 それらを区別しないツールは、毎回、安価な仕事に対して高額な操作を請求します。
MOV が MP4 にほぼ瞬時に移行するのはなぜですか?
MOV と MP4 は近親者だからです。 ファイル形式は、MP4 が構築された ISO ベース メディア ファイル形式の基礎となったため、2 つのコンテナーはほぼ同じ方法でデータを整理します。 通常、その中のストリームは同じストリームです。iPhone の録音、Mac のスクリーン キャプチャ、DSLR クリップ、プレミア エクスポートはすべて、通常、AAC オーディオを使用して H.264 ビデオを生成します。これを .mov または .mp4 でラップします。
つまり、変換は レマックス: 各ストリームの開始と終了を読み、それらのバイトを新しいコンテナに書き、新しいインデックスを作成します。 フレームはデコードされません。 ピクセルは調べられません。 出力は、別のラッパー内の同じビデオ データであり、デコードされたフレームがビットごとに同一であるという厳密な意味での損失がありません。
実際には、ビデオ データが変更されなかったために、2 分間のクリップが 1 分以上ではなく 1 秒以上で終了し、ファイル サイズがほとんど動かないことを意味します。 このジョブに数分かかり、小さなファイルを返すコンバーターが再エンコードされ、サイズのドロップはもはやあなたが持っていない品質です。
ここに各パスが適用されるときがあります。
| ソース | 対象 | 何が起こるか | 速度 | 品質コスト |
|---|---|---|---|---|
| MOV (H.264/AAC) | mp4 | Remux、ストリームのコピー | 秒 | なし |
| MP4 (H.264/AAC) | 動きます | Remux、ストリームのコピー | 秒 | なし |
| MOV または MP4 | ウェブ | 再 -VP9/OPUS にエンコード | 分 | 一部、設定によって異なります |
| どんなビデオでも | GIF | 再 -エンコード、パレットは256色に縮小 | 分 | 厳しい、設計上 |
| GIF | mp4 | 再 -H.264 にエンコード | 秒から1分 | マイナー、通常は見えない |
いつ再エンコードする必要がありますか?
3 つのケース、3 つだけ。
ターゲット コンテナーはコーデックを保持できません。 WebM は、ビデオは VP8、VP9、AV1 を受け入れます。Vorbis またはオーディオの OPUS です。 H.264 は受け付けていません。 したがって、MP4 から WebM への変換は常に実際の変換であり、リアルタイムで実行されます。
ソース コーデックは、H.264 ラッパーでは H.264 ではありません。 カメラからの ProRes MOV、DV キャプチャ、古い DivX AVI: MP4 が技術的には処理できるコーデックを保持しますが、ほとんどのプレイヤーは拒否します。 それらを変換するということは、デコードと再圧縮を意味します。
意図的に絵を変えています。 解像度を下げ、ビットレートを落とし、フレーム レートを変更します。 ビデオを再圧縮せずに小さくする方法はありません。そのため、ファイルの縮小と形式の変更とは別の仕事です。 そのために、 ビデオコンプレッサー圧縮と変換が異なる操作であるという理由だけで、人々が合理的に混乱するのは、まさにそのためです。
なぜ GIF に変換するのが、それよりもはるかに悪いのでしょうか。
GIF は、画像全体に対して最大 256 色を保持します。 それが、フォーマットの定義上限です。 GIF89A 仕様 1989 年に、どのエンコーダでも回避できます。 したがって、ビデオから GIF へのすべての変換では、ソースに含まれる 1,670 万色のうち 256 色を選択する必要があります。
フレームごとに素朴に行われ、各フレームは独自の最高の 256 を選択します。 その結果、同じシャツが連続したフレームでわずかに異なる色になり、全体の画像が這ってきらめくように見えます。 これは、ビデオから GIF への出力に関する最も一般的な不満の 1 つであり、フレームごとのパレットの完全なアーティファクトです。
修正は 2 パス エンコードです。最初にクリップ全体をスキャンし、そのすべてを処理するパレットを 1 つ作成してから、その共有パレットに対してすべてのフレームをエンコードします。 色が動かなくなったため、クロールが消えます。 Toolz コンバーターは両方のパスを実行します。そのため、GIF はシングルパス ツールよりも時間がかかり、かなり安定しています。
2 つ目の驚きはサイズです。 GIF は、フレーム間の違いではなく、フレーム全体を保存します。最新のビデオ コーデックを効率的にする動き補償はありません。 MP4 として 400 KB の 5 秒のクリップは、GIF として通常 4 MB になります。 これは、人々が認識しているよりも頻繁に行う価値のある変換につながります。
代わりに gif を MP4 に変換する必要がありますか?
ほとんどいつも、そうです。 H.264 と同じアニメーションは、通常、10 分の 1 のサイズで、大きな GIF が失速したりスロットルされたりするモバイル ブラウザーでインラインで再生され、ハードウェア デコードをサポートして電話機を加熱しないようにします。 すべての主要なソーシャル プラットフォームは、アップロードした GIF を、まさにこれらの理由でビデオに静かに変換します。これは、どの形式が仕事に適しているかについての合理的なシグナルです。
1 つの詳細によって、変換がまったく機能するかどうかが決まります。 H.264 は、平等なピクセル寸法を必要とします。 標準 クロマ サンプリングを組織し、GIF には奇妙なものが含まれていることがよくあります。601 ピクセル幅の GIF は完全に正常です。 エンコーダの不思議な寸法が、不可解なメッセージで完全に失敗するか、フレームを静かに埋めます。 ここでのコンバーターは、エンコードする前にサイズを最も近い偶数に切り捨てます。これは、誰も見ることができない 1 ピクセルのトリミングと、ファイルとエラーの違いです。
ビデオはどこかにアップロードされますか?
いいえ、これは、使い方を変える部分です。 変換が実行されます ffmpeg が WebAssembly にコンパイルされた、ブラウザーのタブ内で実行しています。 ファイルはディスクからページ メモリに読み込まれ、そこに変換され、ダウンロードとして返されます。
これには 3 つの実際的な結果があります。
- 何もあなたのマシンから離れません。 DevTools を開き、ネットワーク パネルに切り替え、ファイルを変換して見る: いいえ リクエストはビデオを運びます。 NDA、未発表の製品デモ、サードパーティのアップロードに同意しなかった人が含まれているものは、使用可能かどうかの違いです。
- キューもサイズキャップもありません。 他の人の仕事の後ろで待っているわけではありません。また、計画では 100 MB に制限されます。 本当の制限は、ブラウザー タブのメモリです。通常のラップトップでは、数百メガバイトのファイルを快適に処理します。
- 最初の実行は、他の実行よりも遅いです。 FFMPeg WebAssembly バンドルは、数秒で 1 回ダウンロードする必要があります。 その後、キャッシュされ、その後の変換がすぐに開始されます。
取引は正直です。専用のエンコーダを備えたサーバーは、非常に大きなファイルで高速になります。 ほとんどの人が変換するクリップでは、アップロードとダウンロードの往復には、エンコードの保存よりも時間がかかります。
どの設定が違いますか?
Remux の場合、何もありません。 何も再決定されていないため、構成するものは何もありません。
再エンコードの場合は、2 つ。
決議 他のどの設定よりも多くのことを行います。 幅と高さを半分にすると、ピクセル数が 4 分の 1 になり、ファイルは大まかに続きます。 1080p から 720p に移行することは、利用可能な最も効果的な変更点だけであり、電話機の画面では違いがわかりません。
ビットレートまたは品質目標 もう一方です。 ほとんどのツールは、これを数値ではなく高品質のスライダーとして公開しています。これは正しい呼び出しです。固定ビットレートは単純なシーンでビットを無駄にし、複雑なシーンを飢えさせますが、品質のターゲットは各シーンに必要な分を使います。
フレーム レートは、人々が手を伸ばす 3 番目のレバーであり、通常はそうすべきではありません。 30 fps から 15 fps を落とすと、フレームは半分になりますが、動きが目に見えて動揺し、とにかく連続するフレームが互いによく圧縮されるため、解像度の変更よりも節約できます。
# What a remux looks like at the command line. -c copy is the whole trick:
# copy the streams, do not decode them.
ffmpeg -i input.mov -c copy output.mp4
# Compare to a real conversion, which decodes and re-compresses every frame.
ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4
最初のコマンドは、ファイルを読み取るのにかかる時間で終了します。 2 つ目は、ビデオが複雑である限りかかります。 使用する価値のあるブラウザーベースのコンバーターは、内部的に同じように区別されます。 ビデオコンバーター します。
コンテナが変更されると、オーディオはどうなりますか?
Remux では、何もありません。 AAC トラックは、ビデオとともにバイトごとにコピーされます。そのため、MOV から MP4 への変換ではサウンドを劣化できません。同じ圧縮オーディオ データが新しいラッパーに入ります。
再エンコードでは、ターゲットに依存します。 WebM は AAC を運ぶことができないため、オーディオは Opus に再圧縮されます。これは、すでに損失の多いオーディオに適用される不可解なステップです。 スピーチではほとんど聞こえず、シンバルのように高周波のディテールがたくさんある音楽では時折聞こえることもあります。
必要なのはオーディオだけである場合があります。 撮影されたインタビューは、ポッドキャストとして公開され、携帯電話で必要な講義、書き起こしているサウンドトラックです。 ビデオ全体を変換してから、写真を破棄するのは、ゆっくりとした方法です。 ザ・ オーディオエクストラクター サウンドを直接引き出します。MP4 および MOV ソースの場合、既存の AAC トラックを再エンコードせずに M4A にコピーできます。これは、remux とまったく同じトリックです。 持っているファイルがすでにオーディオで、フォーマットだけが間違っている場合、 オーディオコンバーター その側を処理します。
知っておくべきことの 1 つは、ビデオ ファイルには、さまざまな言語または別の解説用の複数のオーディオ トラックを運ぶことができるということです。 これを含むほとんどのブラウザー ベースのツールは、最初のトラックで動作します。 ソースに複数あり、特定のソースが必要な場合、それは、明示的なストリーム セレクターを使用したコマンド ラインでの ffmpeg のジョブです。
どの形式を、誰に送信する必要がありますか?
ほとんどの変換作業は、実際にはこの問題を変装して作業します。 正直なところ、MP4 は H.264 ビデオと AAC オーディオを備えた MP4 は、他のどの組み合わせよりもはるかに頻繁に正しい選択であるということです。これは、基本的にどこでも考えずに再生できる唯一のものであるからです。
| どこに行くの | 送る | なんでや |
|---|---|---|
| クライアント、同僚、メール | MP4 (H.264/AAC) | あらゆる携帯電話、ラップトップ、ブラウザで再生され、この 10 年間で実現しました |
| あなたが管理するウェブサイト | MP4、WebM を 2 番目のソースとして使用 | WebM は同じ品質で小さく、MP4 はフォールバックです |
| ソーシャル プラットフォーム | mp4 | 送信したものは何でも再エンコードするので、最もクリーンな入力を提供します |
| 編集のタイムライン | 元のファイル | 編集前のすべての変換には、品質のコストが戻ることができません |
| サイズキャップ付きのチャットアプリ | MP4、圧縮 | フォーマットではなくサイズを変更します |
| 電子メール署名または Readme のインライン | MP4 許可されている場合、gif のみが許可されていない場合のみ | GIF は、ビデオを拒否する場所のフォールバックであり、選択ではありません |
最も悲しみを救う行は編集の行です。 人々は、輸入する前に映像を変換し、品質を失い、編集とエクスポートを行い、さらに多くの損失を被ります。 タイムラインがオリジナルを受け入れる場合は、オリジナルを渡して最後に 1 回変換します。
もう 1 つのよくある間違いは、圧縮する予定のときに変換することです。 「このファイルはアップロード制限に対して大きすぎます」は、フォーマットの問題ではありません。 ビデオ データは同じであるため、MOV を MP4 に変更しても役に立ちません。 小さくするということは、意図的に再エンコードすることを意味します。 ビデオコンプレッサー 必要のない部品を、またはトリミングするための、またはトリミングする ビデオトリマー まず。 30 秒カットは、エンコードする必要はありません。品質設定に勝るものはありません。
これは画像の変換と比べてどうですか?
イメージに対して同じコンテナーとコーデックの分割が同じですが、結果として、安価でロスレスな変換もあれば、情報を破棄するものもあります。 PNG を BMP に変換すると、すべてのピクセルが保持されますが、JPEG に変換することはできません。 ザ・ 画像フォーマット コンバータ ガイド その側をカバーし、 画像圧縮ガイド ここに収まるよりも、損失の多い対損失のない区別を詳しく説明します。
実用的な違いはスケールです。 画像変換が悪くても、1 枚の写真が必要になります。 ビデオ変換が不十分な場合、11 分かかり、クライアントはテキストがあいまいに見える理由を尋ねます。
よくある質問
MOV と MP4 のどちらが優れていますか? どちらも、ほとんどの目的で、通常は同じビデオが含まれているためです。 MP4 はより広範なデバイス サポートを備えているため、共有するのに安全なデフォルトです。 MOV は Apple ツールが生成するものであり、MP4 にはないプロのコーデックを搭載しています。
変換されたファイルが大きくなったのはなぜですか? より効率の低いコーデックまたはコンテナー、または GIF に変換した。 remux はサイズを意味のあるものに変えることはできません。古いコーデックにエンコードすると、簡単に拡張できます。
MP4 が古いデバイスで再生できないのはなぜですか? コンテナは問題ありませんが、コーデックは問題ありません。 MP4 ラッパーの H.265 ストリームは、拡張機能がおなじみのように見えても、H.264 のみをデコードするハードウェアでは再生されません。 これは、層が重要であるという最も明確なケースです。
