Extends the Media Capabilities API to allow detection of HDR rendering support via three new VideoConfiguration dictionary fields: hdrMetadataType, colorGamut, transferFunction. Chromium implements its own tone-mapping algorithms so will always return true for HDR10 (smpteSt2086) static metadata. HDR10+ (smpteSt2094-10) and Dolby Vision (smpteSt2094-40) dynamic metadata are not currently supported, so will return false. We anticipate adding support for dynamic metadata in the future, so this API will allow developers to select the appropriate content for users with support.
Low interop risk: Already shipping in Safari.
Will start returning false for some DolbyVision and HDR10+ metadata types on the web -- playback would have been broken already for these.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No risks unique to WebView.
Debuggable through media dev tools and chrome://gpu information.
Shipping on desktop | 120 |
Shipping on Android | 120 |
Shipping on WebView | 120 |
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
Spec changes have already been submitted since the feature is shipping in Safari.SummaryExtends the Media Capabilities API to allow detection of HDR rendering support via three new VideoConfiguration dictionary fields: hdrMetadataType, colorGamut, transferFunction. Chromium implements its own tone-mapping algorithms so will always return true for HDR10 (smpteSt2086) static metadata. HDR10+ (smpteSt2094-10) and Dolby Vision (smpteSt2094-40) dynamic metadata are not currently supported, so will return false. We anticipate adding support for dynamic metadata in the future, so this API will allow developers to select the appropriate content for users with support.
Blink componentBlink>Media>Capabilities
TAG reviewAlready shipping by another UA. The now-closed Media Capabilities TAG review covered similar discussions: https://github.com/w3ctag/design-reviews/issues/218
TAG review statusNot applicable
RisksInteroperability and CompatibilityLow interop risk: Already shipping in Safari.
Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/910)
Activation
Web developers: Positive (https://github.com/w3c/media-capabilities/issues/118#issuecomment-511461132)
Other signals:WebView application risksWill start returning false for some DolbyVision and HDR10+ metadata types on the web -- playback would have been broken already for these.
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No risks unique to WebView.
DebuggabilityDebuggable through media dev tools and chrome://gpu information.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?Yes
Is this feature fully tested by web-platform-tests?Yes
Flag name on chrome://flags
Finch feature nameMediaCapabilitiesDynamicRange
Requires code in //chrome?False
Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1048045
Estimated milestonesShipping on desktop120Shipping on Android120Shipping on WebView120
Anticipated spec changesOpen questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
Spec changes have already been submitted since the feature is shipping in Safari.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/6640863931269120
Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/jBzVLBz-Yk4/m/ORuQg2zAEwAJ
On Thursday, October 19, 2023 at 1:18:44 AM UTC+2 blink-dev wrote:Contact emailsvi...@microsoft.com, gwhit@microsoft.com, gurvir@microsoft.com, dalecurtis@chromium.org
Explainerhttps://github.com/w3c/media-capabilities/blob/main/explainer.md#decode-capabilities
Specificationhttps://www.w3.org/TR/media-capabilities/#hdrmetadatatype
SummaryExtends the Media Capabilities API to allow detection of HDR rendering support via three new VideoConfiguration dictionary fields: hdrMetadataType, colorGamut, transferFunction. Chromium implements its own tone-mapping algorithms so will always return true for HDR10 (smpteSt2086) static metadata. HDR10+ (smpteSt2094-10) and Dolby Vision (smpteSt2094-40) dynamic metadata are not currently supported, so will return false. We anticipate adding support for dynamic metadata in the future, so this API will allow developers to select the appropriate content for users with support.
Blink componentBlink>Media>Capabilities
TAG reviewAlready shipping by another UA. The now-closed Media Capabilities TAG review covered similar discussions: https://github.com/w3ctag/design-reviews/issues/218
TAG review statusNot applicable
RisksInteroperability and CompatibilityLow interop risk: Already shipping in Safari.
Gecko: Neutral (https://github.com/mozilla/standards-positions/issues/910)No signal would be more accurate.
It's unclear to me how this link indicates WebKit shipping this. Any particular phrase there you wanted to point at?
Flag name on chrome://flags
Finch feature name
MediaCapabilitiesDynamicRange
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1048045
Estimated milestones
Shipping on desktop 120
Shipping on Android 120
Shipping on WebView 120 Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
Spec changes have already been submitted since the feature is shipping in Safari.Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6640863931269120
Links to previous Intent discussions
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/jBzVLBz-Yk4/m/ORuQg2zAEwAJ
This intent message was generated by Chrome Platform Status.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwforrrpNE5RLc_OVa9uwa-63UX03VgijptNU5E8sVcD7g%40mail.gmail.com.
LGTM2
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-9LJRQwQscKevqnKDWtWkVkyaD%3Dgb7WK1RXRx2bvXn4A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPUDrwea0MaMQhSprLAPrj4sNJd8JySF2-RR%3D5Th8p5eSmAyAQ%40mail.gmail.com.