H264コーデックの最小作業フレームレート

単一の画像ファイルからビデオを作成するとき、各画像ファイルが約1秒間表示される必要がある場合、1秒あたり1フレームなどの非常に低いフレームレートでビデオをエンコードすることは意味があります。このタイプのアプリケーションでは、これを超えるすべてのフレームレートはリソースの無駄になります。

H264コーデック（またはx264などの特定の実装）自体にフレームレートの下限があり、それを下回ると技術的な問題や何らかの不安定性が生じるのではないかと思います。エンコードに問題がない場合、ビデオプレーヤーがこのような異常な低フレームレートを適切に処理することを期待できますか？

あなたの経験を共有してくれてありがとう！

私はAJと一緒です。これを見る可能性のあるすべてのプレーヤーの特性を知らない限り、テスト結果の小さなサンプルに依存することは賢明ではありません。24フレームのキーフレーム間隔で24 fpsのような標準フレームレートを使用すると、互換性を損なうことなく基本的に同じものが得られます。エンコードする検出可能な変更がないため、中間フレームは最小限に抑えられます。

非常に低いフレームレートでどのように動作するかはわかりませんが、クロックサイクルをたどる必要があるため、フレームを変更する方法とタイミングに関するオプションが制限されることを指摘しておく価値があります。この場合に機能する可能性が高いのは、長いキーフレーム間隔です。H.264のような圧縮のフレームの大部分は、前のフレームからの変更のみを保存します。静止画像の場合、フレーム間で変化がほとんどないため、圧縮率は非常に高くなります。フレームに変更を加えることができるときに、制御を失う価値があるほど、フレームレートを落とすことで十分な節約ができるかどうかはわかりません。

最善の策は、メディアで試して結果を確認することです。圧縮は非常にコンテンツに依存するものであり、特定のクリップの最高の品質と圧縮はそのクリップの性質に大きく依存するため、試用はそれをテストするための最良の方法です。

一連の静止写真をh.264スライドショーに変換して、主にJPGとh.264の圧縮効率を比較してみました。私が得たこの技術の影響についていくつかの有用な回答 doom9のx264の開発者からの。たとえば、あまり関係のない画像には大量のIマクロブロックが必要になるため、xフレームでBフレームを使用しないように強制します。また、それらをBフレームでコーディングするとコストが高くなります。

低fpsビデオでのソフトウェアプレーヤーの動作は、これまで理想的ではありませんでした。古いプレーヤーの1人は、フレームを表示するときにキーボード入力のみをチェックしたと思います。そのため、ユーザー入力とプレーヤーの応答の間に遅れがありました。mplayer2とmpvにはこの問題はありません。また、キーフレームのみをシークできるプレーヤーは、キーフレーム間隔を短くしないと、非常に大きなチャンク（2分程度）でシークします。x264は、画像が互いに関連している場合、IDR（GOP境界）を場所全体に挿入しません。

を使用しx264 -tune stillimageます。これは、PSYの最適化をクランクアップ経時安定性は、このユースケースのための問題ではありませんので、。さらに検索結果：googleから。

プレイヤーが悪い場合に備えて、FPSを少なくとも5かそれ以上にするために、いくつかのフレームを複製するという他の提案に同意します。ただし、スマートフォンやタブレットでは、可変FPSビデオの再生に問題はありません。通常、光量が低下すると、FPSビデオがそのように記録されるためです。携帯電話からの可変FPSビデオが出ているので、それらのハードウェアプレーヤーサポートが期待されます。私は問題を予想しませんが、少なくともいくつかの古いハードウェアプレーヤーがうまく処理できない場合でも驚かないでしょう。

すべての「スキップ」マクロブロックのフレームは、1080p、IIRCで約20バイトしかかかりません。ただし、重複したフレームが嫌いな理由の1つは、手動で画像を処理するためのシングルステップ処理が妨げられることです。

ただし、フレームの複製には圧縮の欠点があります。異なる画像の間に冗長性がある場合（つまり、スライドショーではなく、まだビデオである場合）、同一の画像でパディングすると、エンコーダーがそれを見つけて悪用することが難しくなります。

エンコーディング設定に応じて、エンコーダーは新しいフレームの参照として可能ないくつかの古いフレームのみを保持し、GOP内でのみ検索できます（たとえば、x264のデフォルトの250フレーム）。これらの候補がすべて同じ画像である場合、各ブロックのより適切な参照を見つけるための複数のオプションは提供されません。

たとえば、前景オブジェクトが背景の詳細​​の前に移動した後、エンコーダは、不明瞭になる前の古いフレームでの外観を参照してビットを節約できます。h.264は、ブロックごとに参照フレームを選択できます。これは比較的小さな影響です。優れたh.264エンコーダーは1つの参照フレームだけで問題ありませんが、圧縮効率に多少の害を及ぼし、解凍側でメモリをコピーして余分なフレームを表示するために、電力/バッテリー寿命/ CPU時間を浪費します。

NLEがすべてのクリップをいくつかの高いフレームレートに強制した後にVFRを回復する：

FFmpegには、mpdecimate類似のフレームをドロップするフィルターがあります。ドロップできる行のフレーム数に制限を設定できます。類似性のしきい値が厳しい場合は、実際の重複のみを削除する必要があります。

たとえばffmpeg -i input.mp4 -vf mpdecimate=max=9:hi=400 -c:a copy -c:v libx264 -preset veryslow -tune film output_vfr.mkv、連続して9フレームまでドロップし、最も異なるブロックが「400」で異なる場合のみ（デフォルト）：ブロックの33％以下が「320」単位だけ異なっていました。IIRC、それは基本的にピクセルコンポーネントの8x8 SADです。

（.mp4ただし、出力のFFmpegのデフォルトはCFR なので、可変フレームレート出力に使用-vsync 2します.mp4。安全だと思います：libx264でffmpegを使用したビデオ変換でのフレームレートの問題）

ほとんどのNLEでは、プロジェクトのプロパティを30 fpsや24 fpsなどの標準のフレームレートに設定した場合、タイムラインに表示する期間の形式で静止画像をインポートできます。

Vegas Proでは、静止画がタイムラインに表示される時間を、1秒未満から数秒に設定できます。これを1秒に設定した場合、タイムラインに静止画像をドラッグアンドドロップすると、Vegasは私の要求を満たすのに十分なフレームを生成します。私は通常30 fpsのビデオで編集し、静止画を追加するとき、タイムラインを既に存在する30 fpsのビデオ（AVCHD 1080p）と混合しています。

特定の答えを出すには、使用しているNLEを知る必要があります。