GoogleはAndroid 17で、HDR動画の見え方を端末任せにしないための新しい表示規格「Eclipsa Video」を導入する。対象は、暗い部屋でSNSを見ているとHDR動画だけが急にまぶしくなる問題や、スマートフォンでは鮮やかだった動画がテレビでは暗く、または白っぽく見える問題だ。
これまでHDRの体験は、動画側の情報とディスプレイ側の解釈に強く左右されてきた。Eclipsa Videoはここへ、HDR Reference Whiteと呼ぶ基準点、画面の明るさ余力に応じた変換、フレーム単位の指示を持ち込む。Android 17ではこの仕組みがプラットフォームの再生・撮影経路に入るため、アプリ開発者にとっては「HDRをどう見せるか」を個別に作り込む範囲が小さくなる。
ただし、これはすべてのAndroid 17端末で同じ映像体験を保証する話ではない。Googleは、Eclipsa Videoの再生と撮影をAndroid 17以降の端末でサポートするとしつつ、HDRディスプレイがEclipsaの適合試験を通ることを条件にしている。普及の焦点はOS機能の有無より、対応端末、対応アプリ、対応コンテンツが同時に増えるかどうかにある。
HDRとUIを同じ画面で扱うルール
Eclipsa Videoの中心にあるのは、HDR動画を単体で明るく見せることではない。標準ダイナミックレンジの文字や字幕、ボタンを含むアプリ画面と、HDR動画を同じ画面上で破綻なく合成することだ。SMPTE ST 2094-50は、動画に加えてテキストやグラフィック、画像を含む混在表示を、共通の色ボリューム構造の中で扱うための動的メタデータ体系として説明されている。
その基準になるのがHDR Reference Whiteである。これは、SDR要素のピーク輝度をディスプレイ側の基準白へ合わせ、そこを超える明るさをHDRのハイライトに残すための目印になる。スマートフォンのフィードでHDR動画だけが画面全体を押し上げ、キャプションやUIが読みにくくなる問題は、この境界が端末ごとにばらつくことで起きやすい。
Eclipsa Videoはさらに、画面の「ヘッドルーム」、つまり基準白より上にどれだけ明るさを出せるかに応じて表示を変える。高輝度のテレビなら強いハイライトを活かし、明るさ余力が小さいモバイル画面なら眩しさを抑えながら階調を残す。1本の静的なトーンマッピングではなく、フレームごとの指示を動画に持たせる点がこの規格の肝である。
Media3とCamera2に入った実装経路
Android 17では、Eclipsa Videoが発表文上の名前から、開発者が使う実装経路へ移った。Googleの実装ガイドは、再生にはJetpack Media3のExoPlayerを使うことを推奨している。SMPTE 2094-50メタデータを含むファイルを解析すると、ExoPlayerがメタデータを取り出して適用するため、標準的な再生アプリでは専用のプレイヤー設定を増やさずに扱える。
撮影側にも入口がある。AndroidのCamera2では、端末が対応しているかをCameraCharacteristicsで確認したうえで、HLG10_SMPTE_2094_50という動的レンジプロファイルをエンコーダー面へ渡す。Googleの説明では、メタデータのために明示的なコーデック設定を追加する必要はなく、対象の動的プロファイルが有効ならAndroidのメディアフレームワークがメタデータを付与し、下流へ渡す。
APIリファレンスを見ると、この扱いはHLG以外にも広がる。Android 17/API 37では、STANDARD_SMPTE_2094_50、HDR10_SMPTE_2094_50、HDR10_PLUS_SMPTE_2094_50に加え、Dolby Vision系のSMPTE_2094_50付きプロファイルも追加されている。つまりAndroidはEclipsa Videoを、既存のHDR名を置き換えるブランドではなく、複数の動的レンジ経路に載せるメタデータ層として扱う。
オープン仕様でも、端末差は消えない
GoogleはEclipsa Videoを、AppleとNBCUniversalとの協力で開発したオープンなSMPTE ST 2094-50仕様に基づく標準として説明している。SMPTEの公開リポジトリでも、ST 2094-50はHDR Reference Whiteを明示し、ピーク輝度が大きく異なるディスプレイ間で知覚上の意図を保つための仕組みとされる。
一方で、現時点の資料は慎重に読む必要がある。SMPTEのGitHubには2026年2月23日付けの第2公開委員会ドラフトが示され、レビュー期限は2026年3月16日までとされているが、リポジトリ上に正式リリースはまだ見当たらない。規格として開かれていることと、市場のすべての機器が同じ品質で対応することは別の話である。
Android側にも制約がある。実装ガイドは、ハードウェアアクセラレーションの有無をDisplayのLutPropertiesで確認する説明を置き、ハードウェアアクセラレーションを持たない端末向けにはExoPlayerでEclipsa Videoレンダリングをオプトアウトする支援が開発中だとしている。旧来の描画経路より扱いやすくなるとしても、性能と電力、パネル特性の差は残る。
普及の判断材料はコンテンツ側に移る
Eclipsa Videoの導入で、Android側の受け皿はかなり具体的になった。再生はMedia3、撮影はCamera2、仕様はSMPTE ST 2094-50という形で、アプリ開発者が触る場所は明確である。Android 16/API 36以前のレガシーなレンダリング層で起きる既知のデコード上の問題を、Media3側へ寄せて避けるという説明も、Googleの実装ガイドに含まれている。
ここから先の勝負は、動画がそのメタデータを持って流通するかどうかだ。OSとプレイヤーが対応しても、動画側に参照白やヘッドルームに関する指示がなければ、表示のばらつきを十分には抑えられない。スマートフォンで撮ったHDR動画、SNSの縦動画、テレビ向け配信がどの順番で対応するかによって、ユーザーが感じる変化は大きく変わる。
Android 17は、HDR動画のまぶしさをユーザーが明るさスライダーで手当てする状態から、作り手の意図と端末の能力をメタデータで結ぶ状態へ一歩進める。ただし、その一歩はOSだけでは完結しない。Pixelや主要Android端末がどの範囲でEclipsa適合を掲げ、主要アプリがMedia3経由でこのメタデータをどれだけ素直に通すかが、次の確認点になる。