CPUおよびGPUでのビデオ処理。 エキスパートアンサー

この投稿では、CPUとGPUでのビデオの処理について以前に尋ねた質問に対する Intelの専門家Dmitry Serkinの回答を公開しています。 遅れたことをおaびします-それは私たちとDmitryの間の大きな時間差に関連しています。

いつものように、検索の便宜上、著者のHabrの名前が質問に提供されます。



質問Maratyszcza

Intelプロセッサには、他の（ビデオ以外の）圧縮アルゴリズム用のハードウェアブロックがありますか？

そうは思いません 特定のプロセッサ向けに最適化があります。 Intel Integrated Performance Primitivesには、アルゴリズムおよび命令のレベルでのZLIB、DEFLATE、およびGZIP機能ファミリーの最適化が含まれています。



質問ライフスター

CPUのハードウェア圧縮はどのコーデックをサポートしていますか？

コーディングについてのみ話している場合は、H.264、MPEG-2、MJPEG、およびMVCを使用して立体3Dをサポートします。 アプローチについては、いくつかのより広く知られています。



JDimaの質問

QuickSyncは、結果の画像の品質においてx264と比較することが期待できますか？

品質のプリセット（エンコード設定）について話している場合、追いつくことはありません。 新しいプラットフォームごとに、コーディングの品質が向上します。これは、鉄の側により多くのリソースがあり、その結果、動き推定やビットストリームのパッキングなどのアルゴリズムを改善する能力があるためです。 x264は、RDOを含む非常に優れたアルゴリズム（高速ではありませんが、品質に影響します）を使用します。 これはすべて、鉄のコンベヤーアーキテクチャに非常に悪影響を及ぼす。 ミドルプリセットについて話すと、かなりヒットします。 もちろん、すべてはコーデックの最終設定に依存しますが、その多くがあります。 品質と速度が両立しないことを理解する必要があります。 QuickSyncの目標は、99％のユーザーに高品質で迅速にエンコードすることです。 そして、テクノロジーがそれを行います。 それまでの間、dBを増加させる作業は毎日行われています。



質問ウェザーマン

HD 4000と新しいHD 5000のパフォーマンスは大きく異なりますか？ 最新のゲームでいくつか例を挙げてもらえますか？

最近のプレスリリースによると、速度は最大3倍に増加し、エネルギー消費は2倍減少しました。 公的なゲームのベンチマークを見たことはありません。 ハスウェルの打ち上げの数週間前に表示されるはずです。 私の記憶では、6月に開催されます。 残念ながら、このトピックには含まれていないため、コーデックを扱っているため、例を挙げることはできません。



Tp7の質問

1.マルチビットビデオのハードウェアデコードをサポートする計画はありますか。たとえば、H264からのHi10Pまたは「古い」HEVCプロファイルですか。

私はそのような情報を持っていません。 計画は変更可能なものです。 これらのプロファイルが大量に使用される場合、非常に高い確率でサポートされます。

2.しばらく前に、新しいIntelプロセッサから何を望んでいるかをテーマに、無料のコーデックの開発者と対話する試みがあったことを覚えています。 この方向の今の状況は何ですか？ オープンソース開発者はインテルに影響を及ぼしますか？インテルはそれらのサポートを提供しますか？

アプリケーションのレベルでより可能性が高いが、開発者ではない。 HandBrakeがQuickSyncをサポートするという最近の発表は、そのようなイベントの1つです。 これは、無料製品に対するインテルの貢献です。 Linuxおよびその派生製品（Android）でのQuickSyncの開発は本格的であるため、このような活動はますます頻繁に行われます。

ドライバーとハードウェアに直接アクセスすることに関しては、そのような活動は聞いたことがありません。 さらに、この作業はかなり重要なので、私はそれらを無意味だと考えます。 さらに、 Media SDKがあり 、より高いレベルのプリミティブを提供します。

3.現時点では、原則として、GPUでのコーディングの適切な実装はありません（ごく少数であり、すべて品質や速度の特別な利点に違いはありません）。 なぜこれが起こっており、この分野で前向きな進展がありますか？

QuickSyncは非常に成功したソリューションであり、速度と（この速度に比べて）品質の両方が優れていると思います。 AMDまたはNvidiaのソリューションに関しては、それらの障害はIntelとは異なるアーキテクチャで説明できます。 それらの決定はすべて、実行単位とマルチスレッドに基づいています。これは、コーデックで使用するのが困難です（一部のコーナーストーンアルゴリズムは、マルチスレッドに該当しません）。 QuickSyncは、EUと固定機能の組み合わせです（アルゴリズムブロックはハードウェアに「はんだ付け」されています）。 この組み合わせにより、生産性と品質が大幅に向上します。

4.最近リリースされたHEVCとVP9のパフォーマンスが理由を超えていることは秘密ではありません。 プロセッサ/ソフトウェアがこれらの形式のHDビデオをリアルタイムで処理（少なくともデコード）できるようになるまでの期間はどのくらいですか？

数年後にはそのような機会が現れると思います。

5. Intelマルチメディア製品で手書きASMはどれくらい広く使用されていますか、それともコンパイラの最適化により依存していますか？ C ++を使用していますか、それとも古き良きCを使用していますか？ 新しい機能を直接実装する場合と比較して、パフォーマンスを最適化するにはどれくらいの時間がかかりますか？

