1) ここで重要な、より具体的なフラグがあります。ではChrome://gpu、次のように表示されます。VPx Video Decode:
ハードウェアかソフトウェアか？
2) 関連して、試してみること: Chrome で YouTube にアクセスし、任意のビデオを再生します。再生中にビデオを右クリックしStats for Nerds、コンテキスト メニューから選択します。
YouTube が VP8、VP9、または H.264 を提供しているかどうかがわかります。これは、特に H.264 を取得している場合に役立ちます。(Chrome が MS Edge のようなものである場合、ノート PC がバッテリ電源の場合は VPx サポートのアドバタイズを停止し、YouTube に H.264 を提供するように強制するため、ノート PC ではより役立ちます。VPx は H よりも多くのバッテリを消費するためです)。 .264 は、ハードウェアでデコードされた場合でも.264 です.H.264 はコーデックの負担がはるかに少なく、そのハードウェア デコードは VPx ハードウェア デコードよりも効率的です.Kaby Lake は最終的にギャップを埋める可能性があります.)
3) 他にもいくつか問題があります。Chrome ソフトウェア レンダリング リストには、Braswell チップを含むかなり新しい Intel GPU でさえ Chrome が無視している可能性があることを示唆する興味深いエントリがいくつかあります。ここでチェックしてください。「インテル Broadwell、Skylake、および CherryView では VPx デコードが遅すぎる」というエントリがあることに注意してください。
パンくずリストをたどると、特定の PCIID マスクを持つすべての gpu を意味することがわかります (たとえば、N3150 は 0x22b1 である必要があります)。ただし、これは Windows のみであり、さらに、既に修正された古いバグの名残である可能性もあります。
他の可能性のあるエントリにも注意してください。その中には、特定の Intel ドライバー バージョンや特定の Linux カーネル バージョンについて言及しているものもあります。
4)Chrome://flagsソフトウェア レンダリング リストがオーバーライドされていることをページが実際に示していることを確認します (これは最初のフラグです)。古い「ブラックリスト」用語でコマンドライン構文について言及しましたが、このフラグには近年いくつかのバグがあり、基本的に一部の人々やその他の問題に対して機能しません。このフラグをどのように設定しても、実際にはフラグページに正しい設定で表示されることを再確認します。そうでない場合は、明らかにそのページで適切に設定してください。問題に関連する場合と関連しない場合があるバグがあることに注意してください。ソフトウェア レンダリング リストをオーバーライドすると、VPx ビデオ デコード フラグが反転します。chrome://gpuIntel HD 4000 を搭載した現在使用している Ivy Bridge ラップトップのように、VPx ハードウェア アクセラレーションを備えていない PC でも、ハードウェア アクセラレーテッドへ。これが単なる表示上のバグであるかどうかはわかりません。Chrome は実際にハードウェアアクセラレーション、またはChromeが実際にそうしている場合（クラッシュする必要があるように見えますが、そうではありません）。
Chrome フラグは、混乱と衝突する単語の選択の混乱です。フラグにはOverride software rendering listと書かれています。このフラグは無効にするのではなく、有効にする必要があります。ただし、有効になっている場合は、有効という単語やステータス インジケーターは表示されません。設定を変更するための招待状として、Disableという単語が表示されます。あなたが知っているように...多分これはあなたにとってすべて古い帽子です。
5) システム上の VP8 で何が起こっているかを確認するための最後の溝ですが、非常に強力なリソースはIntel Media SDKです。デフォルトで無料でない場合は、Intel の IDE/C++ コンパイラの学生版、および有料の IDE エディションの無料試用版の一部として無料です。何が起きているかを確認するために、そこでできることはたくさんあります。私は、開発者ガイドの 24 ページにある次の文章に感銘を受けました。
ハードウェア アクセラレーションは、簡単なコンパイル手順で FFmpeg に追加できます。FFmpeg コマンド ラインまたは libav* API を使用するように作成されたアプリケーションの場合、コーデック名を変更することでハードウェア対応にすることができます (たとえば、libx264 から h264_qsv に変更)。
ffmpeg の VP8 コーデックのその方法を試して、Chrome 以外のシステムでハードウェア アクセラレーションをトリガーできるかどうかを確認します。
6) また、ビデオ コーデックに関しては、「ハードウェア アクセラレーション」という用語が業界全体で一貫して使用されていないことに注意してください。Chrome が正確に何を意味するのか (フラグで) はわかりません。デコードはGPU によって高速化することも、たまたま GPU 上にある固定機能ユニットによってハードウェアで完全に実行することもできます (ただし、GPU シェーダーは使用しません)。これらはどちらもハードウェア アクセラレーションと呼ばれますが、同じものではありません。そのシナリオを一般的な GPU アクセラレーション (部分アクセラレーションまたはハイブリッド アクセラレーションと呼ばれることもあります) と区別するために、「完全にハードウェア」または「固定機能」が使用されることがあります。
公式 ドキュメントは非常に紛らわしいですが、Braswell (その前身であるBroadwellと同様) には VP8 の完全な固定機能デコードが必要です。エンコーディングと VP9 (同じ QSV モジュールを持つ可能性があるSkylakeと同様) は、ハイブリッド ソリューションを介して提供されます。彼らはある種のGPUアクセラレーションを使用していると思います（シェーダーで、おそらくOpenGLまたはOpenCLなどを使用していますが、詳細はわかりません）。この区別は、バッテリーでデバイスを使用している場合に特に重要です (HEVC は、品質に関して飛躍的に効率的であることは言うまでもありません)。Braswell モデルの使用方法に関する Chrome 開発チームの決定は、このように正当化されると思います。残念ながら、これはすべて十分に文書化されていません...