How to Encode 10-bit H.265 with HDR Metadata for Streaming

An HDR file that plays but never triggers HDR mode on the TV is the standard failure here. The picture data is fine. The signaling around it is wrong. Streaming HDR delivery needs five pieces to line up:

10-bit HEVC Main 10
4:2:0 chroma subsampling
Rec. 2020 color primaries and PQ transfer
BT.2020 non-constant luminance matrix
Valid HDR10 metadata

Miss or mislabel one of those and the file can still play on a TV, phone, browser, or platform transcode without ever entering HDR mode. The encode has to carry both the image data and the signaling that tells the playback chain how to read it. A beautiful HDR grade encoded with Rec. 709 tags is a broken delivery. So is a PQ file with no mastering metadata when the platform expects HDR10. So is an 8-bit encode with HDR metadata pasted onto it. For most post teams the sequence is simple. Export a high-quality mezzanine from color, then build the streaming encode from that master. The editorial timeline export is not the source of truth. Your encode preserves HDR intent; it cannot invent it.

Start with the HDR format, not the codec

H.265 is the compression format. The HDR formats — HDR10, HLG, HDR10+, Dolby Vision — are display workflows layered on top of the picture essence and metadata.

HEVC is the encoded video layer; HDR behavior depends on additional signaling above it.

For streaming deliverables, the common HDR choices behave differently:

HDR10 uses PQ, 10-bit video, Rec. 2020 signaling, and static metadata for the mastering display and content light levels.
HLG uses a hybrid log-gamma transfer function and tolerates SDR display paths better, but it isn't the same as HDR10.
HDR10+ adds dynamic metadata so tone mapping can vary scene by scene or shot by shot.
Dolby Vision also uses dynamic metadata, but it's a licensed ecosystem with specific mastering, validation, and delivery requirements.

If the delivery spec just says “HDR H.265,” ask which HDR format it means. For YouTube-style uploads and many direct streaming workflows, HDR10 in HEVC Main 10 is the safest assumption unless the platform has a specific HLG, HDR10+, or Dolby Vision requirement. The next decision is whether you're encoding from a true HDR master. Metadata can describe HDR. It cannot turn an SDR grade into HDR. YouTube’s own guidance is explicit: HDR videos need HDR metadata in the codec or container, and your team should use metadata tools only when the video was actually graded with an HDR transfer function. Adding HDR tags to an SDR file will distort the image.

The core encode settings that make HDR work

For HDR10 streaming, the encode needs three categories of signaling: the bitstream profile and pixel format, the color volume tags, and the HDR metadata.

An HDR10 stream needs profile and pixel format, color volume tags, and HDR metadata together.

A typical HDR10 HEVC output should use these settings:

Codec: H.265 / HEVC
Profile: Main 10
Color primaries: BT.2020
Transfer characteristics: SMPTE ST 2084, also called PQ
Static metadata: SMPTE ST 2086 mastering display metadata and CTA-861.3 content light metadata

“Main 10” only solves bit depth and decoder profile. It does not prove the file is HDR10. The color tags and metadata still have to be right.

HDR10 signal	Expected value	Common x265 setting	Why it matters
HEVC profile and bit depth	Main 10, 10-bit	`profile=main10`, `output-depth=10`	Required for normal HDR10 decode paths. An 8-bit file with HDR tags is not a valid HDR10 delivery.
Pixel format	4:2:0 10-bit	`-pix_fmt yuv420p10le`	Broadest compatibility for streaming devices, TVs, and platform transcodes.
Color primaries	BT.2020	`colorprim=bt2020` or `--colorprim 9`	Tells the display the color gamut used by the encoded image. Rec. 709 tags can make HDR color display incorrectly.
Transfer characteristics	SMPTE ST 2084, PQ	`transfer=smpte2084` or `--transfer 16`	Tells the playback chain the code values are PQ HDR rather than SDR gamma.
Matrix coefficients	BT.2020 non-constant luminance	`colormatrix=bt2020nc` or `--colormatrix 9`	Keeps YCbCr conversion aligned with the intended HDR color volume.
Mastering display metadata	SMPTE ST 2086 values from the mastering display	`master-display=...`	Helps TVs and platforms tone map to displays with different peak brightness and black levels.
Content light metadata	MaxCLL and MaxFALL	`max-cll=...`	Gives the playback chain program-level brightness limits for tone mapping.

In x265 terminology, the common HDR10 VUI values are:

--colorprim 9 for BT.2020 primaries
--transfer 16 for PQ / SMPTE ST 2084
--colormatrix 9 for BT.2020 non-constant luminance
--output-depth 10 for 10-bit output
--hdr10 to signal HDR10 metadata behavior
--hdr10-opt for typical 4:2:0 HDR10 encoding

Learn those numbers, because they are what downstream QC tools report back to you. A report reading primaries 1, transfer 1, matrix 1 is Rec. 709 SDR signaling, not HDR10.

