DASHのFFmpegでキーフレームを修正する正しい方法は何ですか？

ストリームをDASH再生用に調整する場合、ランダムアクセスポイントはすべてのストリームでまったく同じソースストリーム時間でなければなりません。これを行う通常の方法は、固定フレームレートと固定GOP長（つまり、Nフレームごとのキーフレーム）を強制することです。

FFmpegでは、固定フレームレートは簡単です（-r NUMBER）。

しかし、固定キーフレームの場所（GOPの長さ）には、3つの方法があります...どれが「正しい」ですか？FFmpegのドキュメントは、これについてイライラするほどあいまいです。

方法1：libx264の引数をいじる

-c:v libx264 -x264opts keyint=GOPSIZE:min-keyint=GOPSIZE:scenecut=-1

シーンカットが発生したときにキーフレームの「カウンター」が再起動されるかどうかは不明であるため、シーンカットをオフにするかどうかについては、いくつかの議論があるようです。

方法2：固定GOPサイズを設定する：

-g GOP_LEN_IN_FRAMES

残念ながら、これはFFMPEGのドキュメントを渡すことでのみ文書化されているため、この引数の効果は非常に不明確です。

方法3：N秒ごとにキーフレームを挿入する（たぶん？）：

-force_key_frames expr:gte(t,n_forced*GOP_LEN_IN_SECONDS)

これは明示的に文書化されています。ただし、キーフレームごとに「タイムカウンタ」が再起動するかどうかはまだ明確ではありません。たとえば、予想される5秒のGOPで、scenecutlibx264によって3秒注入されたキーフレームがある場合、次のキーフレームは5秒後ですか、それとも2秒後ですか？

実際、FFmpegのドキュメントではこれと-gオプションを区別していますが、上記の2つのオプションがどのように異なるかについては実際には言及していません（明らかに、-g固定フレームレートが必要になります）。

どちらが正しいですか？

-force_key_frames固定フレームレートを必要としないため、の方が優れていると思われます。ただし、これには以下が必要です。

• H.264のGOP仕様に準拠しています（ある場合）
• libx264 scenecutキーフレームに関係なく、固定リズムでキーフレームが存在することを保証します。

また-g-rffmpeg、異なるコーデック引数での複数の実行が各解像度で同じ瞬間フレームレートを提供するという保証がないため、固定フレームレート（）を強制しないと機能しなかったように思われます。フレームレートを固定すると、圧縮パフォーマンスが低下する場合があります（DASHシナリオでは重要です！）。

最後に、keyintメソッドはハックのように見えます。これが正しい答えではないという希望に反して願っています。

参照：

-force_key_framesメソッドを使用した例

keyintメソッドを使用した例

FFmpegの高度なビデオオプションセクション

TL; DR

以下をお勧めします。

• libx264：（およびオプションでを追加）-g X -keyint_min X-force_key_frames "expr:gte(t,n_forced*N)"
• libx265： -x265-params "keyint=X:min-keyint=X"
• libvpx-vp9： -g X

ここXで、間隔はフレームN単位で、間隔は秒単位です。たとえば、30 fpsのビデオで2秒間隔の場合、X= 60お​​よびN= 2です。

さまざまなフレームタイプに関するメモ

このトピックを適切に説明するには、最初に2つのタイプのIフレーム/キーフレームを定義する必要があります。

• インスタントデコーダリフレッシュ（IDR）フレーム：これらは、IDRフレームの前のフレームにアクセスすることなく、次のフレームの独立したデコードを可能にします。
• 非IDRフレーム：デコードを機能させるには、以前のIDRフレームが必要です。非IDRフレームは、GOP（画像のグループ）の途中でのシーンカットに使用できます。

ストリーミングには何が推奨されますか？

ストリーミングの場合、次のことを行います。

• ビデオを同じ長さのセグメントに分割できるように、すべてのIDRフレームが通常の位置（2、4、6、…秒など）にあることを確認してください。
• シーンカットの検出を有効にして、コーディングの効率/品質を改善します。これは、IDRフレームの間にIフレームを配置できるようにすることを意味します。シーンカットの検出を無効にして作業することもできます（これはまだ多くのガイドの一部です）が、必ずしも必要ではありません。

パラメーターは何をしますか？

エンコーダーを構成するには、キーフレームパラメーターの機能を理解する必要があります。私はいくつかのテストを行い、3つのエンコーダーlibx264、libx265およびlibvpx-vp9FFmpegで次のことを発見しました。

