h264ロスレスコーディング
H264で完全にロスレスエンコーディングを行うことは可能ですか？ロスレスでは、一連のフレームをフィードしてエンコードし、エンコードされたビデオからすべてのフレームを抽出すると、入力とまったく同じフレーム、ピクセルごと、フレームごとに取得することを意味します。それは実際に可能ですか？次の例をご覧ください。
一連のフレームを生成してから、イメージシーケンスを非圧縮AVI（virtualdubなど）にエンコードし、ロスレスh264を適用します（ヘルプファイルでは--qp 0を設定するとロスレス圧縮が行われますが、つまり、プロセスのどの時点でも損失がないこと、または量子化だけが無損失であることを意味します）。その後、mplayerのようなもので、結果のh264ビデオからフレームを抽出できます。
最初にHandbrakeで試しましたが、ロスレスエンコーディングをサポートしていないことがわかりました。 x264を試しましたが、クラッシュします。ソースAVIファイルがYV12ではなくRGBカラースペースにあるためかもしれません。いずれにせよ、一連のYV12ビットマップをどのようにx264にフォーマットするのかわからないので、試すことすらできません。
要約すると、それがそこから行く方法があるかどうかを知りたい
一連のロスレスビットマップ（任意の色空間）->何らかの変換-> h264エンコード-> h264デコード->何らかの変換->元の一連のロスレスビットマップ
これを達成する方法があれば？
編集：ロスレスH264があまり意味をなさないことについて非常に有効なポイントがあります。非圧縮のクリップと、H264で高速に圧縮された別のクリップとの違いを（目だけで）知る方法はないことをよく知っていますが、使い道がないわけではないと思います。たとえば、ファイルを保存するたびに、大量のスペースを使用せずに品質を損なうことなく、エンコードに多くの時間を費やすことなく、編集用にビデオを保存する場合に役立ちます。
更新2：現在、x264はクラッシュしません。ソースとしてavisynthまたはロスレスyv12 lagarithを使用できます（色空間圧縮の警告を回避するため）。しかし、-qp 0およびrgbまたはyv12ソースを使用しても、多少の違いはありますが、最小限ですが存在します。これは厄介です。ロスレス予測コーディング（--qp 0）で見つけたすべての情報は、エンコード全体がロスレスであるべきだと主張していますが、これを検証することはできません。
1日を費やしてYUV 4：4：4ピクセルをx264に変換する方法を見つけ出した後、これに遅い回答を追加します。 x264はファイル内の生の4：2：0ピクセルを受け入れますが、4：4：4ピクセルを渡すのは非常に困難です。ffmpegの最近のバージョンでは、次の方法で完全にロスレスエンコーディングと抽出を行い、エンコーディングを検証します。
最初に、未加工のyuv 4：4：4ピクセルをファイルに平面形式で書き込みます。プレーンはYバイトのセットで、UとVはゼロ値として128を使用するUバイトとVバイトのセットです。ここで、ffmpegを呼び出し、「yuv444p」ピクセルフォーマットを2回使用するように、未加工のYUVフレームのサイズを渡します。
ffmpeg -y -s 480x480 -pix_fmt yuv444p -i Tree480.yuv \
-c:v libx264 -pix_fmt yuv444p -profile:v high444 -crf 0 \
-preset:v slow \
Tree480_lossless.m4v
H264へのエンコードとQuicktimeファイルとしてのラップが完了すると、次のようにまったく同じバイトを抽出できます。
ffmpeg -y -i Tree480_lossless.m4v -vcodec rawvideo -pix_fmt yuv444p \
Tree480_m4v_decoded.yuv
最後に、diffで2つのバイナリファイルを確認します。
$ diff -s Tree480.yuv Tree480_m4v_decoded.yuv
Files Tree480.yuv and Tree480_m4v_decoded.yuv are identical
YUVバイトを自分でファイルに書き込む必要があることに注意してください。ffmpegにYUV値の変換を行わせないでください！
X264がロスレスエンコーディングを行うが、入力形式が気に入らない場合、最善の策はffmpegを使用して入力ファイルを処理することです。のようなものから始めてみてください
ffmpeg -i input.avi -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout \
| x264 $OPTIONS -o output.264 /dev/stdin
そこからオプションを追加します。 YUV4MPEGは、さまざまなビデオツール間のパイピングに適した、ロスレスの非圧縮形式です。 ffmpegはそれを書く方法を知っており、x264はそれを読む方法を知っています。
HandBrake GUIでロスレスH.264を生成するには、ビデオコーデック：H.264、一定品質、RF：0、H.264プロファイル：自動を設定します。このファイルはAppleによってネイティブにサポートされていませんが、再生用にほぼロスレスとして再エンコードできます。
HandBrake GUIのアクティビティウィンドウ：
H.264プロファイル：自動; エンコード時の定数RF 0.0000 ...プロファイルHigh 4：4：4予測、レベル3.0、4：2：0 8-ビット
H.264プロファイル：高; エンコーディング=定数RF 0.0000 ...ロスレスにはhigh444プロファイルが必要、無効化 ...profile Highレベル3.0
圧縮と圧縮解除の要件はわかりませんが、汎用アーカイバー（LZMA2を使用した7-Zipなど）は、ロスレスビデオコーデックと同程度か、場合によってはさらに小さく圧縮できます。また、ビデオ処理チェーン全体よりもはるかにシンプルで安全です。欠点は、はるかに遅い速度であり、それを見る前に抽出しなければならないことです。しかし、画像については、試してみるべきだと思います。
.pngなどの可逆画像形式もあります。
X264でロスレスRGBをエンコードするには、コマンドラインバージョンのx264を使用する必要があります（このEdgeの場合、GUIは信頼できないため、おそらく混乱するでしょう）r2020以降、次のようなものです：
x264 --qp 0 --preset fast --input-csp rgb --output-csp rgb --colormatrix GBR --output "the_lossless_output.mkv" "someinput.avs"
入力と出力の間の損失/差は、何らかの色空間変換（エンコード前または再生時）、間違った設定、または失われたヘッダー/メタデータによるものです。 x264はRGBAをサポートしていませんが、RGBは大丈夫です。 YUV 4：4：4圧縮はより効率的ですが、入力がRGBであるため、色空間変換で一部のデータが失われます。 YV12/i420ははるかに小さく、ビデオで最も一般的な色空間ですが、彩度の解像度は低くなります。
X264設定の詳細： http://mewiki.project357.com/wiki/X264_Settings
また、ラガリスを避けてください。 x87浮動小数点を使用します...より良い代替手段があります。 http://codecs.multimedia.cx/?p=3 http://mod16.org/hurfdurf/?p=142
編集：私はなぜ私が断られたのか分からない。その際、コメントを残してください。
H.264エンコーダーとデコーダーを使用してロスレス圧縮を取得できない場合は、おそらく2つの選択肢を検討できます。
（1）すべてのデータをh.264形式で渡すのではなく、一部のデータを 残余の「サイドチャネル」 で送信しようとしています。
- （h.264ファイル）-> h264デコード->変換->元の一連のビットマップの損失のある近似
- （圧縮された残差ファイル）->デコーダー->一連のロスレス残差ビットマップ
- 各ビットマップの各ピクセルについて、近似ピクセル+残余ピクセル=元のピクセルに等しいビット単位のピクセル。
（2）「ロスレス」モードでDiracビデオ圧縮形式を使用します。
データの損失は許容できる場合もありますが、それは単に圧縮直後のデータの見た目の問題ではありません。
視覚的に知覚できない色データの損失でさえ、映像を劣化させる可能性があり、色補正、グリーンスクリーンキーイング、追跡、およびその他のポストタスクがより困難または不可能になり、制作に費用がかかります。
パイプラインでいつ、どのように圧縮するかによりますが、通常、ストレージは再撮影よりもはるかに安価なので、元の品質をアーカイブするのが理にかなっています。