プロセッサがGPUよりもエンコードに「優れている」のはなぜですか？

私はこの記事を読んでいて、CPUはGPUよりもビデオ圧縮に優れていることがわかりました。

この記事は、プロセッサがGPUよりも複雑なアルゴリズムを処理できるために起こると述べていますが、より技術的な説明が必要です。インターネットで検索を行いましたが、何も見つかりませんでした。

だから、サイトを説明したりリンクしたりすることを誰もが知っていますか？

リンクした記事はあまり良くありません。

通常、シングルパスビットレートエンコーディングは、ビットレートを最大ビットレート制限のあるRF値に変換し、そこから取得します。

x264のワンパスABRレート制御は、CRF +制限として実装されていません。ただし、ターゲットのビットレートを達成するには、2passが最善の方法であるというのが正しいです。

そして、彼は、スレッド= 3などでx264を起動して、他のタスクのためにCPU時間を空けることができることに気付いていないようです。または、x264の優先度を非常に低く設定し、他のタスクが必要としないCPU時間のみを取得します。

また、CUDAなどを使用してthread = 1を混同します。その記事にはひどい説明があるので、質問があるのも不思議ではありません。記事全体は基本的に次のように要約されます：use x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkvまたは、おそらく入力AviSynthスクリプトで光フィルタリングを使用します。彼は実際に「プラセボ」を推奨しています。それは陽気です。プラセボでエンコードされた海賊版ファイルを見たことはありません。（me=esaまたはからme=tesa、またはまでme=umhのすべての良質のプリセットの代わりに伝えることができますveryslow。

彼はまた、10ビットの色深度の使用について言及していません。エンコードとデコードは遅くなりますが、8ビットにダウンコンバートした後でも、8ビットのSSIMが得られます。動きベクトルの精度を高めることは明らかに役立ちます。また、正確に8ビット値全体に丸める必要はありません。コンポーネントごとに8ビットをスピードハックと考えることができます。周波数領域で量子化し、それをCABACで圧縮することは、より高いビット深度係数がより多くのスペースを必要としないことを意味します。

（BTW、h.265は、モーションベクトルの精度が既に高いため、8ビットビデオの10ビットエンコードからのメリットは少なくなります。8ビットビデオ入力に10ビットx265を使用するメリットがある場合は、 x264を使用します。したがって、速度の低下に見合うだけの価値はありません。）

実際の質問に答えるには：

編集：doom9が再びアップしたので、リンクを整理します。誰が何を言ったかを適切に引用するためにそこに行きます。

http://forum.doom9.org/showthread.php?p=1135399#post1135399

googleは、引用を適切に表示しない愚かな印刷バージョンのみをキャッシュします。これらのメッセージのどの部分が引用であり、どの部分がその人自身に起因しているのかはよくわかりません。

非常に不規則な分岐パターン（スキップモード）およびビット操作（量子化/エントロピーコーディング）は、現在のGPUには適していません。IMOが現時点で唯一の本当に良いアプリケーションは、完全検索MEアルゴリズムです。ただし、CPU上より高速であっても、完全検索の高速化は依然として遅くなります。
-MfA

実際、基本的にすべてはCABACを除いてGPUで合理的に実行できます（実行できましたが、並列化できませんでした）。

x264 CUDAは、最初にfullpelおよびsubpel MEアルゴリズムを実装します。後で、CABACの代わりにビットコスト近似を使用してRDOのようなことを行うことができます。

なぜなら、すべてを単精度浮動小数点で行う必要があるからです
-MfA

間違っています。CUDAは整数演算をサポートしています。

-ダークシカリ

Dark Shikariは、x264のメンテナーであり、2007年以降のほとんどの機能の開発者です。

私の知る限り、このCUDAプロジェクトは成功しませんでした。先読みスレッドから一部の作業をオフロードするためのOpenCLの使用がサポートされています（フレームの高品質の最終エンコードではなく、迅速なI / P / B決定）。

私の理解では、ビデオエンコーディングの検索スペースは非常に大きいため、少なくとも高品質のエンコーディングの場合、CPUでの検索パスの早期終了のためのスマートヒューリスティックがブルートフォースGPUを打ち破ります。これは-preset ultrafast、特にx264よりもHWエンコードを合理的に選択できる場所と比較されているだけです。CPUが遅い場合（デュアルコアでハイパースレッディングのないラップトップなど）。高速CPU（ハイパースレッディングを備えたi7クアッドコア）では、x264 superfastはおそらく同じ速度で、同じビットレートでより良く見えるでしょう。

レートディストーション（ファイルサイズあたりの品質）が重要な場合にエンコードを行う場合は、x264 -preset medium以下を使用する必要があります。何かをアーカイブする場合、そのファイルを保持している限り、もう少しCPU時間を費やすことでバイトを節約できます。

サイドノート、ビデオフォーラムでデッドラットからのメッセージを見たことがあれば、役に立ちません。彼は私が今まで見たすべてのスレッドで話しているほとんどのことについて間違っていました。彼の投稿は、x264 GPUエンコーディングについてGoogleで検索したいくつかのスレッドで見つかりました。どうしてそれが簡単ではないのか彼は理解していないようで、x264開発者になぜ彼らが愚かであるかを伝えるために何度も投稿しています...

2017年の更新：

ffmpegは、h264およびh265 NVENC GPU加速ビデオエンコーディングをサポートしています。hevc_nvencまたはh264_nvencのいずれかに対して、選択した品質で1パスまたは2パスエンコードを行うことができます。また、エントリーレベルのGPUでも、非高速エンコードおよびIntel Quick Sync加速エンコードよりもはるかに高速です。

2パスの高品質エンコーディング：

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4

1パスのデフォルトエンコーディング：

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4

NVENC ffmpegのヘルプとオプション：

ffmpeg -h encoder=nvenc

これを使用すると、CPUエンコードよりもはるかに高速です。

GPUがない場合は、Intel Quick Syncコーデック、h264_qsv、hevc_qsv、またはmpeg2_qsvを使用できます。これらは、非高速エンコードよりもはるかに高速です。

ピーターが言うことをもう少し詳しく説明すると、一般に複数のプロセッサを使用すると、すべてを実行する必要があるが互いに依存関係がない複数の独立したタスクがある場合、または同じことを実行している1つのタスクに役立ちます大量のデータに関する数学。

ただし、計算Aの出力を計算Bの入力として、計算Bの出力を計算Cの入力として必要とする場合、各タスクで異なるコア作業を行うことで速度を上げることはできません（ A、B、またはC）。一方が終了するまで開始できないためです。

ただし、上記の場合でも、別の方法で並列化できる場合があります。入力データをチャンクに分割できる場合、1つのコアでA、B、Cの1つのデータチャンクを実行し、別のコアでA、B、Cの異なるデータチャンクを実行できます。

他の考慮事項もあります。計算を並列化する方法を見つけることができるかもしれませんが、ディスクから、またはネットワーク経由でデータを読み取るか、GPUに送信するだけで、計算を実行するよりも時間がかかります。その場合、データをメモリに格納するだけで、並列計算を行うことで節約できる時間よりも長くなるため、並列化する意味がありません。

言い換えれば、それは科学であると同時に芸術でもあります。