• libx264：

  • -g キーフレーム間隔を設定します。
  • -keyint_min 最小キーフレーム間隔を設定します。
  • -x264-params "keyint=x:min-keyint=y"はと同じ-g x -keyint_min yです。

  • 注：両方を同じ値に設定すると、コードに示されているように、最小値は内部的に最大間隔の半分に1を加えた値に設定されx264ます。

    h->param.i_keyint_min = x264_clip3( h->param.i_keyint_min, 1, h->param.i_keyint_max/2+1 );
    

• libx265：

  • -g 実装されていません。
  • -x265-params "keyint=x:min-keyint=y" 動作します。

• libvpx-vp9：

  • -g キーフレーム間隔を設定します。
  • -keyint_min 最小キーフレーム間隔を設定します

  • 注： FFmpegの仕組みにより、-keyint_minは、と同じ場合にのみエンコーダーに転送され-gます。libvpxenc.cFFmpeg のコードには、次のものがあります。

    if (avctx->keyint_min >= 0 && avctx->keyint_min == avctx->gop_size)
        enccfg.kf_min_dist = avctx->keyint_min;
    if (avctx->gop_size >= 0)
        enccfg.kf_max_dist = avctx->gop_size;
    

    にlibvpx異なる値の設定を確実にサポートするため、これはバグ（または機能の欠如）かもしれませんkf_min_dist。

使用すべきです-force_key_framesか？

この-force_key_framesオプションは、指定された間隔（式）でキーフレームを強制的に挿入します。これはすべてのエンコーダーで機能しますが、レート制御メカニズムを混乱させる可能性があります。特にVP9については、品質の変動が激しいことに気づいたので、この場合の使用はお勧めできません。

これが私の場合の50セントです。

方法1：

libx264の引数をいじる

-c：v libx264 -x264opts keyint = GOPSIZE：min-keyint = GOPSIZE：scenecut = -1

必要な間隔でのみiframeを生成します。

例1：

ffmpeg -i test.mp4 -codec:v libx264 \
-r 23.976 \
-x264opts "keyint=48:min-keyint=48:no-scenecut" \
-c:a copy \
-y test_keyint_48.mp4

期待どおりにiframeを生成します：

Iframes     Seconds
1           0
49          2
97          4
145         6
193         8
241         10
289         12
337         14
385         16
433         18
481         20
529         22
577         24
625         26
673         28
721         30
769         32
817         34
865         36
913         38
961         40
1009        42
1057        44
1105        46
1153        48
1201        50
1249        52
1297        54
1345        56
1393        58

方法2は減価償却されます。省略されました。

方法3：

N秒ごとにキーフレームを挿入します（MAYBE）：

-force_key_frames expr：gte（t、n_forced * GOP_LEN_IN_SECONDS）

例2

ffmpeg -i test.mp4 -codec:v libx264 \
-r 23.976 \
-force_key_frames "expr:gte(t,n_forced*2)"
-c:a copy \
-y test_fkf_2.mp4

少し異なる方法でiframeを生成します。

Iframes     Seconds
1           0
49          2
97          4
145         6
193         8
241         10
289         12
337         14
385         16
433         18
481         20
519         21.58333333
529         22
577         24
625         26
673         28
721         30
769         32
817         34
865         36
913         38
931         38.75
941         39.16666667
961         40
1008        42
1056        44
1104        46
1152        48
1200        50
1248        52
1296        54
1305        54.375
1344        56
1367        56.95833333
1392        58
1430        59.58333333
1440        60
1475        61.45833333
1488        62
1536        64
1544        64.33333333
1584        66
1591        66.29166667
1632        68
1680        70
1728        72
1765        73.54166667
1776        74
1811        75.45833333
1824        75.95833333
1853        77.16666667
1872        77.95833333
1896        78.95833333
1920        79.95833333
1939        80.75
1968        81.95833333

ご覧のとおり、2秒ごとにiframeを配置し、ビデオストリームの複雑さにとって重要なシーンカット（フローティング部分のある秒）に配置します。

生成されたファイルサイズはほぼ同じです。方法3でより多くのキーフレームを使用しても非常に奇妙ですで使用しても、標準のx264ライブラリアルゴリズムよりも少ないファイルが生成されることがです。

HLSストリームの複数のビットレートファイルを生成するには、方法3を選択します。チャンク間の2秒と完全に一致し、すべてのチャンクの先頭にiframeがあり、複雑なシーンに追加のiframeがあり、古いデバイスを持ち、x264ハイプロファイルを再生できないユーザーにより良いエクスペリエンスを提供します。

それが誰かを助けることを願っています。

