ロスレスユニバーサルビデオフォーマット

1280x720 25fpsビデオに最適なロスレスビデオ形式を探しています。ビデオには4分あります。サウンドは320 kbps mp3になりますが、大したことではありません。理想的な条件：

ロスレス（知覚的にロスレスになります）
コンテナ+コーデックはほとんどのプラットフォームで再生できます
コンテナ+コーデックは、最新のDVDプレーヤーで再生できます（DVD以外の形式をサポート）
サイズが700 MB未満です

それも可能ですか？満足のいく結果が得られずに、すでに3日間苦労しており、12 GBのファイルを取得することもあります（1分間に3 GB程度）。

video ffmpeg video-editing

— mrkva
ソース

比較については、en.wikipedia.org

— wiki / List_of_codecs＃Lossless_compression

すみませんが、700 MB未満に圧縮された4分の（視覚的に）ロスレス720pビデオを実際に取得することはできません（ここでは、「ビット」を意味する「mb」ではなく、メガバイトを想定しました）。なぜこのような制約があるのですか？ビデオをh.264エンコードできませんか？

— slhck

はい、MB、混乱して申し訳ありません。cca 5ビデオx 4分を4 GBに収める必要があります（中程度の制限）。

— mrkva

12GiBファイルを取得しているので、24ビットの色深度を使用すると仮定します。非圧縮ビデオデータストリームは、1分あたり約4GiBです。それは膨大な量のデータです。必要なのは、1分あたり約170MiBです。選択するコーデックに関係なく、あまり動きのない静的なシーンでのみこれを達成できます。ロスレス、フレームレートの削減、またはより大きなファイルサイズを許容するには、制約を緩和する必要があると思います。

— マルコ

「コンテナ+コーデックは、最新のDVDプレーヤー（DVD以外の形式をサポート）で再生できます」を明確にできますか？

— -llogan

回答:

私が知っている最高の実際の数学的に損失のない形式はhuffyuvですが、それは陽気に巨大なファイルを生成し、多くと互換性がありません。記録のために、ffmpegは以下でそれを行うことができます。

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

オープンソースのh.264エンコーダーであるX264にはロスレスモードがあります。これはMP4コンテナー内に配置でき、ここ数年で作成されたほとんどのハードウェアと互換性があります。最初のコマンドは、エンコード速度は速くなりますが、ファイルが大きくなります。2番目のコマンドにはかなり長い時間がかかりますが、ファイルは高速エンコードされたファイルの約半分のサイズである必要があります（それでもかなり大きなサイズになります）。

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

それで十分なサイズのファイルが得られない場合、一般に18のcrfは「視覚的に可逆」と見なされます。

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

私は通常、x264でのエンコードに非常に高速なプリセットをお勧めします。私の経験では、最高の速度/サイズのトレードオフを提供します（超高速と超高速の間でファイルサイズが大幅に低下しますが、それよりも遅くなり、さらに増加します）。一般的なアドバイスは、処理可能な最も遅いプリセットを使用することです。プリセットは、超高速、超高速、超高速、高速、高速、中、低速、低速、超低速です。

x264エンコードの詳細なガイドについては、こちらをご覧ください。

— 邪悪なスープ
ソース

veryfast非可逆x264のデフォルトとして推奨しないでください。 medium良い中間点ですが、私は通常veryslow、あらゆるものの最終的なエンコードに使用します。またhuffyuv、非常に高速ではありません。互換性以外にはお勧めしません。

— ピーターコーデス

ffmpegには、試してみる価値のある他のロスレスコーデックもいくつかあります[FFv1が思い浮かびます]。GL！

— rogerdpack

0のCRFを使用しても、libx264は2つのカラーチャネル（YUVではUV）をいずれかの方向に半分にダウンサンプリングしないため、完全にロスレスではありません。また、丸めエラーでは、x264圧縮のラウンド後にデータがビット単位で同一であることが保証されません。

— -Adisak

