6.73.0 - The Dolby Vision supplemental is emitted on every display

The second guard from the same May afternoon as the last release, re-measured and gone. What is left on this branch is what the HLS authoring specification asks for, with no deviation.

Changed

SUPPLEMENTAL-CODECS is emitted for Profile 8.1 and 8.4 on every display (#493). It used to be gated on the display's own Dolby Vision capability, because on 2026-05-26 emitting it unconditionally switched an HDR10-only panel to HDR through VIDEO-RANGE=PQ and then showed a black picture with no error at all. That was a measurement, not a guess, and it does not reproduce on tvOS 26.6.

Measured on an Apple TV 4K 3rd generation at a Samsung HDR10+ panel with no Dolby Vision of its own, the session's own DV mode false and the master carrying the supplemental:

CODECS="hvc1.2.4.L150",SUPPLEMENTAL-CODECS="dvh1.08.07/db1p",VIDEO-RANGE=PQ
CODECS="hvc1.2.4.L150",SUPPLEMENTAL-CODECS="dvh1.08.07/db4h",VIDEO-RANGE=HLG

Both play, picture present, no error log entry in either session. Profile 8.4 got its own arm rather than inheriting 8.1's, which took the fixed-HDR output mode to produce at all: with the box on Match Dynamic Range the panel readout drops and an 8.4 routes media-direct, where a master never exists.

The reason to move rather than merely re-test is the one @DrHurt gave on the thread. Pairing a plain hvc1 primary CODECS with a DV supplemental is what the spec asks for, and the pairing exists so a client that does not recognise dvh1 reads the HDR10 or HLG base layer instead of failing to play. That client is not hypothetical here: AirPlayPlaylistDecision hands the loopback master to wireless receivers, and its own measured table has an Apple TV in fixed Dolby Vision mode accepting a 4K PQ master with the supplemental. An AirPlay 2 television is the device the pairing was written for. On top of that the gate keyed on the SENDING device's display, which on iOS is read device-wide, so a sender without Dolby Vision aimed at a receiver that has it dropped the signal for nothing.

Added

[DisplayCapabilities] observed: hdr=… hdr10=… hlg=… dv=…, once per load. Every question this table decides has been answered by inferring backwards from the outcome, and it decides more than it looks: a Profile 8.4 resolving to effective-format=sdr on an HDR panel is the clamp reading supportsHLG for an HLG base layer, and from the outcome alone there is no telling an HDMI chain that does not advertise HLG from an engine misreading the platform. It answered exactly that on the rig above within one playback: hdr10=true hlg=false in both output modes, so the clamp was following its own table. A per-mode false is an assertion the platform made rather than an absence of information, which is what this whole issue turned on for macOS, and now it says so out loud. It lands in the host's diagnostic log like every other engine line.

Acknowledgements

@DrHurt for the spec argument and for measuring Profile 8.4 independently on his own hardware and OS versions. Two releases in one day came out of one thread that started as "the engine should stop distinguishing Dolby Vision from HDR", and both of them removed something that had been inherited rather than re-checked.

Full changelog: CHANGELOG.md | 6.72.0...6.73.0