FFmpeg 1.0で実際に動作するチートシートとプリセット設定?


28

他の場所で入手できる「チートシート」をいくつか試しましたが、ほとんどすべてが古くなっており、FFMpegの最新バージョンでは動作しません。

誰もが最新のFFMpegで動作する設定を教えてもらえますか?

私は主に次のコーデックに興味があります

H.264、低中および高品質のプリセット

と同様

ProRes、低中および高品質のプリセット

回答:


49

FFmpegには、libx264のテキストファイルベースのプリセットとプロファイル、つまり-vpreオプションで使用したものは含まれなくなりました。これらは、プロファイル(および曲)と実際のx264のプリセットにアクセスするの賛成で償却し、削除された-preset-profile:v、および-tuneオプション。古いテキストファイルは公式のx264プリセットとプロファイルのみをエミュレートし、いくつかの制限により、新しいシステムが提供するすべての機能を提供できませんでした。また、保守がはるかに簡単です。

さらに、多くのエンコーダーには独自のオプションがあります。「プライベートオプション」とも呼ばれます。FFmpegオンラインドキュメントで一般的なコーデックのオーディオおよびビデオエンコーダーオプションを調べるか、ffmpeg -h fullサポートされているオプションの完全なリストについての出力を確認する必要があります。たとえば、x264のオプションlibx264 AVOptionsは、完全なヘルプ出力にリストされています。

ffmpegがサポートしている場合-presetは、テキストファイルプリセットを使用しないでください。FFmpegには、非標準のiPodプリセット以外のものは付属していません。テキストプリセットはどこからでも簡単にコピーでき、ffmpegで使用できるというのはよくある誤解です。これは誤りであり、破損につながります。


基本的に、プリセットにより次のことができます。

品質管理

品質は、-b:v(ビデオの場合)または-b:a(オーディオの場合)でビットレートを指定するか、コーデックがサポートする他のエンコード方法を指定することで制御されます。

x264には、さまざまなエンコード方式があり、Constant Rate Factor方式が最も洗練されています。可変ビットレートになりますが、1回のパスで全体的に良質です。CRF値の範囲は0〜51ですが、ソースと希望する品質に応じて、適切な値は19〜26の間です。23がデフォルトであるため、たとえば「高品質」には18、「低品質」には28を選択できます。

ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4

x264には他のエンコード方式もありますが、これはここでは範囲外です。

H.264プロファイルを制限する

これらのプロファイルは、特定のデコーダーの機能を一致させるためにエンコーダーが使用できる機能セットを定義します。最近のFFmpegでは、プロファイルは可能性プロファイルを、指定するには、次の構文を使用しbaselinemainまたはhigh

ffmpeg -i input.mp4 -c:v libx264 -profile:v baseline output.mp4

詳細と、どのプロファイルをいつ使用する必要があるかについては、「H.264プロファイルの違いは何ですか?」を参照してください

x264エンコードを選択する preset

これらのプリセットはエンコード速度に影響します。低速のプリセットを使用すると圧縮率またはファイルサイズごとの品質が向上し、高速のプリセットを使用すると圧縮率が低下します。一般的に、待つ余裕のあるプリセットを使用する必要があります。プリセットすることができultrafastsuperfastveryfastfasterfastmedium(デフォルト)、slowおよびveryslow。以下に例を示します。

ffmpeg -i input.mp4 -c:v libx264 -preset slow output.mp4

ロスレスビデオをエンコードする

これは、0のCRFを指定することで可能になるため、単に使用します-crf 0

ffmpeg -i input.mp4 -c:v libx264 -crf 0 output.mp4

最後に、ProResについて簡単に説明しましょう。ProResは、で固定ビットレートを受け入れるか-b:v、プロファイルを指定できます。これは、プロファイルに従ってビットレートが選択される0〜3の値にする必要があります。高いほど良いことを意味します:

ffmpeg -i input.mp4 -c:v prores -profile:v 0 output.mov

ffmbcウィキは、プロファイルの名前を使用することができることを示唆している-これは、しかしFFmpegの1.0に失敗します。


変換が失敗する可能性を減らすために何をすべきですか、それはランダムに発生していますが、時々発生しません
FlyingAtom

@FlyingAtom「Conversion Fail」についてはまだ聞いていません。再現可能な問題に関する特定の質問がある場合は、新しい質問をしてください:superuser.com/questions/ask
slhck

それで、もしあなたが提供したものがすべてだったら、あなたは事実上何になりますffmpeg -i input.mp4 -c:v libx264 output.mp4か?crf:23およびpreset:medium?
ドラジェンBjelovuk

1
@Drazenはい、そうです。
-slhck

乾杯!-------
Drazen Bjelovuk

20

.mp4CRF値の範囲(18、21、24 、および27)でプリセット値の全範囲(プラセボを除く)を使用して、Sonyカムコーダーから高品質ビデオをトランスコードする(libx264エンコーディングを使用して)テストを行いました)。エンコード速度、出力品質、ファイルサイズの最適な組み合わせを提供するものを知りたいと思いました。

