1
ロスレスモードでh264を使用すると、予期しない小さな結果が生じます
私はffmpegの画面キャプチャ機能に興味を持ち、h264の簡単なリアルタイムキャプチャテストをいじり始めました。 ffmpeg -f dshow -i video="screen-capture-recorder" -video_size 1920x1080 -framerate 30 -c:v libx264 -crf 0 -preset ultrafast capture.mkv -qp 0または-crf 0オプションlibx264を使用したffmpeg h264のドキュメントに記載されている内容は、ロスレスモードで動作するはずです。 -qp 0または-crf 0を使用して、ロスレス出力をエンコードできます。ロスレスでは-crfよりも-qpを使用することをお勧めします。これは、8ビットと10ビットのx264がロスレスで異なる-crf値を使用するためです。 これは、リアルタイムキャプチャセクションのヘルプでも繰り返され、オプションの再エンコードを低速のプリセットで行ってサイズを節約しようとしています。 最初の録音はロスレスであり、再エンコードもロスレスなので、このプロセスで品質が失われることはありません。 これに基づいて、ガイドを信頼し、-qp 0を使用すると想定して、完全にロスレスのワークフローを実現します;） ただし、特定の状況で損失が発生することがわかりました。 だから私はこのコードでhuffyuvコーデックで別のテストを行いました： ffmpeg -f dshow -i video="screen-capture-recorder" -video_size 1920x1080 -framerate 30 -c:v huffyuv capture.mkv 結果： 画面1：ロスレスモードのh264 画面2：huffyuv 画面ベースhuffyuvは完璧ですが、真のロスレスコーデックですが、h264代わりにここで何かを圧縮します。なぜロスレスモードでセットアップする必要があるのか理解できません。 （huffyuvはデスクトップのビットマップスクリーンショットと同じです。h264でも同じです） 誰かがそれを理解するのを手伝ってくれる？ 編集：コメントで必要に応じていくつかのffmpegダンプを追加します;） h264実行： …