ffmpeg 3.4.1の私の実験では、libx264はyuv444ピクセル形式を使用しました。「444」は「U、V部分をダウンサンプリングしない」ことを意味します。そして、OPは明示的に丸め誤差を気にしません。「知覚的に損失がない可能性があります」。@Adisak、あなたの懸念は合理的ですが、この答えには当てはまりません。

— ジムデラハント

YUVモードのffmpegとlibx264は、入力に基づいてYUVピクセル形式をネゴシエートします。入力がYUV 4：2：0の場合、出力ピクセルフォーマットも同様です。入力がYUV 4：4：4またはRGBの場合、出力はYUV 4：4：4です。

— ギャン

最近、webmが好きです。

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

マルチコアプロセッサでより高速に変換するには、実際のコアよりも1つ少ないスレッドを使用することをお勧めします。したがって、8コアでは、次のように7つのスレッドを指定できます。

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

— ロニーベスト
ソース

環境変数％NUMBER_OF_PROCESSORS％を使用して、使用するスレッド数を決定します。カウントが1または2の場合、すべてのプロセッサーを使用しました。カウントが3または4の場合、1つのプロセッサを除くすべてを使用します。カウントが高い場合は、スレッドカウントに2つのプロセッサを除くすべてを使用します。

— アディサック

DOS式としては、次のようになります。if "％ADJUSTED_CPUCOUNT％" EQU ""（if％NUMBER_OF_PROCESSORS％EQU 1（set ADJUSTED_CPUCOUNT = 1）else if％NUMBER_OF_PROCESSORS％EQU 2（set ADJUSTED_CPUCOUNT = 2）else if％NUMBER_OF_PROCESSORS％ EQU 3（設定ADJUSTED_CPUCOUNT = 2）それ以外なら％NUMBER_OF_PROCESSORS％EQU 4（集合ADJUSTED_CPUCOUNT = 3）他（セット/ A ADJUSTED_CPUCOUNT =％NUMBER_OF_PROCESSORS％-2））

— Adisak

superuser.com/questions/155305/…ffmpegはすでに最適な数のスレッドを選択していると述べています

— Boris

webm（最近）よりも良い選択肢は、おそらくav1形式です。

— ロニーベスト

-1

＃コンテナ

DVDプレーヤーとの完全な互換性を確保するには、MPEG-2形式、コンテナ、制限、コーデックを使用する必要があります。「モダンプレーヤー」とは「mp4」互換性を意味します。これは基本的にほとんどがmp4ファイルプレーヤーです-H.264、MPEG-4、AVC => libx264続きを
読む：https : //de.wikipedia.org/wiki /H.264

＃ビデオ

見ていhttps://trac.ffmpeg.org/wiki/Encode/H.264それは互換性のために、「プロファイル」と「レベル」についてです、特に一部
使用して-profile:v high -level 4.0それを行う必要がありますが

＃音声

非可逆コーデックを使用してオーディオトラックを再エンコードすることは避けてください。mp3形式はいずれも320kbpsであっても非可逆です。代わりに
使用してください-c:a copy。

これまでのところ、それは私にとってかなり良い仕事をしました。同期の問題はありません。
オーディオストリームはキーフレームにバインドされていません。正確なカットが可能です。
オーディオトラックが44kHzのサンプリングレートで録音されている場合は、maxを使用します。256kbps

特定の前提条件に適合する必要がある場合、ビデオの最終エンコードにのみ不可逆コーデックを使用します。

いくつかのオーディオ同期の問題を聞いたことがありますが、主な問題のようで、保護されたマテリアルでした！

＃最後に

私はこのようなものを好む：
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— ドー
ソース

オプション「-level 4.0」は不要です。x264のレベルは解像度とFPSに基づいて決定されるため、通常は手動で設定する必要はありません。これにより何も改善されません。私が知る限り、ffmpegは自動的に正しいレベルを設定できるので、それを強制し、FPSと解像度に基づいてレベルを選択する方法を完全に理解する十分な理由がない限り、「-level」オプションを使用しないでください。最高の互換性が必要な場合は、「高」ではなく「ベースライン」プロファイルを使用してください。

— リサンロライエン