完璧な解決策: 非常に類似したフレームの繰り返しを減らし、(ピーク)可変フレームレートで出力を保存する

Question 1

あなたも答えを見つけられなかったことにイライラしていましたが、少なくともVFR（Vではない）を有効にする方法について他の人の質問に答えるつもりでした。BR) FFMPEGからの出力。

その答えは、奇妙な名前の-vsyncオプションです。いくつかの異なるオプションを設定できますが、必要なのは「2」またはですvfr。マニュアルページから引用します。

-vsync パラメータ
ビデオ同期方法。互換性のため、古い値は数値として指定できます。新しく追加された値は常に文字列として指定する必要があります。

0、パススルー

各フレームはタイムスタンプとともにデマルチプレクサーからマルチプレクサーに渡されます。

1、参考文献

要求された一定のフレームレートを正確に達成するために、フレームは複製され、ドロップされます。

2、vfr

2 つのフレームが同じタイムスタンプを持つことがないように、フレームはタイムスタンプとともに渡されるか、ドロップされます。

落とす

パススルーと同じですが、すべてのタイムスタンプを破棄し、マルチプレクサーがフレームレートに基づいて新しいタイムスタンプを生成するようにします。

-1、自動

muxer の機能に応じて 1 と 2 のいずれかを選択します。これがデフォルトの方法です。

タイムスタンプは、この後、マルチプレクサによってさらに変更される可能性があることに注意してください。たとえば、フォーマットオプションがネガティブなことを避ける有効になっています。

-map を使用すると、どのストリームからタイムスタンプを取得するかを選択できます。ビデオまたはオーディオのいずれかを変更せずに、残りのストリームを変更されていないストリームに同期させることができます。

しかし、私は、誰もが抱いているような「サブ質問」に答えるだけのコメントを投稿するほどの評判を持っていません。しかし、正直あまり楽観的ではないアイデアがいくつかありました...しかし、私が実際に試した最初のものは働いた。それで。

-vsync 2オプションをオプションと組み合わせるだけで-r $maxfps、もちろん、必要な最大フレームレートに置き換えるだけ$maxfpsです。そして、それは機能します! ソースファイルからフレームを複製するのではなく、ファイルが最大フレームレートを超える原因となるフレームを削除します。

デフォルトでは、それ-r $maxfps自体では、一定のフレームレートを実現するためにフレームを複製/ドロップするだけであり、それ-vsync 2自体では、PTS 値に実際に影響を与えることなくフレームを直接取り込むことになるようです。

私はこれについて楽観的ではありませんでした-r $maxfps。なぜなら、これによってフレームレートが一定になることはすでにわかっていたからです。正直なところ、エラーが発生するか、最初または最後に発生したもの、あるいはその他のものに従うだけになるだろうと思っていました。まさに私が望んでいたとおりの動作をしてくれたので、FFMPEG の開発者には非常に満足しています。

これがあなたや、後でこれを知る必要がなくなった他の誰かの役に立つことを願っています。

Answer

あなたも答えを見つけられなかったことにイライラしていましたが、少なくともVFR（Vではない）を有効にする方法について他の人の質問に答えるつもりでした。BR) FFMPEGからの出力。

その答えは、奇妙な名前の-vsyncオプションです。いくつかの異なるオプションを設定できますが、必要なのは「2」またはですvfr。マニュアルページから引用します。

-vsync パラメータ
ビデオ同期方法。互換性のため、古い値は数値として指定できます。新しく追加された値は常に文字列として指定する必要があります。

0、パススルー

各フレームはタイムスタンプとともにデマルチプレクサーからマルチプレクサーに渡されます。

1、参考文献

要求された一定のフレームレートを正確に達成するために、フレームは複製され、ドロップされます。

2、vfr

2 つのフレームが同じタイムスタンプを持つことがないように、フレームはタイムスタンプとともに渡されるか、ドロップされます。

落とす

パススルーと同じですが、すべてのタイムスタンプを破棄し、マルチプレクサーがフレームレートに基づいて新しいタイムスタンプを生成するようにします。

-1、自動

muxer の機能に応じて 1 と 2 のいずれかを選択します。これがデフォルトの方法です。

タイムスタンプは、この後、マルチプレクサによってさらに変更される可能性があることに注意してください。たとえば、フォーマットオプションがネガティブなことを避ける有効になっています。

-map を使用すると、どのストリームからタイムスタンプを取得するかを選択できます。ビデオまたはオーディオのいずれかを変更せずに、残りのストリームを変更されていないストリームに同期させることができます。

しかし、私は、誰もが抱いているような「サブ質問」に答えるだけのコメントを投稿するほどの評判を持っていません。しかし、正直あまり楽観的ではないアイデアがいくつかありました...しかし、私が実際に試した最初のものは働いた。それで。

-vsync 2オプションをオプションと組み合わせるだけで-r $maxfps、もちろん、必要な最大フレームレートに置き換えるだけ$maxfpsです。そして、それは機能します! ソースファイルからフレームを複製するのではなく、ファイルが最大フレームレートを超える原因となるフレームを削除します。

