web-dev-qa-db-ja.com

ffmpegのconcatdemuxerのビデオを作成するためのパラメーターの指定（大規模な再エンコードを回避するため）

ffmpegを使用して ファイルを連結する ：

まったく同じコーデックとコーデックパラメータを持つメディアファイルがある場合は、それらを連結できます[...]

（私の強調）私の意図1 同じコーデックとパラメータでメディアファイルを作成することで、長い再エンコードを行わずに連結を利用できるようになります。

前文：

有用な部分を切り取って保管したいファイルがあります。 pythonスクリプトを作成して、目的のカットポイントに最も近いキーフレームを見つけ、そこでカットしました。ストリームコピーを実行する場合、ffmpegはIフレームしか使用できないためです。

-ssを-c：vコピーと一緒に入力オプションとして使用すると、ffmpegはiフレームでのみ使用/分割するように強制されるため、正確でない場合があります。

たまたま、分割は正確に正しい瞬間に起こっていませんが、方程式の別の部分に集中できる瞬間には十分に近いです。この時点でconcatデマルチプレクサを使用すると、さまざまなパーツが完全に結合されます。これまでのところ、これで問題ありません。

ただし、これらのセグメント間でスムーズな遷移が必要なため、これらのセグメントをさらに分割して、ファイルのセット全体を再エンコードせずに、短い方の端を使用してクロスフェード遷移を作成できるようにしました。

基本的な図は、おそらくこれを説明するのに役立ちます。

  [111AAAA111BBBBB111111CCCCCCC1111DDDDD111]   | (original file)
     [AAAA] [BBBBB]    [CCCCCCC]  [DDDDD]      | (desired clips extracted)
[AAA] [A][B] [BBB] [B][C] [CCCCC] [C][D] [DDDD]| (split ends from clips)
      [AAA][ab][BBB][bc][CCCCC][cd][DDD]       | (transitions between short ends)
            [AAAabBBBbcCCCCCcdDDD]             | (intended output)

問題：

これは私が到達したところです。 ffmpegのconcat demuxerを使用して上記のクリップを結合すると、再生時に重要なビデオおよびオーディオアーティファクトが発生します。私の推測では、この質問の冒頭に前提条件として記載されているように、コーデックパラメータに不一致があります。したがって、ffprobeでビデオをチェックすると次のようになります。

$ ffprobe -i ab-transition.mkv 2>&1 | grep Stream.*Video ; ffprobe -i B.mkv 2>&1 | grep Stream.*Video
Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709/bt709/iec61966-2-1), 1280x720, SAR 1:1 DAR 16:9, 62.50 fps, 62.50 tbr, 1k tbn, 120 tbc (default)
Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709/bt709/iec61966-2-1), 1280x720 [SAR 1:1 DAR 16:9], 62.50 fps, 62.50 tbr, 1k tbn, 125 tbc (default)

（ストリームのパラメーターは表面上同じであるため、オーディオストリームの出力を省略しましたが、オーディオは正しく結合されていません）

違いがあります。 -show_streamsを使用して、より詳細な情報を取得しました。詳細情報は、 http://Pastebin.com/4vcnDYtj （2つの出力を区切る単一の空白行）で入手できます。出力をdiffingすると、次のようになります。

7c7
< codec_time_base=1/120
---
> codec_time_base=1/125
70,71c70,71
< start_pts=12
< start_time=0.012000
---
> start_pts=11
> start_time=0.011000

更新：

コーデックのタイムベース（tbc）を除いて、表示されるすべてのオプションと一致するパラメーターを見つけました。 codec_time_base（tbc）を設定できる設定はありますか？ -rを設定しても効果はありません。

更新2：この質問がSUにとってニッチすぎることを恐れて、私はffmpeg-userメーリングリストに質問しました。残念ながら、この場合、-time_baseは適切なエンコーダオプションではありません。

これはFFmpegのオプションです-外部エンコーダー（x264）に使用しようとする内部エンコーダー。

そしてもっと残念なことに、私が一般的な実現可能性について尋ねたとき、答えは

これは不可能だと思います。

元のエンコーディングソフトウェア（この場合はOBS）を取り巻く説明と可能性を求めました。これは、ライブストリームコンシューマー（Twitch）形式と一致する必要があるため、オプション仕様の柔軟性がffmpegよりも低い可能性があります。仕様。メーリングリストからの返信はまだありませんが、OBSフォーラムでも質問しています。

さらに重要なことに、これらを制御することで、concatのffmpeg demuxerを使用して、長いエンコードプロセスを必要とせずにこれらを結合できます？よろしくお願いします。

（これはテキストの壁であることに気付いたので、追加、減算、または説明の提案はもちろん歓迎します。より公式な情報にリンクしますが、10 rep未満であるため、2つ以上のリンクを含めることはできません。 ）

1：詳細については、関連する質問を参照してください： 短いトランジションを使用してビデオクリップを効率的かつ自動的に結合する方法は？

ffmpegvideo-encodingvideo-codecs
2
bertieb

一般的なコーデックオプション によると、トランジショナルクリップの作成中にlibx264エンコーダセットに-time_baseを追加できます。

ファイル比較を正しく読んでいる場合--ab-transition.mkvは1/120のtcbを示していますが、B.mkvは1/125を示しています（必要な値ですよね？）-フレームレートとタイムベースの両方が維持されるように、-r値も含めることをお勧めします。

-c:v libx264 [preset & crf/qp settings] -r 62.50 -time_base 1/125 [output]

ちなみに、concat demuxer withoutを完全に再エンコードしようとすると、常に問題が発生し、主にオーディオの同期とフレームのドロップが発生します。最良の結果は、元の品質を維持するためにロスレスオーディオとビデオで別々のクリップをエンコードすることによって得られました...

-c:v -libx264 -preset ultrafast -qp 0 -c:a pcm_s16le

...次に、ソースビデオの作成に使用したのと同じオーディオ/ビデオ設定を使用して最終ファイルをエンコードします。

2
Mr. What