各CRF値について、各トランスコード操作にそのエンコード時間のスコアを付けました(たとえば、CRF = 18の場合、プリセット値ultrafastの5.7秒は1.0、非常に遅い162秒の時間は0で、すべて他のスコアはその間にスケーリングされます)。出力ファイルサイズのスコアを同様に計算しました。もちろん、最小のファイルに最高のスコアを与えました。次に、速度とサイズを組み合わせた「スコア」の2つのスコアを追加しました。

4つのCRF値のそれぞれについて、「非常に速い」プリセットがハンズダウンの勝者であり、1.94(CRF 18および21)、1.96(CRF 24)および1.97(CRF 27)のほぼ完全なスコアでした。「非常に速い」が毎回ほぼ最小のファイルサイズを生成し、「非常に遅い」だけで、決して多くは失われないことに非常に興味があります

さまざまなプリセット値の中で気づいた違いの1つは、オペレーティングシステム(Windows 7)によって異なるサムネイルが表示されることです。速いプリセットでは、ビデオの数秒後にサムネイルが表示され、遅いプリセットのサムネイルはビデオの開始フレームを反映します。それは私にとって重要ではありません。私が学んだことは、「-preset veryfast」が簡単な選択のように見えることです。

私の結果は次のとおりです(Excelスプレッドシートのスナップショット画像として):
優れたスナップショット

これは、csvテキストとしてのExcelスプレッドシートです。

CRF,Preset,Seconds,score,MB,score,totalscore
18,1_ultrafast,5.7,1.00,59.5,0.09,1.09
18,2_superfast,8.4,0.98,62.3,0.00,0.98
18,3_veryfast,10.8,0.97,30.9,0.98,1.94
18,4_faster,16.0,0.93,33.5,0.89,1.83
18,5_fast,24.0,0.88,36.8,0.79,1.68
18,6_medium,29.1,0.85,34.9,0.85,1.70
18,7_slow,48.1,0.73,33.9,0.88,1.61
18,8_slower,84.9,0.49,33.0,0.91,1.40
18,9_veryslow,162.0,0.00,30.1,1.00,1.00
21,1_ultrafast,5.7,1.00,38.0,0.00,1.00
21,2_superfast,7.9,0.98,35.0,0.15,1.14
21,3_veryfast,10.0,0.97,19.0,0.97,1.94
21,4_faster,14.2,0.94,21.0,0.87,1.80
21,5_fast,19.9,0.89,23.0,0.77,1.66
21,6_medium,24.6,0.86,22.0,0.82,1.67
21,7_slow,43.1,0.72,21.0,0.87,1.58
21,8_slower,69.8,0.51,20.5,0.89,1.41
21,9_veryslow,137.3,0.00,18.4,1.00,1.00
24,1_ultrafast,5.5,1.00,24.9,0.00,1.00
24,2_superfast,7.5,0.98,21.4,0.27,1.25
24,3_veryfast,9.3,0.97,12.0,0.99,1.96
24,4_faster,13.2,0.93,14.0,0.84,1.77
24,5_fast,17.4,0.90,15.0,0.76,1.66
24,6_medium,21.0,0.87,14.4,0.81,1.67
24,7_slow,37.3,0.72,14.0,0.84,1.56
24,8_slower,62.2,0.51,13.0,0.92,1.42
24,9_veryslow,121.1,0.00,11.9,1.00,1.00
27,1_ultrafast,5.5,1.00,16.8,0.00,1.00
27,2_superfast,7.4,0.98,13.6,0.38,1.36
27,3_veryfast,9.0,0.97,8.4,1.00,1.97
27,4_faster,12.6,0.93,10.1,0.80,1.73
27,5_fast,15.8,0.90,10.4,0.76,1.66
27,6_medium,18.8,0.87,10.0,0.81,1.68
27,7_slow,34.1,0.73,9.8,0.83,1.56
27,8_slower,59.6,0.48,9.0,0.93,1.41
27,9_veryslow,109.7,0.00,8.4,1.00,1.00

3
スーパーユーザーの書式設定オプションは平凡ですが、データをテキストとして投稿した方が便利かもしれません-コードの書式設定を使用する可能性があります。
スコット

1
魅力的です。私のマシンでも高速です。ありがとう!
-joeytwiddle

1
私は疑いを持ってあなたの結果を見ていたことを認めなければなりませんが、テストを繰り返して、2分1080pのムービークリップでffmpegバージョン3.3.2-1を使用して、同様の結果を得ました。実際、60%の時間で非常に高速にファイルサイズが最小になり、40%の時間で2番目から非常に遅くなりました(ただし、それほどではありません)。これからは、非常に速いCRF値(18、19、20)とともに、すべてのエンコードに非常に速い速度を使用します。たくさんの時間を節約してくれてありがとう。下のコメントの生データとスクリプト。
マット

1
上記のコメントから続けます...ここに私の生データがあります-CRF 18から27と、エンコードを実行するために書いたLinux / UNIX bashスクリプトです(誰かが同様のテストを実行したい場合)。
マット

1
以下は、テーマに関する素晴らしいブログ投稿です。x264x265でテストが実施されています(予想
どおり
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.