7月14日、Mozilla Graphics Teamが「HDR video in Firefox for Windows tech retrospective」と題した記事を公開した。FirefoxのWindows向けHDR動画サポートの実装を振り返ったもので、「最初に立てた設計仮説はほぼすべて外れた」と率直に述べている点が印象的だ。
HDR（High Dynamic Range）動画は、NetflixやYouTubeでの配信が標準化しつつある中、ブラウザサポートの整備が急がれている分野だ。Chromeはすでに対応を進めており、FirefoxもmacOSでは先行して実装済み。しかしWindowsでの実装は、OSのグラフィックスAPIとブラウザのレンダリングアーキテクチャが複雑に絡み合うため、macOSとはまったく別の困難が待っていた。元記事はその試行錯誤の全貌を詳しく記録したものだ。
「SetColorSpace1を指定すれば済む」という当初の想定は崩れた
チームが実装当初に立てた仮説は、おおむね以下のようなものだった。
- WindowsのDXGIスワップチェーンに
SetColorSpace1でBT.2100 PQを指定すれば対応できる - 映像フレームの伝達関数はBT.1886 EOTFで固定のはず
- VideoProcessorBltを使えばGPU省電力化も両立できる
これらはすべて、実装を進める中で覆された。AMD製GPUでテストするとSetColorSpace1の指定が無視され、HDR動画がBT.709（SDR用の色空間）として誤表示されることが判明。チームは自作のコンポジタテストアプリでこれを確認した。
コードベースの問題も深刻だった。従来のFirefoxは映像フレームが必ずBT.1886 EOTF（SDR映像の標準的な電気光学伝達関数）を使うと仮定して設計されていたため、HDR映像の伝達関数情報を各構造体に持ち回れるよう、数十個の構造体を根本から変更する必要があった。「ブラウザのグラフィックス実装に詳しいエンジニアは少なく、マルチプロセス・サンドボックス・共有メモリ・外部テクスチャ共有といったブラウザ固有の文脈でDirectCompositionやHDR動画再生をどう使うかのドキュメントもほぼ存在しない」と記事は述べており、パイオニア的な作業を強いられた実態が伝わってくる。
HDR動画処理の全体像
FirefoxのHDR動画処理は大まかに以下の流れで行われる。
- デマックス＋デコード：MP4やMKVといったコンテナフォーマットから映像・音声ストリームを分離し、コーデックでデコードする。HDR映像の出力はP010フォーマット（10ビットYUV）になる
- Gecko displaylist構築：デコードされたフレームをWebRenderに渡すためのdisplaylistに組み込む
- WebRender：映像フレームをデスクトップコンポジタのオーバーレイに昇格させるか、通常のHTMLレンダリングパスで処理するかを判断する
ここで重要なのがデスクトップコンポジタオーバーレイの存在だ。WindowsではDirectComposition APIを使ってDWM（Desktop Window Manager：Windowsの画面合成エンジン）上にビジュアルを合成する。HDR動画はBT.2100 PQ色空間・RGB10A2フォーマットを使用するが、WebRenderはsRGB色空間しか扱えない。そのためHDR動画においてオーバーレイは最適化ではなく必須となる。
最大の意思決定：VideoProcessorBlt vs 自前シェーダー
技術的に最も重要な選択が、色変換をどう行うかの判断だ。
VideoProcessorBltはGPUの専用ビデオプロセッサユニットを活用できるため消費電力面で有利だが、チームがCheckVideoProcessorFormatConversionでサポート状況を確認したところ、P010 PQ→RGB10 PQ変換に対応するGPUは多いが、HLG動画（P010 HLG→RGB10 PQ）に対応するGPUは少ないことが判明した。video-dynamic-range CSSメディアクエリはPQとHLGを区別できるほど細かくないため、VideoProcessorBltを必須にするとHDRディスプレイユーザーの約20%しか機能を使えないという試算になった（Nightly試験時の実機調査に基づく数字として元記事に記載されている）。
一方、自前のGLSLシェーダーを書くアプローチには次のメリットがある。
- すべてのGPUベンダーで一貫した動作
- HDRトーンマッピング（後述）の実装が可能
- スマートフォンで撮影した90/180/270度回転動画への対応
- BT.2020→BT.709の色域変換を含む任意のYUV→RGB変換
- scRGB（RGBA16F：DirectXで広色域を浮動小数点で扱うフォーマット。HDR対応ディスプレイとの親和性が高い）やBT.2100 PQ（RGB10A2）など任意のEOTFへの対応
チームはNightlyでVideoProcessorBltを長期間試験した後、最終的にシェーダーを選択した。
SDRディスプレイへのトーンマッピング問題
HDRコンテンツをSDRディスプレイで表示する際は、輝度を圧縮する「トーンマッピング」が必要になる。Mozillaは当面、Erik Reinhard氏らの論文「Photographic Tone Reproduction for Digital Images」に基づくReinhard tonemappingを採用し、SDR表示時は400 cd/m²→100 cd/m²の固定輝度比で適用する方針だ。
一方、HDRディスプレイではトーンマッピングを適用しない方向で検討が進んでいる。理由は複数ある。
- ライトセンサーを持つデバイスでは基準輝度がリアルタイムに変化し、毎フレーム再描画が必要になるとバッテリーを大幅に消費する
- 輝度の上限を動的に変えるとブラウザフィンガープリンティング（ユーザー追跡）のベクターになりうる
- 複数の画像を含むページでは画像ごとに異なるトーンマッピングが適用されてしまう
- Nightly利用者からのフィードバックでも「トーンマッピングを適用しない方が視聴体験が良い」との意見が多かった
今後の課題
現状、DRM保護付き動画を含む通常動画の再生に対応した。今後の予定として以下が挙げられている。
- WebGL/WebGPU/Canvas2Dへの対応（キャンバスのHDR対応が前提）
- WebRTCのHDR対応（libwebrtcでの実装、ビデオ会議やゲームストリーミング向け）
- 写真・アプリ・一般Webコンテンツへのサポート拡張
- VideoProcessorBltを省電力最適化として活用する可能性の検討
またWindows 11 23H2で追加されたIDCompositionTextureインターフェースは全フォーマット・全色空間で普遍的にサポートされるとされており、将来的な選択肢として注目している。仮説が外れ続けた実装の試行錯誤がどのような教訓をもたらしたのか、技術的な詳細に関心がある方には一読の価値ある記事だ。
詳細はHDR video in Firefox for Windows tech retrospectiveを参照していただきたい。