したがって、答えは次のように思われます。

• 方法1は機能することが確認されていますが、libx264特定の方法であり、非常に便利なscenecutオプションを削除するという代償を払っていますlibx264。
• 方法3は2015年4月のFFMPEGバージョンの時点で機能しますが、オプションの効果についてはFFMPEGのドキュメントが不明であるため、この投稿の最後に含まれるスクリプトで結果を確認する必要があります。動作する場合は、2つのオプションの上位です。
• 方法2は使用-gしないでください。動作していないように見えたり、ドキュメントで明示的に定義されたり、ヘルプで見つかったり、コードで使用されているようには見えません。コードインスペクションは、この-gオプションがMPEG-2ストリーム向けであることを示しています（PALおよびNTSCを参照するコードスタンザもあります！）。

また：

• インタースティシャルIフレーム（キーフレーム）が許可されているため、方法3で生成されたファイルは方法1よりわずかに大きくなる場合があります。
• 明示的にも上または次frameslotの方法3ヶ所のIフレームが、どちらの場合も「-r」フラグを設定する必要があります後指定した時間ます。「-r」フラグの設定に失敗すると、ソースファイルを使いこなすことになり、フレームレートが変動する可能性があります。互換性のないDASH遷移が発生する場合があります。
• FFMPEGドキュメントの警告にもかかわらず、方法3は他の方法よりも効率的ではありません。実際、テストでは、方法1よりもわずかに効率的であることが示されています。

-force_key_framesオプションのスクリプト

これは、shlckのffprobe提案の出力に基づいてIフレームケイデンスを検証するために使用した短いPERLプログラムです。-force_key_framesメソッドが機能することを検証しているようで、scenecutフレームを許可するという追加の利点があります。FFMPEGがこの機能をどのように実現するのか、またはストリームの状態が良好なためにどういうわけか運が良かったのか、まったくわかりません。

私の場合、予想されるGOPサイズは6秒、つまり180フレームで、30fpsでエンコードしました。このプログラムのgopsize引数として180を使用して、180の倍数ごとにIフレームを検証しましたが、それを181（または180の倍数ではない他の数）に設定すると文句を言われました。

#!/usr/bin/perl
use strict;
my $gopsize = shift(@ARGV);
my $file = shift(@ARGV);
print "GOPSIZE = $gopsize\n";
my $linenum = 0;
my $expected = 0;
open my $pipe, "ffprobe -i $file -select_streams v -show_frames -of csv -show_entries frame=pict_type |"
        or die "Blah";
while (<$pipe>) {
  if ($linenum > $expected) {
    # Won't catch all the misses. But even one is good enough to fail.
    print "Missed IFrame at $expected\n";
    $expected = (int($linenum/$gopsize) + 1)*$gopsize;
  }
  if (m/,I\s*$/) {
    if ($linenum < $expected) {
      # Don't care term, just an extra I frame. Snore.
      #print "Free IFrame at $linenum\n";
    } else {
      #print "IFrame HIT at $expected\n";
      $expected += $gopsize;
    }
  }
  $linenum += 1;
}

ここで情報を追加したかったのは、グーグルがこの議論をかなり求めて、DASHエンコーディングを希望する方法でセグメント化する方法を見つけるための情報を見つけるための情報を見つけたからです。

取り除くための最初のいくつかの誤解：

1. すべてのIフレームが同じというわけではありません。大きな「I」フレームと小さな「i」フレームがあります。または、正しい用語、IDR I-Frameおよび非IDR I-Frameを使用します。IDR Iフレーム（「キーフレーム」と呼ばれることもあります）は、新しいGOPを作成します。非IDRフレームはサポートしません。シーンの変化があるGOPの内部にあると便利です。

2. -x264opts keyint=GOPSIZE:min-keyint=GOPSIZE←これはあなたが思っていることをしません。これを理解するのに少し時間がかかりました。それは判明min-keyintコードに限定されています。を超えることはできません(keyint / 2) + 1。したがって、これら2つの変数に同じ値を割り当てると、次の値になります。min-keyintエンコード時に半分にノックダウンされるなります。

シーンカットは本当に素晴らしく、特に高速のハードカットを含むビデオでは特に効果的です。それは素晴らしく、鮮明に保たれるので、私はそれを無効にしたくはありませんが、同時に、有効になっている限り固定GOPサイズを得ることができませんでした。シーンカットを有効にしたかったのですが、IDR以外のIフレームのみを使用するようにしました。しかし、それは機能していませんでした。誤解＃2について（たくさんの読書から）理解するまで。

