Repository navigation
Add registry for HDR metadata types? #242
Description
We have a couple of proposals to add support for different HDR metadata types:
In the context of Dolby HDR metadata, we have discussed at TPAC 2023 then more recently in MEIG in April the idea of handling this by maintaining a registry of values. This would allow new entries to be introduced without requiring the MC API spec itself to be updated, which could be valuable after it gets to Recommendation status. The registry idea first came up in 2019 in #118 (comment). We used the registry approach for similar reasons in EME for HDCP versions.
Is this the direction we prefer to go, or add enumeration values to HdrMetadataType?
Activity
markafoltz commentedon Apr 30, 2025
I recall this was also discussed at TPAC 2024.
The main issue identified, which I think @jernoble also shares similar thoughts, is that the registries should not be used as a way to bypass buy-in from browser vendors and vetting that new API features can be implemented in an unencumbered and interoperable manner.
Dolby Vision is concerning because of the lack of public specifications, although I recall that some of their specifications are now free to the public.
I don't think REC status is a good argument for a registry, as specs can continue to evolve after REC (i.e., "Level 2" specs).
wschidol commentedon Nov 11, 2025
I don't think that is what would be happening here. If a vendor does not support a given technology, they would simply not recognize some registry entries or entries, and fail the capability query. So admitting a new registry entry would not imply any sort of buy-in, I think?
The model that comes to mind is that the MIMEtype/codecs parameter in the capability APIs is also a registry of sorts, and someone taking a registry entry has never implied any kind of support by a vendor.
wschidol commentedon Nov 11, 2025
Two specifications come to mind that might be relevant in this context, Dolby Vision in ISOBMFF and Dolby Vision profiles.