2 つのビデオ ファイルを端から端まで配置することは、世界で最も安価な操作のように聞こえますが、約 5 分間、私はそれを信じていました。 次に、ストリームをコピーして何も書き換えない、利用可能な最速の方法を使用して、25 fps の 640x480 クリップに 30fps の 1280x720 クリップを参加させました。 ファイルを作成しました。 ファイルは、2 つのクリップが 11 になると、11 の 9 9 6 秒とされ、コンテナーは 1280x720 で、ストリームの後半は 640x480 であり、マルチプレクサは 2 番目のクリップのすべてのフレームの書き換えタイムスタンプについて警告を印刷しました。 ビデオへの参加に関するすべては、なぜそれが起こるのかから続きます。
tl;dr: チープ ジョインは、両方のファイルがコーデック、解像度、フレーム レート、タイムベースに既に同意している場合にのみ機能します。この場合、2 つのデバイスの映像は決してわかりません。 正直なルートは両方をデコードし、1 つの新しいファイルをエンコードします。これは、遅くなり、何かを生成します。 ここでの測定: コピー方法は、11 秒間の映像で 11.996 秒を報告し、誤った解像度を宣言しました。再エンコードは、1280x720 の 1280x720 で 0.63 秒で正確に 11.000 秒を生成しました。 異なるサイズのクリップを最初に 1 つのフレームに取り付ける必要があります。そうしないと、結合が完全に拒否されます。 ザ・ ビデオ編集者 8 つのクリップまで、すべてブラウザーで実行します。
なぜ 2 つのクリップがくっつきにくいのでしょうか?
ビデオ ファイルは、ヘッダーのある画像のストリームではないためです。 これは、エンコードされたストリームを保持するコンテナであり、エンコードが状態を運ぶ。
H.264 は、ほとんどのフレームを他のフレームとの相違点として説明することにより、圧縮します。 キーフレームは単独で、次のキーフレームまで、それ以降のすべてが定義されます。 デコーダには、解像度、色の形式、プロファイルを記述するストリームのパラメータ セットも必要であり、各パケットの数値を秒単位に変換するタイムベースを保持します。
2 つのデバイスによって作成された 2 つのファイルは、そのいずれにも同意しません。 解像度が異なるということは、パラメータセットが異なることを意味します フレーム レートが異なると、通常は異なるタイムベースを意味します。 1 年間隔で記録された同じ電話機の 2 つのクリップでも、カメラ アプリがエンコーダ設定を変更したため、異なる場合があります。
バイトを連結すると、デコーダがヘッダーで 1 つのことを伝えられ、途中で別のことを渡されたストリームが得られます。 プレイヤーが対応することもあります。 多くの場合、最初のクリップを表示して停止するか、2 つ目を色付きのノイズとして再生します。
高速メソッドは何を生成しますか?
ファイル、警告の山、間違っている期間。
ffmpeg's 連結デマキサー ストリームのコピーを使用すると、すべての「参加するだけ」という方法がオンラインで推奨され、入力が一致したときに真に適切なツールです。 2 つの不一致のクリップを指し示しますが、正常に終了します。次に、次のようにします。
| 測定 | 予想されている | 生産された |
|---|---|---|
| 期間 | 11.000 s | 11.996 s |
| 宣言された解決 | 1 つの値、正しい | 640x480 になるストリームの場合は 1280x720 |
| タイムスタンプの警告 | なし | 2 番目のクリップのフレームごとに 1 つ |
警告はすべて同じことを言っています。
Non-monotonic DTS; previous: 90981, current: 76133; changing to 90982.
This may result in incorrect timestamps in the output file.
2 番目のクリップのタイムスタンプは、自分のファイル内にあるはずのようにゼロから再起動し、マルチプレクサはタイムスタンプが逆方向に移動するストリームを書きません。 そこで、1 フレームずつ新しいものを発明し、実際のタイミングと発明されたタイミングとの累積差分は、余分な秒の元となります。
ffmpeg は異常に許容できるため、ffmpeg は後で両方の半分をデコードできます。 ブラウザはありません。 これは、マシン上で正常に再生され、ビューアに黒い長方形を表示するファイルです。
フィルタ グラフを介して結合すると、何が得られますか。また、何を購入しますか?
完全なデコードとエンコードが必要です。 正しいファイルを購入します。
ストリームをコピーする代わりに、各入力がフレームにデコードされ、フレームがトリムされてフィルター グラフ内で結合され、結果から 1 つの新しいストリームがエンコードされます。 すべてのフレームはデコーダとエンコーダを通過します。これは実際の作業です。
何を買うかというと、出力には、すべてのコードが一から一気にエンコードされているため、1 つのコーデック、解像度、1 つのフレーム レート、1 つの連続したタイムスタンプがあります。 同じ 2 つのクリップで:
| 測定 | コピー方法 | フィルタ グラフ |
|---|---|---|
| 期間 | 11.996 s | 11.000 s |
| 決議 | 1280x720 と宣言され、640x480 になります | 全体で 1280x720 |
| フレーム | 305 | 305 |
| エクスポート時間 | インスタント | 0.63 s |
| サイズ | より小さい | 2.1MB |
ffmpeg をネイティブに実行するデスクトップで、11 秒間の出力で 0.63 秒の作業。 WebAssembly を介したブラウザ タブでは、数倍遅くなります。これは正直な取引であり、クリップ数が制限されている理由です。
クリップにタイムスタンプの再ベースが必要なのはなぜですか?
フィルタ グラフ内の連結はストリームに結合し、ストリームのタイムスタンプは絶対的です。
各クリップのフレームは、自分のファイルの最初から測定された時間で到着します。 クリップの中央からセクションをトリムすると、これらのフレームはまだ「これは 42 秒で発生します」と表示されます。 それらを 6 秒で終わるクリップに参加すると、36 秒間の何もない状態で 6 から 42 にジャンプするストリームができます。
setpts=PTS-STARTPTS クリップがそれぞれのフレームから各クリップの開始を差し引くので、すべてのクリップが結合される前にゼロから始まります。 オーディオに相当するのは asetpts。 それらがないと、出力が最初のクリップを再生し、次に長いフリーズを再生し、次に 2 番目のクリップを再生します。 これは、手書きの ffmpeg join コマンドで最もよく見られる間違いであり、それは無音です。ファイルは有効で、期間が間違っています。
クリップのサイズが異なるとどうなりますか?
参加は拒否され、最近まで、その拒否がすべての話でした。
ザ・ 連結フィルター 入力を比較して、ビデオの寸法またはサンプルの縦横比が一致しない場合は実行されません。
Input link in0:v0 parameters (size 640x480, SAR 1:1) do not match the
corresponding output link in0:v0 parameters (1280x720, SAR 1:1)
Failed to configure output pad on Parsed_concat_8
これは中止であり、警告ではありません。ファイルは生成されません。 2 つの電話、または電話クリップと画面の録音は、まさにそれを引き起こすのに役立ちます。これは、誰かがクリップに参加する通常の理由です。
オーディオにはそのような助けは必要ありません。直感に反するものであるため、知っておく価値があります。 同じグラフが 44.1 kHz のモノラル トラックを 48 kHz のステレオ トラックに苦しむことなく結び付け、正確な 11.000 秒のファイルを生成しました。 ビデオ側だけが厳格です。
修正は、タイムライン全体に対して 1 つのフレームを整理し、参加する前にすべてのクリップをその中に収めることです。 高さは、選択した出力解像度、またはソースの解像度を維持するときの最初のクリップから得られ、幅はそのクリップの縦横比に沿っているため、縦断映像のタイムラインはポートレートのままです。 次に、各クリップをフレームの内側に収まるようにスケーリングし、埋め込むためにパディングします。
scale=1280:720:force_original_aspect_ratio=decrease,
pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1
フィッティングは、異なる形状のクリップが、4:3 クリップが 16:9 のタイムラインに合致する場合の 2 つの悪のうち小さい方である、別の形のクリップがレターボックスで表示されることを意味します。 setsar=1 は装飾ではありません: フィルターはサンプルの縦横比とピクセル寸法を比較するため、2 つのクリップは同じサイズで、それでも拒否できます。
4:2:0 の H.264 の H.264 は、各方向の半分の解像度で色を格納し、奇数の幅または高さをエンコードできないため、両方の寸法は偶数に丸められます。
なぜクリップが 8 分間だけでしょうか。
各クリップのコストがかかるため、ブラウザー タブ内でデコード パスを取得し、タブには固定のメモリが含まれます。
8 つの入力とは、同じフィルター グラフに対して実行される 8 つのデコーダに加えて、エンコーダと、ストリームの対象とならないため、メモリに保持されているすべてのソース ファイルを意味します。 30 分の出力は、エンコードがページがハングしたと想定するのに十分な時間がかかるポイントです。
どちらの制限も、フォーマットの法則ではありません。 どちらも、ブラウザーのビルドが快適でなくなるという行を超えており、タブがエクスポートの 40 分でクラッシュしたときに検出されるのではなく、前に表示されます。 10 分の 1 秒未満のクリップも拒否されます。その下では、警告ではなく、フレームがなく、ffmpeg エラーが発生するためです。
それ以上の場合、これは間違ったツールであり、デスクトップ エディターが適切です。
ここでのトリミングはトリマーとどう違うのですか?
結合内部でのトリミングはフレームに正確で、余分な費用はかかりません。
専用の ビデオトリマー ストリームをコピーし、キーフレームでしかカットできない高速モードを提供します。そのため、トリムの開始が最大 10 秒早く着地することがあります。 そのガイド 理由を詳しく説明します。
とにかくエクスポートがすべてを再エンコードしているため、その取引はここには存在しません。 トリムは、デコードされたフレームでフィルター グラフ内で行われるため、4.3 秒でのカットは 4.3 秒でカットされます。 すでに支払っているコストの副作用として、フレームの精度を無料で入手できます。
したがって、1 つのクリップをトリムしても何も必要ない場合は、トリマーの高速モードの方がはるかに高速です。 何かに参加する場合は、ここでトリミングしてください。
速度の変更はオーディオに何をもたらしますか?
別々に処理する必要があり、算術はビデオと同じではありません。
ビデオの速度はタイムスタンプ操作です。 setpts=PTS/2 フレームのプレゼンテーション時間は半分になり、フレーム自体はそのままです。 サンプルを 2 倍の速さで再生すると、ピッチがオクターブ上に上がるため、オーディオはこのようには機能しません。 ザ・ atempo 代わりに、フィルターのリサンプリングを行い、ピッチを維持し、持続時間を変更します。
atempo 1 回のパスで 0.5 から 2.0 までしか受け取れないため、4 倍の変更は 2 つの 2x パスとして構築され、0.25 倍の 1 つの 2 つの 0.5x パスとして変更されます。 現在のビルドは上限を上げ、FFMPeg 8.1 は 0.5 から 100 の範囲を報告しています。 1 つのクリップで測定され、1 つのクリップで測定 atempo=4 そして鎖でつながれた atempo=2,atempo=2 11 ミリ秒間隔で着陸しました。
WebAssembly コアは、バージョンに固定するのではなく、実行時にフェッチされ、フィルタを出荷したすべてのビルドでパスを乗算することが正しいため、チェーンはまだ構築されます。 提供される速度範囲は、0.25 倍から 4 倍ですが、結果は目新しさではなく編集のままです。
MP4かWebMか？
MP4 は、特定の理由がない限り、ほとんどの場合、その理由は、質の高い議論ではなく、ライセンスです。
| mp4 | ウェブ | |
|---|---|---|
| ビデオコーデック | H.264 | vp9 |
| オーディオコーデック | aac | 作品 |
| でプレーする | every | ブラウザ、ほとんどの現代のプレーヤー |
| タブで速度をエンコードする | もっと早く | かなり遅い |
| 同じ品質のサイズ | 大きい | より小さい |
VP9 は、同じ品質の小さなファイルを作成します。これは、一部のプロジェクトにとって重要であり、他のプロジェクトにとっては重要ではありません。 ffmpeg's 所有 VP9 エンコーディング ガイド 速度コストについて率直です。 そうでないものは速いです。 ここでの WebM パスは、リアルタイムの期限を設定してより高い CRF で実行されます。 cpu-used 5タブ内の VP9 エンコードは、壊れていると感じるのに十分な時間がかかるため、デスクトップ エンコードが不注意であると考える設定です。
MP4 パスは使用します -preset veryfast CRF 23 で yuv420p、プラス -movflags +faststart、インデックスをファイルの前面に移動して、ダウンロード後だけでなく、ダウンロード中に再生します。
輸出額はどれくらいで、どのくらいの期間がかかりますか?
サイズは解像度から予測できます。 時間は何からでも予測できません。
エクスポートは常に再エンコードされるため、ソース ファイルのサイズは結果についてほとんど教えてくれません。 表示されている見積もりは、出力高さから得られます。1080p で約 5 Mbps、720p で 2.5 Mbps、その下で 1.2 です。WebM は MP4 フィギュアの約 70% に着陸し、オーディオはミュートしない限り 128 kbps を追加します。
コンテンツはどの式よりも重要であるため、これは見積もりであり、1 としてラベル付けされています。 CRF は品質レベルを目標としており、必要なビットレートをすべて費やすため、同じ解像度で同じ CRF が木を通り抜ける静的なインタビューとハンドヘルド パンが数倍異なります。
時間は、マシン、解像度、クリップの数、タブに他にやるべきことがないかどうかによって異なります。 ネイティブ FFmpeg は 0.63 秒で 11 秒の出力を管理し、ブラウザーがそれより数倍遅くなり、WebM が再び遅くなると予想します。
これで何ができないの
結合、トリム、並べ替え、スケール、速度の変更、オーディオのドロップ。 それが機能セット全体であり、それとビデオ エディターとのギャップは明確にする価値があります。
トランジション、タイトル、音楽トラック、色補正、トリミング、クリップあたりのボリューム、キーフレームの何も、完成したタイムラインのプレビューはありません。 各クリップをトリムして配置すると、1 セットの出力設定がすべてのクリップに適用され、結果がエンコードされます。
これは、実際の一般的な仕事をカバーしています。複数の録音が 1 つのファイルになる必要があり、有用な部分にトリミングされ、適切な順序で、何かが受け入れるサイズです。 クリエイティブな決定に関係するものはすべて、エディターを使用してください。
クリップはどのような順序で入りますか?それを変更できますか?
追加した順序、そして、各クリップにアップボタンとダウンボタンを使用して。
再順序付けはビデオではなくリスト操作です。クリップを移動すると、入力インデックスがフィルター グラフで占める入力インデックスが変更され、エクスポートが実行されるまで何も再読または再デコードされません。 そのため、ファイルがどんなに大きいかは一瞬で移動でき、タイムラインは何度でも無料で再配置できます。
ドラッグ アンド ドロップではなくボタンを使用することは、最大 8 つの項目のリストに対して意図的に選択できます。 それぞれに移動するクリップのラベルが付いているため、順序はキーボードで変更でき、スクリーン リーダーでも読み取ることができます。どちらもドラッグ ハンドルでは余計な作業をしなくてもわかります。
エクスポートする前に確認する価値があるのは、シーケンスの方向です。 同じイベントのいくつかの録音は、通常、ファイル ピッカーからアルファベット順に届きます。これは、カメラのファイル名がたまたま生成する順序であり、常に記録が行われた順序ではありません。
なぜこれがブラウザで実行されるのですか?
映像は通常、アップロードしたくない種類であり、ジョブにはサーバーは必要ありません。
ここでのすべての操作は ffmpeg と ffmpeg です WebAssembly にコンパイル。 ファイルはディスクからタブに読み込まれ、そこでデコードされ、そこに結合され、そこにエンコードされ、ダウンロードとして返されます。 何もアップロードされず、キューがあなたの映像を保持し、制御できないマシン上にコピーはありません。
人々が参加するクリップは、インタビュー、相談、家族の録音、内部ソフトウェアのスクリーン キャプチャ、禁輸措置の下のドラフトです。 通常の代替手段は、無料のサービスに数百メガバイトをアップロードし、何も知らないハードウェアで変換し、誰も読んでいない条件の下に保持します。
費用は 8 つのクリップと 30 分の天井で、デスクトップのエンコードよりも遅いエンコードです。 どちらも開始前に述べていますが、これは取り引きする価値があります。
