2030484 - Netflix claims no HDR support on HDR capable laptop

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P3)

Description

[Jim Mathies [:jimm]]

On an HDR capable Intel Arc laptop Netflix debug console claims Media Capabilities reports no HDR support. HDR is clearly working on other sites like youtube.

Comment 1

[Jim Mathies [:jimm]]

Attachment: media-capabilities-test.html

Comment 2

[Jim Mathies [:jimm]]

Attachment: media-capabilities-test.html

Adds an export results as text option.

Comment 3

[Jim Mathies [:jimm]]

Attachment: mcapi test results (Arc laptop)

Comment 4

[Jim Mathies [:jimm]]

Looks like Widevine content isn't reported as power efficient? The video codec in use by Netflix is AV1, and I have hardware for that.

Comment 5

[Jim Mathies [:jimm]]

Attachment: bug-2030484-triage.md

I think if we have hardware to do the decoding, we should return true for power efficient.

Comment 6

[Jim Mathies [:jimm]]

Hey Alastor. I think the initial assumption was fine (non-efficient) but I'd like to update that. Do you foresee any negative side effects to switching the value to check for hardware decoding?

Comment 7

[Alastor Wu [:alwu]]

Attachment: Media Capabilities HDR Test.html

Comment 8

[Alastor Wu [:alwu]]

Attachment: Bug 2030484 - Part 1: Detect powerEfficient by checking real decoder for software-DRM key systems.

The DRM decodingInfo path previously determined powerEfficient solely from
IsHardwareDecryptionSupported(), which returns false for software-DRM systems
like Widevine L3 or ClearKey — causing powerEfficient to always be false for
those cases, regardless of whether the underlying video decoder is hardware-
accelerated.

Extract a CheckVideoDecodingInfo() static helper that creates and initialises
a platform video decoder and queries IsHardwareAccelerated(). When the DRM
path detects a software key system and a video configuration is present, it
chains CheckVideoDecodingInfo() to obtain the correct powerEfficient value.
Hardware-DRM paths and cases without a video track continue to derive
powerEfficient from IsHardwareDecryptionSupported() as before.

Comment 9

[Alastor Wu [:alwu]]

Attachment: Bug 2030484 - Part 2: Add RFP guard to DRM decodingInfo path.

The non-DRM path already suppressed powerEfficient when resisting fingerprinting.
The DRM path had no such guard.

For hardware DRM (robustness "3000", "HW_SECURE_ALL", "HW_SECURE_DECODE"),
return supported=false/smooth=false/powerEfficient=false since hardware TEE
presence is a strong fingerprinting signal.

For software DRM under RFP, keep supported/smooth from the key system check
but force powerEfficient=false to suppress hardware decode capability.

Comment 10

[Alastor Wu [:alwu]]

Attachment: Bug 2030484 - Part 3: Tests for DRM powerEfficient and RFP behavior.

• Add GTest (TestMediaCapabilities) with HardwareCapableMockDecoder and
  AutoForcePDM to verify CheckVideoDecodingInfo returns the correct
  powerEfficient value for hardware/software decoders and under RFP.
• Add mochitest (test_mediacapabilities_drm_power_efficient.html) to verify
  that software-DRM (ClearKey) decodingInfo exposes a boolean powerEfficient
  and that RFP forces it to false.
• Add mochitest (test_mediacapabilities_drm_hardware_encryption.html) to verify
  that hardware-DRM (PlayReady via WMF media engine) reports powerEfficient=true
  and that RFP suppresses the result entirely; this test must be a separate file
  in mochitest_media_engine.toml because it requires the WMF media engine prefs
  that are not available in other mochitest suites.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/73c5d174941b
https://hg.mozilla.org/integration/autoland/rev/4d0d2b0f54b2
Part 1: Detect powerEfficient by checking real decoder for software-DRM key systems. r=media-playback-reviewers,jolin
https://github.com/mozilla-firefox/firefox/commit/a776f22e74d8
https://hg.mozilla.org/integration/autoland/rev/05b5fdb2ee9f
Part 2: Add RFP guard to DRM decodingInfo path. r=media-playback-reviewers,jolin
https://github.com/mozilla-firefox/firefox/commit/687704e08115
https://hg.mozilla.org/integration/autoland/rev/8544e0c54b0b
Part 3: Tests for DRM powerEfficient and RFP behavior. r=media-playback-reviewers,jolin
https://github.com/mozilla-firefox/firefox/commit/2e9e030e1568
https://hg.mozilla.org/integration/autoland/rev/bda11e53a190
apply code formatting via Lando

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/c2282b444f18
https://hg.mozilla.org/integration/autoland/rev/1b4e80314055
Revert "Bug 2030484: apply code formatting via Lando" for causing build bustages at RefPtr.h

Comment 13

[rperta]

Backed out for causing build bustages at RefPtr.h
Backout link
Push with failures
Failure log(s)

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/996ee103c983
https://hg.mozilla.org/integration/autoland/rev/3f7f577cbcf4
Part 1: Detect powerEfficient by checking real decoder for software-DRM key systems. r=media-playback-reviewers,jolin
https://github.com/mozilla-firefox/firefox/commit/0926933690e2
https://hg.mozilla.org/integration/autoland/rev/83a1bdefc7fa
Part 2: Add RFP guard to DRM decodingInfo path. r=media-playback-reviewers,jolin
https://github.com/mozilla-firefox/firefox/commit/75f1a473ac14
https://hg.mozilla.org/integration/autoland/rev/eb2678c0676a
Part 3: Tests for DRM powerEfficient and RFP behavior. r=media-playback-reviewers,jolin
https://github.com/mozilla-firefox/firefox/commit/0e109d94fd4f
https://hg.mozilla.org/integration/autoland/rev/cac63b0856ce
apply code formatting via Lando

Comment 15

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/3f7f577cbcf4
https://hg.mozilla.org/mozilla-central/rev/83a1bdefc7fa
https://hg.mozilla.org/mozilla-central/rev/eb2678c0676a
https://hg.mozilla.org/mozilla-central/rev/cac63b0856ce

Comment 16

[Alastor Wu [:alwu]]

Attachment: Media Capabilities SDR/HDR Test.html