HDR10+ and Dolby Vision missing dynamic metadata

[DrHurt]

I've tested the current implementation and these are my findings:

It's VERY fast. I'm super impressed.

Video:

• DV P8.1: TV switches to HDR mode (not DV) and plays the HDR10 base layer, no DV dynamic metadata

• DV P5: TV switches to HDR mode (not DV), purple/green video as no HDR10 layer in P5

• HDR10+: TV switches to HDR mode (not HDR10+) and plays the HDR10 base layer without the "plus" metadata

• HLG & HDR10: both play correctly, TV switches to HDR mode and colours play correctly.

In the other thread, I said you could use AVPlayer to decode & render videos but if you can achieve the same results via AVSampleBufferDisplayLayer then that's probably better.

Thanks again and good luck

[DrHurt]

Tested again the new Sodalite rebrand 0.4.0 build 13

Same results:
Static HDR:
HLG & HDR10 - work as expected

Dynamic HDR:
HDR10+ --- plays HDR10 base layer (fallback)
DV P8.1/8.4 --- plays HDR10/HLG base layer (fallback)
DV P5 --- wrong colours (because no HDR10 fallback)

TV does NOT switch to DV mode with any of the DV profiles tested.

[DrHurt]

@superuser404notfound

I think I see a potential reason why DV is failing.

CMVideoFormatDescription in videotoolbox setup is missing kCMVideoCodecType_DolbyVisionHEVC and dvcC

Have a look here:
Marginal/QuickLookVideo#158

[superuser404notfound]

Sorry for not responding quicker! Thanks for your testing i will take a look into it!

[DrHurt]

No worries, sorry for tagging! Super impressed by your work. I think this will eventually become the gold standard for media playback on Apple devices replacing KSPlayer.

Very well done!!!

[superuser404notfound]

No worries, sorry for tagging! Super impressed by your work. I think this will eventually become the gold standard for media playback on Apple devices replacing KSPlayer.

Very well done!!!

Wow thanks a lot!! This project was started for my tvOS Jellyfin Player because all the existing engines wouldnt fit my needs or were to complicated to implement.

I pushed a potential fix for the dolby vision stuff. HDR10+ is still an issue i have to look at. Could you please test this? I currently dont have a dv display :(

[DrHurt]

That was super fast. I'll test it once you push a new built to test flight (don't have the setup to build this).

[superuser404notfound]

The fix is gonna be part of the 0.5.0 update, this may take some days until release. Thanks again for your testing, that was really helpful information!

[DrHurt]

HDR10+ probably needs kCMSampleAttachmentKey_HDR10PlusPerFrameData but we should wait until we test & iron out Dolby Vision before moving to HDR10+

I'll keep an eye on TestFlight and let you know how it goes.

[DrHurt]

I see you’ve released 0.5.0 with potential fixes for DV & HDR10+ but it’s probably still awaiting Apple review.

Looking forward to testing it and reporting back.

One trick we use is incrementing build number without changing version number. That bypasses Apple review and gives testers instant access to beta builds for quicker feedback & debugging.

We bump version only when releasing!

[superuser404notfound]

0.5.0 is now live for testing!

[DrHurt]

Unfortunately got exact same results. P8 & HDR10+ fall back to HDR10, wrong colours with P5.

First thought is whether gating on displaySupportsDolbyVision is actually working as expected (because Apple documentation says it’s deprecated) so it might be blocking the new pathway.

I’ll try again after work and will manually change TV mode to DV to see if that changes anything.

Might be worth removing gating for now for debugging purposes (another 0.5.0 build).

[superuser404notfound]

Thanks for testing and the detailed analysis! Two follow-up changes just landed (engine c01cb15, Sodalite fee8c3e). Will be in the next TestFlight build.

Two distinct root causes addressed:

1. displaySupportsDolbyVision gate removed — your hypothesis was on point. AVPlayer.availableHDRModes is soft-deprecated on tvOS 26 and observed in third-party players to lag the HDMI HDR-mode handshake. We now always tag DV streams as dvh1 + dvcC whenever the codec params carry an AVDOVIDecoderConfigurationRecord, regardless of the gate. Profile 8.1 / 8.4 still play their backward-compatible base layer on non-DV TVs; Profile 5 has no compatible base so it'll still produce wrong colours on a non-DV sink, same as before.

2. HDR10+ HEVC bitstream walker added — the HW (VideoToolbox) path was the bug here. FFmpeg only parses ITU-T T.35 SEI inside its own HEVC decoder, which we bypass entirely on the HW path. So AV_PKT_DATA_DYNAMIC_HDR10_PLUS on packets was empty for HEVC sources and our previous extraction returned nil. Now there's a manual NAL walker that parses PREFIX_SEI_NUT / SUFFIX_SEI_NUT, unescapes RBSP, finds payload_type 5 SEI matching the HDR10+ signature (country_code 0xB5 / terminal_provider 0x003C / oriented_code 0x0001 / application_identifier 4) and returns the T.35 payload starting at the country_code byte for kCMSampleAttachmentKey_HDR10PlusPerFrameData. SW path was already correct via AVFrame side data and is unchanged.

Diagnostics added so the next test round leaves a clear trace:

• [VideoDecoder] AVPlayer.availableHDRModes raw=N contains.dolbyVision=true|false on every stream open. Tells us what the deprecated API actually returns on your hardware.
• [VideoDecoder] Dolby Vision detected: profile=N level=N rpu=N el=N bl=N compat=N → tagging as 'dvh1' with dvcC plus a hex dump of the 24-byte dvcC atom. Lets us cross-check the bit packing against MP4Box -info if needed.
• [VideoDecoder] HEVC bitstream SEI walker found HDR10+ T.35 payload (N bytes) (one-shot per stream). Confirms the new HW-path extraction worked.
• [Renderer] HDR10+ attachment count: N (last payload N bytes) at 1, 30, then every 600 frames. Proves the metadata is actually reaching the display layer.

If you can grab a Console log during your next test (TV + Play/Pause for a screenshot is fine, idevicesyslog if you have a Mac), those four lines plus the visible TV behaviour should narrow down whatever remains in one round. Especially curious whether the gate logs contains.dolbyVision=true or =false on your TV.

Thanks again!