Static metadata helps displays tone map

HDR10 static metadata describes the mastering environment and the content’s light levels. The playback device uses it to decide how to tone map the image onto its own panel.

Static HDR metadata helps a playback display tone map bright content to its own range.

HDR10 typically carries two kinds of static metadata:

Mastering display color volume, often referred to as SMPTE ST 2086
Content light level metadata, commonly MaxCLL and MaxFALL from CTA-861.3

Mastering display metadata describes the display used to master the content: its RGB primaries and white point, plus maximum and minimum luminance. Content light metadata describes the brightest pixel level and the frame-average light level in the program. Don't treat these as random defaults. If you mastered on a 1000-nit HDR reference monitor, the metadata should reflect that monitor or the approved mastering environment. If the colorist generated measured MaxCLL and MaxFALL values, use those. Many teams fall back to conservative defaults, but that is a delivery decision rather than a technical truth. In x265, a simplified HDR10 command often looks like this:

ffmpeg -i hdr_master.mov \
  -c:v libx265 \
  -pix_fmt yuv420p10le \
  -x265-params "profile=main10:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:hdr10=1:hdr10-opt=1:master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50):max-cll=1000,400" \
  -c:a aac -b:a 320k \
  output_hdr10.mp4

The mastering display numbers above are examples only. The L(10000000,50) style notation is x265’s scaled representation of max and min luminance. Use the values from the actual mastering display, or from the mastering metadata supplied with the source. If you're using a GUI encoder, look for settings named along these lines:

HEVC profile: Main 10
Export color space: Rec. 2020 PQ, HDR10, or equivalent
Include HDR10 metadata
Mastering display primaries and luminance
MaxCLL and MaxFALL

Premiere Pro, for example, keeps the profile setting separate from export color space and HDR10 metadata entry. Set HEVC to Main 10 for 10-bit output, then type the HDR10 metadata values in by hand. The app will not analyze them for you, so you have to know which values belong in the deliverable.

Dynamic metadata changes the handoff

Static HDR10 metadata applies to the whole program. That is good enough for many streaming uploads, but it is coarse. A dark interior and a bright exterior get the same global metadata, so the TV or platform tone mapper has less to work with. Dynamic metadata formats exist to solve that:

HDR10+ carries dynamic metadata, usually scene-based or frame-based, alongside the HDR10-style base video.
Dolby Vision carries dynamic metadata and may include additional profiles, compatibility layers, or platform-specific packaging requirements.
Some encoders can pass or write HDR10+ metadata only with certain codec paths.

For x265 HDR10+, you commonly pass the dynamic metadata with an option like:

--dhdr10-info metadata.json

Never guess at that JSON by hand during export. It comes from the HDR10+ mastering process or from a trusted extraction pipeline. If the source has dynamic metadata and your transcode path drops it, the output falls back to static HDR10 behavior or loses the intended dynamic tone mapping entirely. Hardware encoders need extra attention. They are fast and good enough for distribution encodes, but not all of them write HDR metadata in the same place. Some write HDR10 metadata into the container and not into the HEVC bitstream. Certain platforms accept that. Others require the metadata in the bitstream, or behave differently after transmuxing to HLS or DASH. If the encode feeds a packaging pipeline, test the packaged output as well as the original MP4.

Keep editorial formats out of the delivery decision

A lot of HDR problems start earlier than export. Editorial may be cutting with proxies, optimized media, or long-GOP camera files. That's normal, and it shouldn't define the final streaming encode. H.265 is efficient because it's interframe compression, which means it stores differences across groups of pictures rather than complete independent frames. That is great for small streaming files and rough for editing. It gets worse with 10-bit 4:2:2 camera originals, with multicam or heavy effects, and on systems missing the right hardware decode block. For post, the cleaner order of operations is:

Camera originals or graded masters remain the image source of truth.
Proxies or intraframe mezzanines handle editing performance.
The final conform and grade output a high-quality HDR master.
The HEVC streaming encode is made from that master.

Proxy color tags and editorial preview paths hide problems. A proxy may be Rec. 709. The timeline may be viewed through a display transform. Copy an export preset from an SDR job and the HEVC encode inherits its wrong tags. Configure the delivery encode from the HDR master's actual color pipeline. Whatever made the offline edit play smoothly is irrelevant here.

Platform compatibility is narrower than “plays on my machine”

Consumer playback depends on the whole chain:

The file and its container
The app, the OS, and the GPU
The cable, the display, and any platform transcode

A file can look correct in a desktop player and still fail to trigger HDR in a TV app.

A file that looks correct locally can still fail to trigger HDR on the real viewing device.

For broad streaming compatibility, 10-bit HEVC Main 10 with 4:2:0 chroma is still the center of gravity. H.264 isn't the right choice for many HDR streaming paths. YouTube’s HDR live streaming guidance, for example, points to H.265 / HEVC and Main 10 for HDR streaming support. When you test playback, use devices that resemble the audience path:

