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

The safest default for streaming HDR delivery is 10-bit HEVC Main 10, 4:2:0, Rec. 2020 color primaries, PQ transfer, BT.2020 non-constant luminance matrix, plus valid HDR10 metadata. If one of those pieces is missing or mislabeled, the file may still play, but it may not trigger HDR mode on a TV, phone, browser, or platform transcode. That's the part that catches teams: the encode has to carry the image data and the signaling that tells the playback chain how to interpret 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 decision is simple: export a high-quality mezzanine from color, then make a streaming encode from that master rather than trying to use the editorial timeline export as the source of truth. The encode should preserve the HDR intent, not invent it.

Start with the HDR format, not the codec

H.265 is the compression format. HDR10, HLG, HDR10+, and 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 is designed to be more tolerant of SDR display paths, 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, but it can't turn an SDR grade into HDR. YouTube’s own guidance is blunt on this point: 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

The key takeaway is that “Main 10” only solves bit depth and decoder profile. It doesn't automatically prove that 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

Those numeric values matter because they're what downstream tools often report. If a QC report says primaries 1, transfer 1, matrix 1, that's Rec. 709 SDR signaling, not HDR10.

Static metadata helps displays tone map

HDR10 static metadata tells the display about the mastering environment and the content’s light levels, and it helps the playback device decide how to tone map the image to 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, white point, maximum luminance, and minimum luminance. Content light metadata describes the brightest pixel level and 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. If not, many teams use conservative defaults, but that's a delivery decision, not 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, not universal values. 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, distinguishes the profile setting from export color space and HDR10 metadata entry. The editor should set HEVC to Main 10 for 10-bit HEVC, and the editor enters HDR10 metadata values rather than relying on the app to magically analyze them. That means the editor still has to know what values belong in the deliverable.

Dynamic metadata changes the handoff

Static HDR10 metadata applies to the whole program. That can be good enough for many streaming uploads, but it's blunt. A dark interior and a bright exterior get the same global metadata, so the TV or platform tone mapper has less context. 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

That JSON isn't something to guess by hand during export. It should come from the HDR10+ mastering process or a trusted extraction/metadata pipeline. If the source has dynamic metadata and your transcode path drops it, the output may fall back to static HDR10 behavior or lose the intended dynamic tone mapping entirely. Hardware encoders need extra attention here. They're fast and often good enough for distribution encodes, but not all of them write HDR metadata in the same place. Some workflows write HDR10 metadata in the container but not in the HEVC bitstream, and some platforms accept that, but others may require the metadata in the bitstream, or they may behave differently after transmuxing to HLS or DASH. If your team sends the encode into a packaging pipeline, test the packaged output, not just 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, but 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's great for small streaming files and rough for editing, especially with 10-bit 4:2:2 camera originals, multicam, heavy effects, or systems without the right hardware decode block. For post, the cleaner workflow is usually:

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.
Make the HEVC streaming encode from that master.

This matters because proxy color tags and editorial preview paths can hide problems. A proxy may be Rec. 709, your team may view a timeline through a display transform, and the final HEVC encode may inherit the wrong tags if your team copies the export preset from an SDR job. Your team should configure the delivery encode from the HDR master’s actual color pipeline, not from whatever made the offline edit play smoothly.

Platform compatibility is narrower than “plays on my machine”

Consumer playback depends on the whole chain: file, container, app, OS, GPU, cable, display, and platform transcode, and a file can look fine in a desktop player and still fail to trigger HDR on 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 can be misleading because operating systems may tone map HDR into an SDR desktop, browser support varies, and GPU drivers may expose HDR differently than the TV app. A reference monitor through a proper video output device is ideal for finishing, but your team still needs consumer device testing because the consumer app decides whether viewers see the HDR rendition. On platforms that transcode uploads, wait until HDR processing finishes. A freshly uploaded file may initially show only SDR renditions. Once processing completes, the player or stats panel should indicate HDR, and supported devices should switch into HDR mode automatically. Viewers on unsupported devices should receive 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 behavior that inspection can't prove: crushed shadows, clipped highlights, washed-out color, wrong saturation, or SDR-looking playback. If the TV never switches into HDR mode, assume signaling is wrong unless 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 may be metadata placement, packaging, platform support, or a transcode rule. 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, make the HEVC encode from an approved HDR master, not from a random timeline preset. Use 10-bit HEVC Main 10, 4:2:0, Rec. 2020 primaries, PQ transfer, BT.2020 non-constant luminance matrix, and valid HDR10 static metadata. If the deliverable uses HDR10+ or Dolby Vision, preserve or generate the dynamic metadata through the proper mastering pipeline and 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.

For robust delivery, HDR metadata should be present where the target platform expects it. Many workflows place HDR10 signaling in the HEVC bitstream, while containers can also carry color and HDR metadata. Some transcode or packaging systems may preserve one location and drop another, so the packaged HLS, DASH, or final uploaded version should be inspected, not just the source MP4.

The most common 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 that viewers will use, and confirm the platform has finished HDR processing if the file was uploaded.

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