[Webkit-unassigned] [Bug 288080] New: [EME] CDMPrivate ignores encryptionScheme when checking supported audio/video capabilities

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=288080

            Bug ID: 288080
           Summary: [EME] CDMPrivate ignores encryptionScheme when
                    checking supported audio/video capabilities
           Product: WebKit
           Version: WebKit Local Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: bartosz.moczulski at youview.com

TL;DR: CDMPrivate accepts encryptionScheme parameter but ignores it completely

Current implementation of CDMPrivate follows W3C Editor's Draft 09 November 2016 of Encrypted Media Extensions spec. In the meanwhile a newer version was published on 07 August 2024 (a.k.a. EME v2), which added optional MediaKeySystemMediaCapability.encryptionScheme parameter. This parameter is ignored in CDMPrivate, in accordance with 2016 spec, however it already exists in MediaKeySystemMediaCapability.idl, can passed as requestMediaKeySystemAccess() argument, and is eventually available in CDMMediaCapability type down in CDMPrivate::getSupportedCapabilitiesForAudioVideoType(). Moreover, MockCMD and MockCMDFactory both allow setting supported encryption scheme which is even leveraged in LayoutTests, including WPT. Support for .encryptionScheme in WebKit was added already back in 2018 when it first appeared in draft EME spec (https://bugs.webkit.org/show_bug.cgi?id=190173), which confirms a desire for EME v2 support.

Despite the useful additions mentioned above there seems to be no way for CDMPrivate to signal if it supports particular scheme or not. Implementation of "Get Supported Capabilities for Audio/Video Type" still follows 2016 spec and ignores the scheme when it is explicitly passed. Other parameters are considered (e.g. robustness) but not the scheme. This is likely a minor oversight, considering that equivalent functionality exists and works in MockCDM.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20250220/4080aa40/attachment.htm>