このの記事を読んでいたところ、CPUがビデオ圧縮に適していることがわかりましたGPUよりも。
この記事では、プロセッサがGPUよりも複雑なアルゴリズムを処理できるために発生すると述べていますが、より技術的な説明が必要です。インターネットで検索を行いましたが、しませんでした。何かを見つけてください。
では、サイトを説明したりリンクしたりすることを知っている人は、これについてもっと詳しく説明しましたか？
回答
リンクした記事はあまり良くありません。
通常、シングルパスビットレートエンコーディングは、ビットレートをRF値に変換します。最大ビットレート制限とそこから取得します。
x264のワンパスABRレート制御はCRF +制限として実装されていません。彼はその2パスの権利です。ただし、目標のビットレートを達成するための最善の方法です。
そして、彼は、threads = 3などでx264を起動できることに気付いていないようです。他のタスクのためにCPU時間を空けておきます。または、x264の優先度を非常に低く設定して、他のタスクが必要としないCPU時間のみを取得します。
彼はまた、スレッド= 1とCUDAなどの使用を混同しています。質問があるのも不思議ではありません。記事にはひどい説明があります。記事全体は基本的に次のように要約されます：x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkvを使用するか、入力AviSynthスクリプトで光フィルタリングを使用します。彼は実際に placebo "。それは陽気です。プラセボでエンコードされた海賊版ファイルを見たことがありません（iv id = “の代わりにme=esaまたはme=tesaからわかります。 aecffbf258 “>
は、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で合理的に実行できます（実行可能であり、並列化できませんでした）。
x264CUDAはフルペルを実装します最初はMEアルゴリズムをサブペルします。後で、ビットコストの承認でRDOのようなことを行うことができます。 CABACの代わりにximation。
単精度浮動小数点ですべてを実行する必要があるため
-MfA間違っています。CUDAは整数演算をサポートしています。
-ダークシカリ
ダークシカリはx264のメンテナであり、2007年頃からほとんどの機能の開発者です。
AFAIK、このCUDAプロジェクトは成功しませんでした。 OpenCLを使用して、先読みスレッドから一部の作業をオフロードするためのサポートがあります（フレームの高品質の最終エンコードではなく、迅速なI / P / B決定）。
私の理解は、ビデオエンコーディングの検索スペースが非常に大きいため、CPU上の検索パスを早期に終了するためのスマートヒューリスティックがブルートフォースGPUを打ち負かすことです。少なくとも高品質のエンコーディングのために、テーブルに持ってきてください。これは、特に低速のCPU（デュアルコアでハイパースレッディングのないラップトップなど）を使用している場合に、x264よりもHWエンコーディングを合理的に選択できる-preset ultrafastとのみ比較されます。 CPU（ハイパースレッディングを備えたi7クアッドコア）、x264 superfastはおそらく同じくらい高速で、（同じビットレートで）見栄えが良くなります。
「レート歪み（ファイルサイズごとの品質）が重要なエンコードを作成する場合は、x264 -preset medium以下を使用する必要があります。何かを再アーカイブし、もう少しCPU時間を費やすと、「そのファイルを保持している限り、バイトを節約できます。
補足として、ビデオフォーラムでデッドラットからのメッセージを目にしたことがある場合は、それ」です。役に立たないでしょう。彼は、私が今まで見たすべてのスレッドで話しているほとんどのことについて間違っていました。彼の投稿は、私がx264 GPUエンコーディングについてグーグルで検索したいくつかのスレッドで見つかりました。どうやら彼はそれが簡単でない理由を理解していないようです、そして、x264開発者に「ばかげている…
回答
2017年の更新：
ffmpegは、h264およびh265 NVENCGPUで高速化されたビデオエンコーディングをサポートします。 hevc_nvencまたはh264_nvencのいずれかに対して、選択した品質で1パスまたは2パスのエンコードを実行できます。また、エントリーレベルのGPUを使用しても、非高速エンコードやIntel QuickSync高速エンコードよりもはるかに高速です。
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 codec、h264_qsv、hevc_qsv、またはmpeg2_qsvを使用できます。これらは、高速化されていないエンコーディングよりもはるかに高速です。
コメント
回答
Peterの言うことをもう少し詳しく説明すると、一般に、複数のプロセッサを使用すると、複数の独立したタスクがある場合に役立ちます。実行する必要がありますが、相互に依存関係がないか、大量のデータに対して同じ計算を実行する1つのタスクがありません。
ただし、計算Aの出力が必要な場合計算Bの入力として、計算Bの出力を計算Cへの入力として使用する場合、タスク（A、B、またはC）ごとに異なるコア作業を行うことで速度を上げることはできません。他が終了するまで開始します。
ただし、上記の場合でも、次のことができる場合があります。 o別の方法で並列化します。入力データをチャンクに分割できる場合は、1つのコアでA、B、Cの順にデータのチャンクを実行し、別のコアでA、B、Cの順にデータのチャンクを実行することができます。 。
他にも考慮事項があります。計算を並列化する方法を見つけることができるかもしれませんが、ディスクから、またはネットワークを介してデータを読み取るか、GPUに送信するだけでは、計算を行うよりも時間がかかります。その場合、データをメモリに取り込むだけでは、並列計算を行うことで節約できる時間よりも時間がかかるため、並列化しても意味がありません。
つまり、科学であると同時に芸術でもあります。
コメント
- そうです、x264はマルチコアCPUで非常によく並列化されます。私は少なくとも8コアまでほぼ直線的にスケーリングし、32コアを超えても適切にスケーリングします。モーション推定は並列で実行でき、別のスレッドの必然的にシリアルな作業と同様のトリックのみを残します。
- 問題はありません'一般に並列処理、特に'のGPU。 'は、CPUよりも実行できるコードがはるかに制限されています。 'は、画像のさまざまなブロックでさまざまな方向に進むブランチを持つコードを'持つことができないためだと思います。 '理由は正確にはわかりませんが、'はそのようなものだと思います。各ストリームプロセッサは非常にシンプルで、他のプロセッサから独立して実行する手段が限られているため、最も遅いプロセッサが終了するのを常に待つ必要があるか、分岐がまったく制限されているか、またはその両方です。
- コンピューターのクラスター（'メモリ帯域幅とCPUキャッシュについて互いに競合しなかった独立したRAMを備えたCPU）がある場合は、' d入力ビデオをGOPに分割し、まだ圧縮されている入力ビデオのセクションを送信して、クラスター内の他のマシンでデコードおよび圧縮します。したがって、圧縮された入力または出力ビデオのみを転送する必要があります。 マルチソケットx86ワークステーションのようなマルチコア共有キャッシュ/ RAMシステムの1つでは、複数のスレッドが同じフレームで同時に動作します。 （また、エンコードをセグメント化するためのグローバルレート制御を行うために'新しいコードは必要ありません。）
-c:v libx264 -preset slowerを打ち負かすつもりはありません（Skylake i7-6700kの1920x1080p24のほぼリアルタイムのように、それほど遅くはありません）。ffmpegと-vcodec h264_qsvを使用すると、レンダリングがはるかに高速になりました！