web-dev-qa-db-ja.com

FFMPEG / libx264:最大で可変フレームレートを指定する方法

FFMPEG/libx264(-r/-framerate)に固定フレームレートを提供する代わりに、MAXIMUM値で可変フレームレートを指定し、libx264が適切と思われるフレームレートを下げることを許可します。ここでのアイデアは、拡張された静止フレームのようなものが存在する場合に、追加の圧縮を取得することです(これはA LOTソースビデオで発生します)。

予測または双方向のMPEGフレームは非常によく圧縮されますが、ソースフレームレートがトランスコード先のフレームレートよりも低い可能性もあります(結果として、BIGGERストリームが発生する可能性があります)。

17

あなたも答えを見つけられなかったことにイライラしました、私は少なくともVFRを有効にする方法に関する他の人々の質問に答えるつもりでした(Vではありません[〜#〜] b [〜#〜]R)FFMPEGからの出力。

その答えは、奇妙な名前の-vsyncオプションです。いくつかの異なるオプションを設定できますが、必要なのは '2'またはvfrです。 manページから:

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

  • 、パススルー

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

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

    • 2つのフレームが同じタイムスタンプを持つことを防ぐために、フレームはタイムスタンプとともに通過するか、ドロップされます。
  • ドロップ

    • パススルーとしてすべてのタイムスタンプを破棄し、マルチプレクサにフレームレートに基づいて新しいタイムスタンプを生成させます。
  • -1、auto

    • マルチプレクサ機能に応じて、1〜2を選択します。これがデフォルトの方法です。

この後に、タイムスタンプがマルチプレクサによってさらに変更される可能性があることに注意してください。たとえば、フォーマットオプションavoid_negative_tsが有効になっている場合です。

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

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

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

デフォルトでは、-r $maxfps自体はフレームを複製/ドロップして一定のフレームレートを達成するだけであり、-vsync 2自体は実際にPTS値に影響を与えずにフレームを直接プルするようです。

-r $maxfpsが一定のフレームレートに設定することをすでに知っていたので、私はこれについて楽観的ではありませんでした。私は正直に言って、エラーまたはそれが最初または最後に来たもののいずれかに従うだけであることを期待していました。それが私が望んでいたことを正確に実行するという事実は、FFMPEG開発者に非常に満足しています。

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

19
Tynach

MAXIMUM値を使用して可変フレームレートを指定し、libx264でフレームレートが適切と思われるように下げられるようにしたいと考えています。ここでの考え方は、拡張された静止フレームのようなものが存在する場合に、追加の圧縮を取得することです

私の理解では、これはおそらく比較的不器用な方法かもしれませんが、複雑で直観に反する理由で望ましくありません

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

パススルーVFRエンコードでは、本質的には、どのフレーム/時間でのフレームレートが詳細なテキストファイルであり、ソースのエンコードでは、tcfile-inまたはtcfile-outなどの関数がタイムスタンプをエンコードに渡します、レートの場所をマッピングし、ビデオをソースから主観的に一貫した状態に保ちます。

低フレームレートのアイデアは論理的なものですが、いくつかの理由でうまくいきません。 x264はいくつかの機能を備えたVFR対応ですが、ファイルサイズを下げるためにモーションに関してフレームレートを変化させる分析機能はないと思います(多くのビットレートコントロールと同様に)。

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

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

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

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

最後に、希望することを実行するためのオプションが多くない理由は、x264が時間圧縮(部分フレームでの変更の記録)だけを使用してビットレートを管理するのに本当に優れているためです。フレームレートを1/2にしても、ファイルサイズは半分になりません。 10%はおそらく、低モーションやアニメーションから期待できる現実的な利益です。

つまり、静的なシーンのビットレートを落としても、ファイルサイズはほとんど変わりませんが、ビデオ編集ソフトウェアとの非互換性は言うまでもなく、品質と同期の問題が発生します。

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

多くのビットレート設定の最適化に時間を費やすと、ファイルサイズ管理の点ではるかに多くの利益が得られ、少しの利益のために複雑化を引き起こすのではなく、ビデオの品質が向上します。放送やメディア規格を目指しているのでない限り、元のFPSを維持することはおそらく最良のアイデアです。プレーヤーは(編集者とは異なり)可変ビットレートを再生でき、ビデオ内のフレーム数が多いほど、フレーム間の動きの変化が小さいため、ビデオがスムーズに再生され、ファイルサイズが小さくなる可能性があります。

これは、エンコーディングのこの混乱する側面を支援する標準情報とフォーラムディスカッションへのリンクのコレクションです。

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

- fpsおよび-rスイッチ
- x264 General(tcfile、fps)
- タイムコードファイル標準
- レベルとプロファイル
- 短く、明確なCFR/VFR設定の要約(「フレームレート」セクション)

Doom9、videohelp、&c理論的なディスカッション
124567

1
chronometric