keyint希望のGOPサイズを2倍に設定する必要がありました。これはmin-keyint、目的のGOPサイズに設定できることを意味します（内部コードを半分にカットすることなく）、最後のIDR Iフレーム以降のフレームカウントが常に未満ですmin-keyinit。

そして最後にforce_key_frameオプションを設定すると、doubleサイズが上書きされkeyintます。だからここに働くものです：

私は2秒単位のセグメントを好むので、GOPSIZE =フレームレート* 2

ffmpeg <other_options> -force_key_frames "expr:eq(mod(n,<GOPSIZE>),0)" -x264opts rc-lookahead=<GOPSIZE>:keyint=<GOPSIZE * 2>:min-keyint=<GOPSIZE> <other_options>

ffprobeを使用して確認できます。

ffprobe <SRC_FLE> -select_streams v -show_frames -of csv -show_entries frame=coded_picture_number,key_frame,pict_type > frames.csv

生成されたCSVファイルでは、各行が次のことを示しますframe, [is_an_IDR_?], [frame_type], [frame_number]。

frame,1,I,60  <-- frame 60, is I frame, 1 means is an IDR I-frame (aka KeyFrame)
frame,0,I,71  <-- frame 71, is I frame, 0 means not an IDR I_frame

その結果、IDR I-Frameは一定のGOPSIZE間隔でのみ表示されるはずですが、他のすべてのIフレームは、シーンカット検出で必要に応じて挿入された非IDR I-Frame です。

この構文は常に機能しないようです。VODコンテンツとライブコンテンツ（ファイルダンプ）でかなり多くのテストを行い、シーンカットが機能せず、ibetween iframeをトリガーすることがあります。

i50-> p50アップコンバートの構文、2秒のgop /セグメント、開始時のIDR、必要に応じてiframeの中間

ffmpeg.exe -loglevel verbose -i avc_50i.ts -pix_fmt yuv420p -filter_complex yadif=1,scale=1920:1080 -vcodec libx264 -preset fast -x264-params "rc-lookahead=100:keyint=200:min-keyint=100:hrd=1:vbv_maxrate=12000:vbv_bufsize=12000:no-open-gop=1" -r 50 -crf 22 -force_key_frames "expr:eq(mod(n,100),0)" -codec:a aac -b:a 128k -y target.ts

Twitchにはこれに関する投稿があります。彼らは、いくつかの理由で独自のプログラムを使用することに決めたと説明しています。その1つは、ffmpegでは、異なるスレッドで異なるx264インスタンスを実行できないが、代わりに、指定されたすべてのスレッドを1つの出力の1つのフレームに割り当ててから次の出力に進むというものでした。

リアルタイムストリーミングを行っていない場合は、さらに贅沢を味わえます。「正しい」方法は、おそらく-gで指定されたGOPサイズだけで1つの解像度でエンコードし、その後、同じ場所でキーフレームを強制する他の解像度でエンコードすることです。

これを行うには、ffprobeを使用してキーフレーム時間を取得し、シェルスクリプトまたは実際のプログラミング言語を使用してそれをffmpegコマンドに変換します。

ただし、ほとんどのコンテンツでは、5秒ごとに1つのキーフレームと5秒ごとに2つのキーフレーム（強制的に1つとシーンカットから1つ）を使用してもほとんど違いはありません。これは、PフレームとBフレームのサイズに対するIフレームの平均サイズです。通常の設定でx264を使用する場合（これらに影響を与えるために何かを行う必要があると思う唯一の理由は、簡単なコンテンツでx264がビットレートを使用できないようにする-qminを設定する場合です。 、私は思う）、46 kBのIフレーム平均サイズ、Pフレーム24 kB、Bフレーム17 kB（Pフレームの半分の頻度）、30 fpsで毎秒余分なIフレームのような結果を得るファイルサイズが3％増加するだけです。h264とh263の違いは、3％の減少で構成されている可能性がありますが、1つの違いはそれほど重要ではありません。

他の種類のコンテンツでは、フレームサイズが異なります。公平を期すために、これは空間的な複雑さではなく時間的な複雑さに関するものであるため、単純なコンテンツとハードなコンテンツではありません。ただし、一般的に、ストリーミングビデオサイトにはビットレートの制限があり、比較的大きなIフレームを持つコンテンツは、追加のキーフレームがいくつ追加されても高品質でエンコードされる簡単なコンテンツです。それは無駄ですが、この無駄は通常は気づかれません。最も無駄なケースはおそらく、各キーフレームがまったく同じである、歌に付随する単なる静止画像のビデオです。

