HDR video is coming to a Reel near you

Over the past year, Meta's Video Infrastructure teams have watched HDR uploads climb to millions per day across Facebook and Instagram. Now, creators can pull HDR clips from their phone's camera roll into Reels and have them play back in full high dynamic range. Getting there meant solving a set of technical problems that stem from one uncomfortable fact: the device landscape for HDR is a mess.

The compatibility gauntlet

HDR is not a single standard. Content can be encoded with HLG or PQ transfer functions, and may carry HDR10+ or Dolby Vision dynamic metadata. Different device manufacturers implement different subsets of these specs, and different sensors capture color differently. For a platform serving billions of videos, that variety creates a consistency problem: a video that looks correct on one device can appear washed out, too dark, or just wrong on another.

HDR also requires 10 bits per color component and modern codecs such as HEVC, VP9, or AV1, which raise decode complexity. Playback on devices that lack adequate support risks stuttering, buffering, and wasted bandwidth. The safe fallback — delivering an SDR version to everyone — degrades the experience for users with capable screens. The end-to-end answer requires generating both representations and choosing intelligently at delivery time.

The tone mapping problem

When a device can’t display HDR, the platform must provide an SDR rendition of the video. Tone mapping shrinks the dynamic range and color space of the content while preserving its intended look. Done poorly, it produces color shifts — blue trees, for example — or clips that are too bright or too dark. In a studio, a colorist adjusts a tone mapping operator by eye. Meta needed an automatic approach that works on every upload without human review, and that produces an SDR encode closely resembling the original HDR video.

After internal testing, the team settled on the popular Hable tone mapping operator, tuned to produce results that reasonably reflect the creator’s original intent. Precise visual quality metrics for tone mapping remain an open research problem, but in practice this operator delivered acceptable results at scale.

Client-side tone mapping

When HDR uploads first started hitting Meta’s pipeline, the media processing stack wasn’t ready for 10-bit color. Early HDR videos had overexposed colors. iOS devices were first to enable HDR by default, so the earliest problem was concentrated there. A quick fix came from Apple’s native tone mapping APIs: the client converted HDR compositions to SDR in the device before upload, which made everything look right everywhere.

Android was less cooperative. The device ecosystem lacked standardization, so OS-level mapping wasn't consistent, and Meta couldn't rely on it. Some devices produced PQ-HDR, others HLG, and there was no single approach that mapped both accurately to SDR. The team built custom tone mapping shaders to handle both transfer functions. During decoding, they extracted metadata to identify whether PQ or HLG was in use, then applied the right transformation matrices to move each frame from its original YUV colorspace into BT.709 SDR. With correct SDR frames in hand, the rest of the creation flow — AR filters, effects, composition — worked as before.

Client-side tone mapping fixed the color quality issue, but it only papered over the real goal: delivering actual HDR to the people who could see it.

Server-side tone mapping

With client-side conversion, HDR creators got watchable SDR videos. To deliver true HDR, Meta built tone mapping into its server-side pipeline. Uploads now carry the original HDR color information intact. The servers produce both HDR and SDR encodes; devices that can handle HDR get the HDR stream, and everyone else gets the SDR version.

Generating both representations doubles the compute cost for HDR videos, but Meta's Scalable Video Processor handles the extra load without increasing energy requirements. The SDR variants serve another purpose, too: mixed surfaces like the Instagram Explore grid or the Facebook Feed want uniform brightness across thumbnails and previews, so the SDR tone-mapped versions are what get shown there.

Brightness is a UX problem

HDR doesn’t just widen the color palette; it pushes brightness far beyond SDR levels. That creates an interaction design problem inside apps built around SDR video. On iOS, the default system behavior reserves the brightest display ranges for HDR content and dims SDR content—which is fine when the whole screen is a video, but jarring in a mixed grid. In the Explore tab, an HDR video next to SDR content grabs extra attention and feels unbalanced. For that surface, Meta uses client-side tone mapping on the fly to keep brightness uniform.

Reels presents the opposite situation: a single full-screen HDR video with SDR UI overlaid on top. Meta’s early experiments exposed an ugly side effect: white text rendered alongside HDR video looked gray—sometimes illegibly so. The cause was the same iOS dimming behavior applied to SDR overlays.

Since the goal was to show HDR video, converting back to SDR was off the table. Instead, Meta changed the overlays. By applying a brightness multiplier to overlay colors, UI elements extend into the HDR part of the spectrum and are rendered at a brightness comparable to the video itself. The result is white text that reads as actual white against HDR content.

Making the transition seamless

