With Android 17, Google is introducing a new display standard called "Eclipsa Video" that aims to stop leaving how HDR video looks up to the whims of individual devices. It targets problems like HDR videos suddenly becoming glaringly bright while browsing social media in a dark room, or videos that looked vivid on a smartphone appearing dim or washed-out on a TV.
Until now, the HDR viewing experience has been heavily shaped by both the information embedded in the video and how the display chooses to interpret it. Eclipsa Video introduces a reference point called HDR Reference White, conversion logic based on how much brightness headroom a screen has, and frame-by-frame instructions. Because this mechanism is now built into the platform's playback and capture pathways in Android 17, app developers will have less need to individually engineer how HDR should be displayed.
However, this doesn't mean every Android 17 device will deliver an identical viewing experience. While Google states that Eclipsa Video playback and capture are supported on Android 17 and later devices, it also conditions this on the HDR display passing Eclipsa's conformance testing. The real question for adoption isn't whether the OS feature exists, but whether supporting devices, supporting apps, and supporting content all expand together.
A Rule for Handling HDR and UI on the Same Screen
At the core of Eclipsa Video isn't simply making HDR video brighter on its own. It's about seamlessly compositing standard dynamic range elements—text, subtitles, buttons—together with HDR video on the same screen without visual breakdown. SMPTE ST 2094-50 is described as a dynamic metadata framework for handling mixed displays that include not just video but also text, graphics, and images, all within a shared color volume structure.
The reference point for this is HDR Reference White. It serves as a marker for aligning the peak brightness of SDR elements with the display's reference white, while reserving brightness beyond that point for HDR highlights. The problem of HDR video pushing up the brightness of an entire smartphone feed screen—making captions and UI elements hard to read—tends to occur precisely because this boundary varies from device to device.
Eclipsa Video also adjusts display behavior based on a screen's "headroom"—how much additional brightness it can produce above the reference white. A high-brightness TV can make full use of strong highlights, while a mobile screen with limited brightness headroom can preserve tonal detail while keeping glare in check. The key feature of this standard is that it carries frame-by-frame instructions within the video itself, rather than relying on a single static tone-mapping curve.
Implementation Paths Built into Media3 and Camera2
With Android 17, Eclipsa Video has moved from being a name in an announcement to an actual implementation path that developers can use. Google's implementation guide recommends using Jetpack Media3's ExoPlayer for playback. When ExoPlayer parses a file containing SMPTE 2094-50 metadata, it extracts and applies that metadata automatically, meaning standard playback apps can handle it without adding dedicated player configuration.
There's also an entry point on the capture side. In Android's Camera2, after checking device support via CameraCharacteristics, apps pass a dynamic range profile called HLG10_SMPTE_2094_50 to the encoder surface. According to Google's explanation, no explicit codec configuration is needed for the metadata itself—as long as the target dynamic range profile is enabled, Android's media framework attaches the metadata and passes it downstream.
Looking at the API reference, this handling extends beyond HLG. In Android 17/API 37, profiles such as STANDARD_SMPTE_2094_50, HDR10_SMPTE_2094_50, and HDR10_PLUS_SMPTE_2094_50 have been added, along with Dolby Vision variants that include SMPTE_2094_50. In other words, Android treats Eclipsa Video not as a brand replacing existing HDR names, but as a metadata layer that rides on top of multiple dynamic range pathways.
An Open Specification, But Device Differences Remain
Google describes Eclipsa Video as a standard based on the open SMPTE ST 2094-50 specification, developed in collaboration with Apple and NBCUniversal. SMPTE's public repository also explicitly defines HDR Reference White as a mechanism for preserving perceptual intent across displays with widely differing peak brightness levels.
That said, current materials should be read with some caution. SMPTE's GitHub shows a second public committee draft dated February 23, 2026, with a review deadline of March 16, 2026—but no formal release has yet appeared in the repository. A specification being open is a separate matter from every device on the market supporting it with equal quality.
There are constraints on the Android side as well. The implementation guide explains how to check for hardware acceleration availability via Display's LutProperties, and states that support for opting out of Eclipsa Video rendering in ExoPlayer—intended for devices without hardware acceleration—is still under development. Even if this proves easier to handle than older rendering pathways, differences in performance, power consumption, and panel characteristics will remain.
The Deciding Factor for Adoption Shifts to Content
With the introduction of Eclipsa Video, the receiving infrastructure on the Android side has become fairly concrete. Playback runs through Media3, capture runs through Camera2, and the specification is SMPTE ST 2094-50—the touchpoints for app developers are now clearly defined. Google's implementation guide also notes that known decoding issues occurring in the legacy rendering layer of Android 16/API 36 and earlier can be avoided by shifting to the Media3 side.
The next battle is whether videos actually carry that metadata as they circulate. Even if the OS and player support it, if the video itself lacks instructions regarding reference white or headroom, variability in display quality won't be sufficiently suppressed. How much the experienced change differs for users will depend heavily on the order in which HDR videos shot on smartphones, vertical social media videos, and TV-oriented streaming content adopt this support.
Android 17 takes a step forward—from a state where users compensate for glaring HDR video with a brightness slider, toward one where creator intent and device capability are connected through metadata. But that step can't be completed by the OS alone. The next things to watch are how broadly Pixel and other major Android devices claim Eclipsa conformance, and how faithfully major apps pass this metadata through via Media3.