私が確信していないことの1つは、-maxrateおよび-bufsizeで設定されたレートリミッターと強制キーフレームがどのように相互作用するかです。YouTubeでさえ、バッファ設定を正しく構成して一貫した品質を提供する最近の問題があったと思います。一部のサイトで見られるような平均ビットレート設定を使用している場合（ヘッダー/ movアトムのx264のオプションを16進エディターで検査できるため）、バッファーモデルは問題ではありませんが、ユーザーが生成したコンテンツを配信する場合、平均ビットレートにより、ユーザーはビデオの最後に黒い画面を追加するようになります。

Ffmpegの-gオプション、または使用するその他のエンコーダオプションは、エンコーダ固有のオプションにマップされます。したがって、「-x264-params keyint = GOPSIZE」は「-g GOPSIZE」と同等です。

シーン検出の使用に関する1つの問題は、何らかの理由で特定の数値に近いキーフレームを好む場合です。5秒ごとにキーフレームを指定してシーン検出を使用し、4.5でシーンが変化した場合、検出されるはずですが、次のキーフレームは9.5になります。時間がこのようにステップアップし続けると、40、45、50、55の代わりに42.5、47.5、52.5などのキーフレームになってしまう可能性があります。逆に、5.5でシーンが変更されると、 5と5.5のキーフレームは、他のキーフレームには早すぎます。Ffmpegでは、「次の30フレーム内にシーンの変更がない場合、ここにキーフレームを作成する」ことを指定できません。ただし、Cを理解している人はそのオプションを追加できます。

可変フレームレートビデオの場合、Twitchのようなライブストリーミングではない場合、恒久的なフレームレートに永続的に変換することなくシーンの変更を使用できるはずです。ffmpegで「select」フィルターを使用し、式で「scene」定数を使用すると、デバッグ出力（-v debugまたはエンコード中に「+」を数回押す）にシーン変更番号が表示されます。これはおそらく、x264で使用されている数値とは異なり、それほど有用ではありませんが、それでも有用な場合があります。

したがって、手順はおそらく、キーフレームの変更のみを目的としたテストビデオを実行することですが、2パスを使用している場合はレート制御データに使用できます。（生成されたデータがさまざまな解像度と設定に役立つかどうかはわかりません。マクロブロックツリーデータは役に立ちません。）一定フレームレートのビデオに変換しますが、このバグを参照あなたが判断した場合、フレームレートを半分にすると出力を吃音についてfpsフィルターを他の目的に使用するには。希望するキーフレームとGOP設定でx264を介して実行します。

次に、これらのキーフレーム時間を元の可変フレームレートビデオで使用します。

フレーム間に20秒のギャップがある完全にクレイジーなユーザー生成コンテンツを許可する場合、可変フレームレートエンコードの場合、出力を分割し、fpsフィルターを使用し、何らかの方法でselectフィルターを使用できます（おそらく、すべてのキーフレーム時間）...またはテストビデオを入力として使用し、そのffmpegオプションが機能する場合はキーフレームのみをデコードするか、選択フィルターを使用してキーフレームを選択することができます。次に、正しいサイズにスケーリングし（このためのscale2refフィルターもあります）、元のビデオをオーバーレイします。次に、インターリーブフィルターを使用して、これらの強制キーフレームを元のビデオと組み合わせます。これにより、インターリーブフィルターが妨げない2つのフレームが0.001秒離れている場合は、別の選択フィルターを使用してこの問題を自分で解決してください。ここでは、インターリーブフィルターのフレームバッファー制限に対処することが主な問題になる可能性があります。これらはすべて動作する可能性があります。何らかの種類のフィルターを使用して、より高密度のストリームをバッファーに入れます（FIFOフィルター？）。入力ファイルを複数回参照するため、複数回デコードされ、フレームを保存する必要はありません。「streamselect」フィルターを使用します。これは、キーフレームの正確なタイミングで、これまで行ったことのないものです。デフォルトの動作を変更するか、フレームをドロップする代わりにバッファの最も古いフレームを出力するオプションを追加することにより、インターリーブフィルターを改善します。キーフレームの正確なタイミングで、私は一度もやったことがありません。デフォルトの動作を変更するか、フレームをドロップする代わりにバッファ内の最も古いフレームを出力するオプションを追加して、インターリーブフィルターを改善します。キーフレームの正確なタイミングで、私は一度もやったことがありません。デフォルトの動作を変更するか、フレームをドロップする代わりにバッファ内の最も古いフレームを出力するオプションを追加して、インターリーブフィルターを改善します。