FFMPEGで変換されたビデオの再生時間が異なります。なぜですか？

FFMPEGを使用してビデオを変換します。私の目標は、AACエンコードされたオーディオストリームとMPEG-4パート10エンコードされたビデオストリームを使用して、それらをMP4コンテナー形式（MPEG-4パート14）に変換することです。

次の行を使用してビデオを変換します。

ffmpeg -y -i "{inputFile}" "{outputFile}"

変換されたビデオは正常に見えますが、変換されたファイルと入力ファイルのストリームの長さが常に一致するとは限りません。

私はいくつかの実験を行いましたが、デュレーションの違いは間違いなくそこにありますが、それほどではありません-とにかく私は小さなビデオでテストしています。これが私の結果です：

| InputFile  | InputAudio | InputVideo | OutputAudio | OutputVideo  |
|------------|------------|------------|-------------|--------------|
| h.avi      | 3s 631ms   | 3s 567ms   | 3s 668ms    | 3s 567ms     |
| h.flv      | 3s 631ms   | 3s 558ms   | 3s 668ms    | 3s 567ms     |
| h.mov      | 3s 532ms   | 3s 533ms   | 3s 682ms    | 3s 534ms     |
| h.mp4      | 3s 605ms   | 3s 534ms   | 3s 682ms    | 3s 567ms     |
| h.mpg      | 3s 605ms   | 3s 533ms   | 3s 563ms    | 3s 534ms     |
| h.wmv      | 3s 620ms   | 3s 633ms   | 3s 659ms    | 3s 567ms     |

私はFFMPEGの上にソフトウェアを構築するので、少なくともこの違いの理由を理解できれば幸いです。不要なトランスコーディングが原因ですか？

この場合、FFMPEGが入力ビデオファイルをリサンプリングしないように、このトランスコーディングをオフにできますか？

オフにできない場合、（テスト以外に）この違いがビデオのサイズに比例していないことをどのように確認できますか？

たとえば10時間のビデオを変換する場合、数秒から数分の差は私には適していません。

— Zsolt
ソース

入力コーデックと出力コーデックに依存すると思います。長いGOPコーデックは、必要な場所にキーフレームを配置してGOPを閉じるために、ビデオストリームの継続時間を変更する場合があります。イントラコーデックからイントラコーデックにトランスコーディングする場合は、この問題に直面しないでください。ビデオを再エンコードする必要がない場合、ターゲットコンテナーがこのコーデックをサポートしていれば、オプション 'c：v copy'を使用します。

— audionuma

動画が長くなっても長さの違いは悪化しないと思います。速度ドリフトなどではなく、開始/終了の問題である可能性が高くなります。ffmpegを使用してxcodeを実行すると、フレーム数、フレームレート、長さ（秒）は常に同じままです。（私がそれを変えたいのでなければ！）

— Peter Cordes

@audionuma：健全なコーデックはフレームを追加/削除しません。mencoderは、A / V同期のために、フレームをビデオコーデックに送る前に実行することがあります。コーデックは、適切と思われる場所（固定間隔またはシーンカット）にキーフレームを配置し、エンコーダーがコーデックにこれが最後のフレームであることを伝えると、その最後のGOPを閉じますが、その長さは異なります。非適応キーフレーム配置でも、コーデックは最後のGOPを同じ長さにするためだけにフレームを追加しません！

— Peter Cordes

この説明があなたが探しているものであることを願っています：

H.264（MPEG-4 part 10）などのエンコーディングにトランスコードする場合は、必ずH.264圧縮技術の一部であるビデオもリサンプリングする必要があります。それにもかかわらず、リサンプリングが必ずしもメディアのクロックレートに影響を与えるわけではないので、これがタイミングのギャップを経験する理由であるかどうかは疑問です。だから、私はリサンプリングについてあまり心配しません、それは多少の変動を引き起こす可能性がありますが、おそらく非常にわずかです。
リストしたコンテナ形式は、圧縮ストリームのパッケージ方法を定義しているため、あまり関係ありませんが、タイミングの違いの原因は圧縮そのものです。.flvファイルには、例えば、従来のフラッシュソレンソンコーデック以降H.264でエンコードされたストリームが含まれていてもよいです。前者の場合はビデオストリームをトランスコーディングしますが、後者の場合は、使用しないオーディオコーデックによっては、そうでない場合もあります。.aviそして.wmvコンテナはコーデックにとらわれない、そうでもそのコンテンツのエンコーディングを推測する方法はありません。
期間がどのようにテストされたかについては言及しませんでした。ffmpegは、デフォルトでは、計算された値ではなく、ファイルのメタデータに表示される期間を表示することに注意してください。リストがスプラッシュ通知の一部としてffmpegがダンプするデータに基づいている場合、これは明示的にメタデータであり、実際の測定値ではないことに注意してください。
あなたが提示した期間のデルタは、25または30 fpsの範囲の1つまたは2つのフレームの範囲内です。コーデックがそのアルゴリズム（または開発者の整頓...）に従ってストリームの空白フレームをパディングまたはストリップするのは合理的です。ストリームを適切に連結する場合、タイムスタンプに影響を与えるべきではありません。
メディアの継続時間を大幅に変更できる理由は2つだけ考えられますが、特定のケースには該当しません。
1. 別のターゲット速度で再エンコードします。入力ファイルの不正なメタデータが原因で、これが意図せずに発生する場合があります。ただし、上記のように、ドロップまたは取得された単一のフレームに対応する場合はそうではありません。
2. いずれかのストリームを再作成するコーデックを適用する場合。例としては、広告除去、無音検出、ノイズクレンジングなどがあります。

結論として、10時間のビデオで何が起こるか心配な場合は、実際のテストを実行してください。問題が発生して支援を求めた場合は、入力ファイルのコーデックの詳細とストリームの継続時間を測定した方法を投稿することを忘れないでください。

お役に立てれば。

— avnr
ソース

実際には、おそらくコンテナのフォーマットが適切です。コンテナによって、タイムスタンプ/フレーム期間の保存方法が異なります。そして、長さ計算機は異なるコンテナー形式に対して異なるコードを必要とし、そのコードは異なる動作をするかもしれません。たとえば、最後のフレームが表示される期間をカウントしますが、別のフレームでは表示されません。

— Peter Cordes

@PeterCordes、コメントで「長さ」とはどういう意味ですか？「継続時間」を意味したい場合、それは間違いです。継続時間は常にフレーム数にタイムベースを掛けたものです。他のことを意味する場合は、「長さ」で何を意味するのかを示してください。

— avnr 2015

持続時間を意味しました。すべてのビデオが一定のフレームレートであるとは限りません。また、フレームの継続時間を格納する方法（一部または通常、タイムベースの倍数）は、コンテナーごとに異なります。詳細を見ていなかったので、これは私の手にとって波打つようなものでしたが、思ったほど簡単ではないことは確かです。

— Peter Cordes

@PeterCordes、大丈夫ですが、これは非常にまれであり、実際にはここには属しません。これは、スクリーンレコーディング、スライドショーなどの一部のエッジケースでのみ使用されます。編集ソフトウェアでは、可変フレームレートという用語の誤用がありますが、彼らの場合、より簡潔な用語はハイブリッドビデオです（つまり、異なるレートまたはタイムベースのストリームであり、多重化されたときに元の一定のレートを維持します）。「通常の映画」の場合、コンテナがメタデータでそれをどのように表すかに関係なく、ほとんど常に既知のフレームレートがあります。

— avnr 2015年