The full HDR playback path is now live for Reels. It took both client-side and server-side engineering to handle a device ecosystem that spans everything from old SDR-only phones to the latest HDR flagship screens. The server does double encodes and picks the right one at delivery; the client can tone map on the fly when the serving context demands SDR; and the UI layer now understands that in a full-screen HDR experience, even a simple label needs to be brighter to be legible. The result is a pipeline that treats HDR as a first-class citizen without leaving the rest of the device population watching videos that look wrong.

Rendering HDR in the browser

Once the HDR-encoded stream reaches the client, two big remaining questions are whether the user’s device can reproduce HDR and whether the browser can exploit that capability. Color management is notoriously browser- and OS-dependent, so Instagram’s approach treats this as a detection problem before it is a rendering problem.

The essential requirement is that the page render in an HDR-capable color space; display-p3 alone is insufficient because it can be mastered to SDR targets. The real check is for a wide-gamut, high-luminance surface such as rec2020 or one of the scene-oriented extended-range spaces.

Camera and display queries

The broader HDR state of the platform is exposed through the ImageCapture and MediaStreamTrack APIs, which offer direct capture capabilities over the device’s camera. But because those surfaces don’t expose the display’s tone-mapping and gamut parameters, the implementation falls back on heuristic detection. Specifically, WebGL can be used to probe for the availability of specific rendering extensions — most notably, floating-point framebuffers with half-float textures — which are reliably absent on SDR-only devices and often absent on non-HDR-capable GPUs even if the panel supports it.

To then discover whether the display is actually running in HDR, the page requests an ExtendedSrgb or Rec2020 canvas via the WebGL swapchain, then writes a color value with a full-intensity, wide-gamut RGB signature. Reading that value back and comparing it to the original indicates whether the display is tonemapping to SDR or is passing wide color through. On top of this canvas-level probe, the user’s saved HDR preference is respected at the system level.

That process yields a queue of four decisions:

  1. Device supports HDR capture: the camera API advertises an HDR mode or the specific codec and profile are present.
  2. Encode to HDR in real time: the device’s encoder exposes the target HDR profile and supports the bitrate/latency budget.
  3. End-to-end network delivery: the pipeline has negotiated an HDR-capable codec, profile, and bitrate.
  4. Client can render HDR: the canvas and browser checks pass, and playback is not forced into an SDR fallback track.

For the client-rendering check specifically, the platform sends a flag from the backend to the player indicating that HDR content is available on the server; the player then runs the capability checks above. If any check fails, playback reverts cleanly to the SDR stream without a visible hiccup.

The SDR fallback track

No client is guaranteed to support HDR playback, and even capable clients might face network constraints. So every HDR-rendered reel is also encoded to SDR. The SDR version is not a separate encode from a different master; it is derived automatically from the same HDR master through a display-mapping step that produces a Rec.709, gamma-2.2-compliant stream. That ensures every reel can serve the widest possible audience while HDR is progressively rolled out.

When both the HDR and SDR streams are available, the client shows the correct one based on the four-part check described above. Preference is given to HDR only once the device and rendering stack have both proven capable. There is no additional user-facing toggle in the capture flow: recording, effects processing, and preview happen natively in HDR when the session is established in that mode.

Quality verification at scale

Subjective verification of thousands of HDR encodes cannot rely on manual review. The team employed several objective metrics computed over the entire pipeline. Core among them are PSNR, SSIM, and VMAF scored against the source master; ΔE (CIE76) for color accuracy; and peak signal-to-noise-ratio against a tone-mapped reference using the HDR-specific tone-map VMAF model. For a global rollout, those reports are segmented by device family, encoder configuration, and network path, so any regression tied to a specific libx264 build or GPU driver is caught before it reaches a broad audience.

Rollout itself follows a progressive pattern: HDR encoding and delivery activate gradually across device models, Android and iOS versions, and geographic regions. This staging allows the team to watch real playback telemetry for anomalies — not just encode-side metrics, but also rendering-side signals like dropped frames or failed capability checks — before expanding the HDR footprint further.

Acknowledgements

This work is the result of a collaborative effort between the entire Video Infrastructure and Instagram Media Platform teams at Meta. The authors would like to extend special thanks to the following people: Anthony Dito, Rex Jin, Ioannis Katsavounidis, Ryan Lei, Wen Li, Richard Liu, Denise Noyes, Ryan Peterman, David Ronca, Bhumi Sabarwal, Moisés Ferrer Serra, Ravi Shah, Zafar Shahid, Haixia Shi, Nidhi Singh, and Kyle Yoon.