A current HDR TV using the platform’s native app
A recent HDR-capable phone or tablet
A Windows or Mac system with HDR output actually enabled
A streaming box connected to an HDR display
The packaged stream, if your team will deliver the file as HLS or DASH

Desktop verification misleads. Operating systems tone map HDR into an SDR desktop, browser support varies, and GPU drivers can expose HDR differently than the TV app does. A reference monitor through a proper video output device is ideal for finishing. You still need consumer device testing, because the consumer app decides whether viewers ever see the HDR rendition. On platforms that transcode uploads, wait until HDR processing finishes. A freshly uploaded file may show only SDR renditions at first. Once processing completes, the player or stats panel should indicate HDR, and supported devices should switch into HDR mode automatically. Viewers on unsupported devices get an SDR version or tone-mapped playback, depending on the platform.

Inspect the file, then watch it

Use both technical inspection and real playback, because neither is enough alone. A media inspection tool should report the essentials:

HEVC Main 10
BT.2020 color primaries
PQ / SMPTE ST 2084 transfer
BT.2020 non-constant luminance matrix
Mastering display metadata

Then watch the file on an HDR display and look for what inspection cannot prove:

Crushed shadows or clipped highlights
Washed-out color or wrong saturation
Playback that simply looks SDR

If the TV never switches into HDR mode, assume the signaling is wrong until you can prove otherwise. A useful troubleshooting move is to compare three things side by side: the graded master, the encoded MP4, and the platform-processed version. If the local MP4 is correct but the platform version isn't, the problem sits downstream in metadata placement, packaging, or the platform's own support and transcode rules. If the MP4 is already wrong, fix the encode before blaming the platform.

Metadata mistakes that break HDR

Most HDR delivery failures are mismatches between the image and the tags. Common failure modes include:

Encoding 8-bit video while tagging it as HDR
Leaving export color space at Rec. 709
Omitting mastering display metadata for an HDR10 deliverable
Using full range when the expected delivery is limited range
Judging HDR playback on an SDR desktop path

The pattern is simple: every stage has to agree about what the pixels mean. If the grade is PQ but the file says Rec. 709, the display will interpret the code values incorrectly. If the metadata says HDR but the image data is SDR, the platform may stretch or tone map it into something ugly. If the transcode strips dynamic metadata, the output may still be HDR, but not the HDR version that was approved.

A sane delivery recipe

For a standard HDR10 streaming file, build the HEVC encode from an approved HDR master rather than from a random timeline preset. Configure it like this:

10-bit HEVC Main 10, 4:2:0
Rec. 2020 primaries, PQ transfer, BT.2020 non-constant luminance matrix
Valid HDR10 static metadata

If the deliverable uses HDR10+ or Dolby Vision, preserve or generate the dynamic metadata through the proper mastering pipeline, then confirm the platform supports that exact profile. Then inspect the encoded file and test the actual viewing path. HDR success means the file is identified as HDR, displayed as HDR on supported devices, and converted acceptably for everyone else.

FAQ

No. 10-bit HEVC only confirms the bit depth and codec profile. For HDR10, the file also needs correct color signaling, usually BT.2020 primaries, PQ transfer, BT.2020 non-constant luminance matrix, and valid HDR metadata such as mastering display data plus MaxCLL and MaxFALL.

A common safe target is HEVC Main 10, 10-bit, 4:2:0, limited range, BT.2020 color primaries, SMPTE ST 2084 PQ transfer, BT.2020 non-constant luminance matrix, and HDR10 static metadata. The exact bitrate, GOP structure, audio format, and container should follow the platform delivery spec.

No. HDR metadata describes how HDR graded image data should be interpreted. It doesn't create HDR picture information. Adding PQ, BT.2020, or HDR10 metadata to an SDR Rec. 709 master can cause incorrect brightness, saturation, and tone mapping on playback.

HDR metadata has to be present wherever the target platform looks for it. Many workflows put HDR10 signaling in the HEVC bitstream, and containers can carry color and HDR metadata too. Some transcode and packaging systems preserve one location while dropping the other. Inspect the packaged HLS, DASH, or uploaded version, not only the source MP4.

The usual causes are missing or wrong color tags, HEVC Main instead of Main 10, 8-bit output, Rec. 709 signaling, missing HDR10 mastering metadata, unsupported dynamic metadata, or a playback path that isn't HDR capable. Test on the actual app, device, cable path, and display your viewers will use. If the file was uploaded, confirm the platform has finished its HDR processing.

Treat consumer-device testing like a review pass rather than a loose email thread. Aspect gives reviewers frame-accurate comments and annotations, so a note about clipped highlights, washed-out playback, or missing HDR mode lands on the exact frame in the review workflow.