戦争では、すべての手段が優れています:)私たちは、ドライバーレベルおよびそれ以下で上記のすべてを使用します。 もちろん、特定のASMは、その後の手動最適化のためにCのようなコードから生成されます。 すべてのために多くの時間がかかります。 品質と生産性の両方の分野で多くの研究がありますが、すべてに期限があります。 私は正確な割合を言うつもりはありませんが、研究はもちろんより多くの時間を消費します。

6. Intelのマルチメディアチームの規模は？ あなたに到達するのはどれくらい難しいですか？ :)

ハードウェア、ドライバーからさまざまなSDKまで、何千人もの人々がいます。 タグ付けする位置を確認してください。）ロシア（モスクワとニジニノヴゴロド）には、Intel Media SDKを扱う大規模なチームがあります。 定期的に空室が表示されます。



質問RussianNeuroMancer

問題はハードウェアまたはドライバーにありますか？

ここで最も可能性が高いのはドライバーです。 Windowsでは、これはOSレベルの制限がある既知の問題です。 しかし、それは解決可能です。 よりアクセスしやすく、詳細をここに書きました 。



質問Ilya_Smelykh

ほとんどの一般的な形式のハードウェア色空間変換はありますか？ ハードウェアのインターレース解除はどうですか？

これはすべてです 。 平面およびパッケージ形式。 次はさらに続きます。 インターレース解除もサポートされています。



Aingis Question

ご存知のように、昨秋、Appleは網膜を搭載した13インチMacBook Proをリリースしました。 個別のグラフィックカードは搭載されておらず、すべてのグラフィックはIntel HD4000で動作します。 このプラットフォームでは完全にサポートするには不十分であるというレビューがあります。 Intelはグラフィックスに関して少なくともiPadをRetinaに譲らないことを計画していますか？

グラフィックは非常に迅速かつ強力に開発されていると思います。 Intel Irisはiごとにドットを付ける必要があります。



質問ディガー

自宅のGPUでのビデオエンコーディングの例を教えてください。

最も一般的な例は、モバイルデバイスのコーディングです。 一連のシリーズを30分待つのではなく、数分でモバイルデバイスでサポートされる形式にトランスコードする場合は、QuickSyncが役立ちます。



質問ラッセル

Intel 3650用の64ビットドライバーはありますか？

申し訳ありませんが、そのような情報はありません。 しかし、トピックはフォーラムによって判断されるホットです。



質問sancho2222

1. IntelプロセッサにはKUDAに似たものがありますか？

Nvidia CUDAを意味しますか？ 答えはIntel OpenCLです。

2. Intelプロセッサのグラフィック機能、特にh.264エンコード/デコードを使用するには、どのライブラリが必要ですか？

必要なのは、Intel Media SDKだけです。

3. Intel i7-3517UEプロセッサには、H.264で960 * 720のビデオ解像度を同時にデコードおよびエンコードするのに十分なパフォーマンスがありますか？

はい、もちろんです。 また、複数のスレッドでも。

4. Intel Atom（tm）N2800プロセッサーに問題があります。 たぶんあなたは私を助けることができます。 Logitech C920カメラ、ビデオ解像度960 * 720のffmpeg H.264でデコードしています。 デコード後、YUYJ420フレーム形式を取得します。 この解像度では、上記の解像度で1秒あたり24フレームで2つのストリームをデコードできますが、デコード後にビデオを270度反転させると、キャッシュの制限（理解しているとおり）に反して、最終的には1秒あたり20フレームしか使用できなくなります。 1つのストリームで、フレーム数を増やすと、ビデオは小さな正方形にバラバラになり、非常に遅くなります。 何が問題なのか教えてください。 このキャッシュは正確ですか？

ほとんどの場合、システム全体のパフォーマンスが低下します。 すべての操作は中央処理装置で行われ、2つのスレッドと後処理によって対処できなくなります。 遅延を実行するために、ffmpegはフレームのスキップを開始するため、アーティファクトが表示されます。 どのようなCPU使用率がありますか？

出力がどのような形式であるのか、私にはよくわかりませんでした。 YUV420？ フォーマットに応じて、ローテーションには異なる操作セットが必要です。 まあ、あまりキャッシュはありませんが、ご存知のように、速度に影響します。



ユラセク質問

h.264のハードウェアデコード機能を備えたIntel第2世代および第3世代プロセッサに組み込まれたロジックの可能性に興味がありますか？ つまり、たとえば1280 x 720（1920 x 1080）/ 25フレーム/秒の解像度のリアルタイムh.264ストリームは、ハードウェアデコードを使用してIntel i7-3770プロセッサで処理できます（プログラムコードが理想的な場合）最大限に最適化された）画面上の後続の表示のために？ 他のプロセッサユニットのリソースはどの程度関与しますか？

いい質問です。 スレッドの数は、グラフィックメモリにのみ物理的に残ります。 サーフェスを選択するのに十分なメモリがある限り、すべてが機能するはずです。 別の問題はパフォーマンスです。 デコードしようとしているコンテンツに依存します。 つまり、ストリームがどのようにエンコードされたかに応じて、異なる時間とリソースがかかります。 これらすべての要因（および他の多くの要因）を考慮すると、私の頭からの大まかな見積もりは、同時に最大20のリアルタイムセッションです。