デフォルトでは、それ-r $maxfps自体では、一定のフレームレートを実現するためにフレームを複製/ドロップするだけであり、それ-vsync 2自体では、PTS 値に実際に影響を与えることなくフレームを直接取り込むことになるようです。

私はこれについて楽観的ではありませんでした-r $maxfps。なぜなら、これによってフレームレートが一定になることはすでにわかっていたからです。正直なところ、エラーが発生するか、最初または最後に発生したもの、あるいはその他のものに従うだけになるだろうと思っていました。まさに私が望んでいたとおりの動作をしてくれたので、FFMPEG の開発者には非常に満足しています。

これがあなたや、後でこれを知る必要がなくなった他の誰かの役に立つことを願っています。

Question 2

可変フレームレートを最大値で指定し、libx264が適切と判断したフレームレートを下げることを許可したいと思います。ここでの考え方は、拡張された静止フレームのようなものがある場合に追加の圧縮を得ることです。

私の理解では、これは比較的不器用な方法で可能かもしれないが、いくつかの複雑で直感に反する理由から望ましくない。

x264 ストリームにはフレームレートがありますが、フレームレートはコーデックの問題というよりもコンテナレベルの問題です。

パススルー VFR エンコードでは、基本的に、どのフレーム/時間でどのフレームレートであるかを詳細に記述したテキストファイルが存在し、ソースをエンコードする際に、tcfile-in や tcfile-out などの関数がタイムスタンプをエンコードに渡して、レートの場所をマッピングし、ビデオをソースと主観的に一致させます。

低フレームレートのアイデアは論理的ですが、いくつかの理由でうまくいきません。x264 はいくつかの機能で VFR を認識しますが、ファイルサイズを小さくするために動きに応じてフレームレートを変更する分析機能 (多くのビットレート制御に類似した方法) はないと思います。

ソースも問題です。VFR ソースはデフォルトでフレームの可変性を保持しますが、CFR ファイルを可変ビットレートでエンコードすると (特にテレシネが必要な場合には良いアイデアです)、同じ CFR が生成されるようです。

つまり、おそらく手動でビットレートを書き直す必要があるでしょう（つまり、遅いシーンのタイムスタンプをファイルに多重化します）、またはavisynth 用の dup、dedup、exactDedup などのフレームデシメーションアルゴリズム動画の動きが極端に少ない場合、一部のフレーム (半分でも?) が破棄されます。問題は、これらのアルゴリズムが高度ではなく、最良のエンコードに寄与するものに関して「実際の」映像で適切な選択を行えないことです。

また、I フレームや B フレームなどを含むフレームを削除すると、時間の経過とともに利用可能な詳細の量が減少し、動きが「階段状」に見え、他の基本的なビデオパラメータに干渉して、エイリアシングなどのアーティファクトが発生する可能性があります。

また、量子化器の動作方法により、x264 は動きの少ないシーンでは実際にビットレートを不釣り合いにさらに下げます。同一の画像のスライドショーがない限り、動き (粒子やその他のアーティファクトのみ) があり、ビットレートを大幅に変更しない限りは目に見えない品質の低下が発生します。

そして最後に、希望どおりのことをするための選択肢があまりない理由は、x264 が時間的圧縮 (部分的なフレームの変更の記録) のみを使用してビットレートを管理するのに非常に優れているためです。フレームレートを 1/2 にしてもファイルサイズは半分にはなりません。動きが少ない場合やアニメーションの場合は、10% が現実的な増加と考えられます。

つまり、静止シーンのビットレートを下げてもファイルサイズはほとんど変わりませんが、品質や同期に関するさまざまな問題が発生し、ビデオ編集ソフトウェアとの互換性も失われます。

デシメータを試してみたい場合は、レベルオプション、それぞれが最大解像度とフレームレートを指定します。残念ながら、プロファイルを使用して、必要なフレームレートを得るには、おそらく非常に低い解像度で作業する必要があります。レートを完全に手動で編集するか、高すぎると思われるフレームレートを修正する必要があります。いずれにしても、tcfile が保存されるエンコードプロセス後に変更が加えられた場合、サウンドを新しいフレームレートと同期させるには、調整が必要になります。

重要なのは、多くのビットレート設定を最適化することに時間を費やすと、ファイルサイズ管理の面ではるかに多くの成果が得られ、ビデオの品質が向上し、メリットがほとんどないまま複雑になるよりも良いということです。放送やメディア標準を目指しているのでない限り、元の FPS を維持するのがおそらく最善の策です。プレーヤーはさまざまなビットレートに対応できるように適切に設計されており (NLE とは異なります)、ビデオのフレーム数が多いほど、フレーム間の動きの変化が小さくなるため、再生がスムーズになり、ファイルサイズも小さくなる可能性があります。

以下に、エンコードのこのわかりにくい側面を解決するのに役立つ標準情報とフォーラムのディスカッションへのリンクのコレクションを示します。

-AviSynth デシメーションツール

-fps および -r スイッチ
-x264 一般 (tcfile、fps)
-タイムコードファイル規格
-レベルとプロフィール
-簡潔でわかりやすい CFR/VFR 設定の概要 (「フレームレート」セクション)

doom9、videohelp、その他の理論的な議論
1 2 3 4 5 6 7

Answer