インタビューの 42 秒の回答を切り取り、デッキに落とし、必要なビットより 7 秒前に話者が文の途中で始まるのを見ました。 慎重にスタートを切りました。 トリマーは私を無視していた、またはそう見えた。 要望点よりも前の最寄りのキーフレームで開始するという、ファストカットでできることはそれだけでした。 それが分かれば、その動作はバグではなくなり、2 つの選択肢があり、適切な選択肢を選択するのに 1 秒かかります。
tl;dr: 高速トリムは、既存のビデオ ストリームを再エンコードするのではなく、コピーして、キーフレームでのみコピーを開始できます。 キーフレームが 10 秒間隔のファイルで 0:07 に開始するように依頼し、デコーダが開始できる最後のポイントである 0:00 にカットが開始されます。 エンドはあなたが尋ねたところに着陸し、スタートだけがドリフトし、後方にドリフトします。 正確なフレームが必要な場合の修正は、再エンコードすることです。これは、遅く、少し品質のコストがかかります。 ザ・ ビデオトリマー 両方を提供し、デフォルトは高速です。
カットがあなたが尋ねるよりも早く開始されるのはなぜですか?
ビデオにほとんどフレームがないのは完全な画像だからです。
ビデオ圧縮は、1 つのフル フレームを格納してから変更を説明することによって機能します。 キーフレーム、正しくは IDR フレーム H.264、画像全体を保持し、何にも依存しません。 フレームが異なる場合: このブロックは左に 4 ピクセル移動しましたが、この領域は変更されず、これらのピクセルは少し暗くなりました。 シーケンスの途中でフレームは意味がありません。それ自体では、差分が適用されるファイルがなければ意味がありません。
したがって、0:07 に開始するように要求し、ツールがデコードせずにストリームをコピーすると、0:07 にコピーするものは何もありません。 0:07 が以前のものとどのように異なるかについての説明があります。 プレーヤーが開始できるのはキーフレームだけで、安全な唯一の場所は、開始点または前の最後のキーフレームです。
別の方法として、ビデオを 0:07 までデコードし、前のものを捨てて、残っているものを新しいキーフレームで始まる新しいファイルに圧縮することもできます。 バイトをコピーするのではなく、すべてのフレームで実際に機能するという理由で、それは正確であり、スローパスです。
キーフレームは、実際にどのくらい離れていますか?
ほとんどの人が想定しているよりも、そのギャップが、ファスト カットの見た目を決めるのはいかに悪いかを決定するものです。
推測するよりも測定しました。 x264 をデフォルトで 30 秒間エンコードし、キーフレームをリストします。
ffmpeg -f lavfi -i "testsrc=duration=30:size=640x360:rate=25" -c:v libx264 clip.mp4
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4 \
| awk -F, '$2 ~ /K/ {print $1}'
# 0.000000
# 10.000000
# 20.000000
10 秒に 1 つのキーフレーム。 これは、キーフレーム間の X264 のデフォルトである 250 フレーム、毎秒 25 フレームです。 これらのデフォルトでエンコードされたファイルでは、選択したポイントよりも 10 秒前まで、高速トリムが開始されます。
ほとんどの映像は、ほとんどの映像がストリーミング用に作られているため、より親しみやすいものであり、プレイヤーは品質を切り替えるために頻繁にエントリー ポイントを必要とします。 知っておく価値のある範囲は次のとおりです。
| ソース | 典型的なキーフレームギャップ | ファストカットで最悪の場合のドリフト |
|---|---|---|
| 電話録音 | 1～2秒 | ほとんど目立たない |
| ストリーミング ビデオ、HLS または DASH | 2～6秒 | 短いクリップで目立つ |
| X264 または ffmpeg のデフォルト | 25 fps で 10 秒 | ショートカットを台無しにする |
| スクリーンレコーダー、低モーション | 10秒以上 | ショートカットを台無しにする |
パターン: プレーヤー用にエンコードされたものには、キーフレームが近いものがあり、ストレージ用に 1 回エンコードされたものはすべてありません。
ドリフトはファイルに何をもたらしますか?
開始を移動し、終わりはそのままにします。これは、ウィンドウ全体がスライドすると簡単に想定できるため、正確にする価値があります。
同じクリップを 0:07 から 0:15 に要求します。8 秒のウィンドウで、ストリーム コピーを使用します。
| 求められた | ソースのキーフレーム | 結果 | 何があったの |
|---|---|---|---|
| 7、15 秒 | 0、10、20 | 0 から 15.08 秒 | 開始は 0 でキーフレームに戻りました |
| 12秒から20代 | 0、10、20 | 10 秒から 20.08 秒 | 開始は 10 時にキーフレームに戻りました |
| 7、15 秒 | 2秒ごと | 6 秒から 15.08 秒 | 1 つのキーフレームを後退させて開始 |
終わりは、3 つすべてに当てはまります。 持続時間を信頼するのではなく、フレームをハッシュして確認しました。出力の最後のフレームは、ソース フレームと 15.04 秒で、ソース フレームと同じで、これは、私が要求したフレームの後にフレームと停止する正しい場所です。 変わったのは、それが始まるところからです。
これが、選択したウィンドウよりもファイルが長いのはそのためです。 8 秒と思っていたカットが 15 秒で届きました。オーバーランのせいではなく、7 秒のリードインがやってきたからです。 キーフレームが 2 秒間隔のクリップでは、同じカットが 9 秒と到着し、誰も気づきません。
代わりにいつ再エンコードする必要がありますか?
3 つのケースで、その外では高速パスがより優れたツールです。
特定のフレームが必要です。 ボールがバットに当たった瞬間に、ジェスチャーで言葉を切ります。 キーフレームの精度が十分ではなく、スライダーを気にするほどの注意が必要です。制限は、インターフェイスではなくファイルにあるためです。
クリップは短いです。 32 カットで 7 秒のリードインは厄介です。 4 秒のカットで、それがすべてです。
スパース キーフレームでファイルを切り取っています。 上記の測定値が示すように、スクリーンの録音とアーカイブ用に一度エクスポートされたもの。
費用は本物ですが、人々が恐れるよりも小さいです。 再エンコードはウィンドウ内のすべてのフレームをデコードして再度圧縮するため、ファイルのサイズではなくカットの長さに比例して時間がかかり、品質の世代が失われます。 23 の一定の係数で、トリマーが正確なモードに使用するものである場合、その損失は 1 回のパスで見えないようになります。 これは、すでに 1 回圧縮された 2 回目のパスです。これは同じです。 圧縮を支配する世代損失 一般的に。
自分のファイル内のキーフレームをどのように見つけますか?
1 つのコマンドで、高速パスが実行されるかどうかを事前に通知します。
# the first ten keyframe timestamps, in seconds
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.mp4 \
| awk -F, '$2 ~ /K/ {print $1}' | head -10
ギャップが 1 秒または 2 秒の場合は、すばやくトリミングして、それについて考えるのをやめます。 それらが 10 で、カットが重要な場合は、再エンコードしてください。
これには 2 番目の使用法があります。 映像を作成している場合、他の人がカットします。キーフレーム間隔を短くすると、ファイル サイズをわずかなコストで、生活が楽になります。 キーフレームは全体像であるため、より多くのバイトを意味します。これが、エンコーダが他の何も要求しないときに、それらをスペースに配置する理由です。
トリミングは品質を失いますか?
厳密な意味では、高速パスはそうではありません。 何も復号されないので、何も再圧縮されません。出力内のフレームは、入力にあった同じ圧縮フレームで、バイト単位で、バイト単位で、新しいコンテナーに入っています。 この方法でファイルを 10 回トリムすると、10 分の 1 は最初のファイルと同じ品質になります。
正確なパスは、一度は実行します。 ウィンドウはデコードされ、圧縮されます。そのため、1 世代の損失を拾います。 十分にエンコードされたソースを適切な品質のターゲットにすると、これはわかりにくく、トリムのトリムをトリミングするのではなく、元のパスで必要なカットを行うことが賢明なルールです。
どちらのパスも、アップスケール、シャープ化、改善にはなりません。 トリマーは時間を取り除きます。これがすべての作業です。
トリム クリップがすぐに再生されないのはなぜですか?
インデックスがどこに着地するか、そして圧縮時に重要なのは同じフラグです。
MP4 には、すべてのフレームがどこから始まるかを説明する表があります。 エンコーダは、終了時にのみその内容を認識するため、明白な順序で記述すると、そのテーブルはファイルの最後に表示されます。 ディスクから再生しました。 HTTP 経由で提供される場合、プレーヤーはファイル全体が到着するまで開始できません。
トリマーが通過する -movflags +faststart、2 回目のパスを実行し、そのテーブルを前面に移動します。 カットはダウンロード中に再生されます。これは、ファイルが URL からチャット アプリ、CMS、またはスライドに移行するときに必要なものです。
オーディオはどうなるの?
オーディオは、それ自体のフレーム境界でカットされ、それらはビデオ キーフレーム間隔よりもはるかに短いため、オーディオは画像よりもマークに近づくことができます。
この不一致は、他の古典的なトリミング障害の原因です。それは、サウンドが画像より少し先にあるか、または単語の断片で始まるクリップです。 修正は、編集ではなく引数にあり、トリマーはそれを渡します。 -avoid_negative_ts make_zero 両方のストリームのタイムスタンプを再ベースして、ストリームが互いに相対的に整列したままで出力がゼロで開始されるようにします。 それがないと、ストリーム コピーはキーフレームとカット ポイントの間のフレームに対して否定的なタイムスタンプを発する可能性があり、プレイヤーはそれらをどうするかについて意見が一致しません。 スキップする人もいれば、ストール型になっている人もいれば、早くオーディオを再生する人もいます
サウンドだけが必要な場合は、最初にビデオをカットしてから、次にカットします。 オーディオの抽出 順番が間違っています。 オーディオカットはフレーム精度で安価であるため、最初に抽出してオーディオをカットします。
携帯電話の写真アプリでトリミングしたほうがいいですか?
簡単な個人用クリップとしては、問題ありません。 あなたが公開するものは何でも、いいえ、その理由は明らかではありません。
電話のエディターは通常、エクスポート時に再エンコードし、忠実度ではなく、速度と予測可能なファイル サイズの設定を使用してそれを行います。 トリムごとに一世代の損失を払います。 さらに悪いことに、一部の人は非破壊的にトリミングし、元のメタデータとしてインポイントとアウトを保存します。これは、電話機のトリムのように見え、ファイルがそれを離れるとまったくトリミングされません。受信者は、完全なクリップを取得するか、プレーヤーが無視する編集リストを表示します。
コピーモードのトリムは、両方の問題を回避します。 取得したファイルは、全員が取得するファイルであり、その中のフレームはデコードされません。
ビデオは私のマシンから離れますか?
いやー 。 カットが通り抜ける ffmpeg が WebAssembly にコンパイルされた ブラウザー タブ内: ファイルはディスクからページ メモリに読み込まれ、そこでトリミングされ、ダウンロードとして返されます。 DevTools のネットワーク パネルは、これが発生している間、ビデオを空にしたままにします。
フッテージの場合、ほとんどのファイル タイプよりも重要です。 クリップは通常、だれでも編集する最大の個人的なものであり、無料のオンライン トリマーの通常の配置は、自分の映像を見知らぬ人にアップロードし、読んでいないページの保持ポリシーを信頼することです。 ここでは、保持するコピーはありません。
制限は計画ではなくタブです。1 つのカットが 30 分に制限され、ソース全体がブラウザーのメモリに収まる必要があります。 それを過ぎると、デスクトップ ツールはより高速で信頼性が高く、9 分目にメモリーが不足するタブを渡すよりも、そう言う方がよいでしょう。
デスクトップ エディタが適切なツールはいつですか?
時間を割く以上のことをしている場合。 いくつかのクリップを結合して、タイトル、色、音楽を追加するか、サンプル レベルで表示する必要がある波形をカットします。 これは編集のタイムラインであり、トリマーではありません。正解は本物のエディターです。
ブラウザ内では、境界線はほぼ同じです。 1 つのクリップから 1 つのストレッチを取り除くのはトリムです。 ピースを一緒に結合することは、 ビデオ編集者。 結果を小さくするのは、 コンプレッサー、コンテナーまたはコーデックを変更するのは、 コンバーター、これは 圧縮とは異なる操作 2人は常に混乱していますが。
プレビューとエクスポートされたファイルが一致しないのはなぜですか?
トリム インターフェイスは、3 つの場所から同じ数を収集するため、その数が何であるかに一致しないため、それらを 1 つの値にすることがトリマーでの作業のほとんどです。
テキスト フィールドは、誰かが入力したものをすべて表示します。 7、 0:07、 00:00:07 や 7.25。 スライダーは、誰もが望むよりも正確に浮動小数点を提供します。 ビデオ要素 currentTime 別の浮動小数点を指定します。これは必ずしもフレームのタイムスタンプではありません。ブラウザは、フレーム間の位置を報告することができます。
3 つがわずかに異なる数秒で着地すると、プレビューで 1 つのことが表示され、エクスポートが別の要素を生成します。これは、カットが正しい場合でも、トリマーが壊れていると感じさせる特定のバグです。 ここでのパーサーは、3 つのタイムコード シェイプをすべて受け入れ、それらを正しく整列させて解決し、最後の部分は常に秒数になるようにして、単一の値をプレビューとエクスポートの両方に渡します。 半型フィールドはスローするのではなく何も返さないので、入力中にキーストロークごとに入力が爆発しない 0:0。
実践的なアドバイス: 正確に 2 番目に重要な場合は、ドラッグするのではなくタイムコードを入力してください。 スライダーはモーメントを見つけるためのもので、フィールドはそれに名前を付けるためのものです。
セクションを真ん中から切り取るにはどうすればよいですか?
2 回カットして 1 回の結合を行います。トリマーは 1 ステップでそれを行います。これは、人々を頻繁に驚かせます。
クリップの中央を取り外すということは、パーツを選択前とその後に保持し、2 つの別々のウィンドウであるパーツを保持し、それらを元に戻すことを意味します。 ここでトリマは実行ごとに 1 つのウィンドウを生成します。したがって、シーケンスは次のようになります。バッド セクションの最初から最初までトリムし、悪いセクションの最後から最後までトリムしてから、2 つを ビデオ編集者。
その際に注目すべき 2 つのこと。 両方のピースがコーデック、解像度、フレーム レートを共有している場合、結合は正常に機能します。両方とも、コピー モードのトリムを介して同じソース ファイルから取得した場合に使用されます。 シームは両側のキーフレーム境界に着地するため、2 番目のピースは、マークより少し早く、上記のように開始します。 カットポイントが重要な場合は、2 番目のピースに正確なモードを使用します。
もう 1 つのオプションは、開始前に停止することです。必要なものがリアクションではなくハイライトである場合、2 つの別々のクリップは、隙間があってつながれた 1 つのクリップよりも便利です。
