shaka-project / eme-encryption-scheme-polyfill Goto Github PK

I can't use eme-encryption-scheme-polyfill v. 2.0.4 in KaiOS devices (KaiOS v. 2.5.x)

dist/eme-encryption-scheme-polyfill.js
SyntaxError: missing = in const declaration [eme-encryption-scheme-polyfill.js:8:1151]

or

index.js
SyntaxError: missing : after property id [index.js:71:15]

This issue is based on next fact:
KaiOS v. 2.5.x is based on Gecko 48
Gecko 48 is unsupported async/awat functions

Please, make version without async/await

Feedback on the spec has led to cbcs-recommended being renamed to cbcs-1-9. The polyfill must be updated as well, and a new version published.

When compiling with --jscomp_error '*', there are compiler errors. This doesn't occur in the Shaka Player environment because the settings there are not as strict.

You didn't change the copyright placeholder at the bottom of the LICENSE file.

Expected

Copyright notice with year and name filled

Actual

Copyright placeholder
Copyright [yyyy] [name of copyright owner]

There is a bug in the minified bundle (but not in the source) where requestMediaKeySystemAccess sometimes resolves to undefined.

The code in demo/ doesn't get pushed on a GitHub Actions workflow, so the gh-pages branch is badly out of date. We should build an automated workflow for this to make sure it's updated on push to main.

Can both EME & MC polyfills scripts be loaded on CDNJS, JSdeliver or another CDN? It would be nice, because our node-modules folder isn't available to the public. so NPMing these files locally doesn't help us for that matter.

The EME part of the polyfill checks to make sure it isn't installed twice, but the MCap polyfill doesn't. This leads to infinite recursion when the polyfill tries to call the original, but ends up calling itself.

The MediaCapabilities API mirrors parts of the EME spec in many ways, including the MediaKeySystemMediaCapability object where this encryptionScheme field was added.

We should consider polyfilling the equivalent feature in MediaCapabilities, too. It's likely that most of the code would be shared.

See w3c/media-capabilities#100
Tagging @chcunningham

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
4.2.1

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from main?
Yes, via https://nightly-dot-shaka-player-demo.appspot.com/demo/

Are you using the demo app or your own custom app?
Reproducible in both

If custom app, can you reproduce the issue using our demo app?
Yes

What browser and OS are you using?
Windows 10 - Firefox 104.0.2
macOS 10.15.7 - Firefox 104.0.2

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?
N/A

What configuration are you using? What is the output of player.getConfiguration()?
N/A

What did you do?
I probed Firefox for support of Widevine CBCS after applying the Shaka Polyfills (shaka.polyfill.installAll()). The behavior is the same if in a code file or in the dev tools console.

const config = [
  {
    label: 'cbcs support',
    audioCapabilities: [
      {
        contentType: `audio/mp4; codecs="mp4a.40.2"`,
        encryptionScheme: 'cbcs',
        robustness: 'SW_SECURE_CRYPTO',
      },
    ],
    videoCapabilities: [
      {
        contentType: `video/mp4;codecs="avc1.42E01E"`,
        encryptionScheme: 'cbcs',
        robustness: 'SW_SECURE_CRYPTO',
      },
    ],
  },
];

await navigator.requestMediaKeySystemAccess('com.widevine.alpha', config);

What did you expect to happen?
I expected Firefox to report that this config object was a supported configuration. Running the same code block in Firefox's dev tools console on a page without the polyfills applied indicates that it is a supported configuration. It's worth noting that Chrome/Edge do work after the polyfill.

What actually happened?
An exception is thrown indicating that it is not a supported configuration:
Uncaught (in promise) NotSupportedError: Unsupported keySystem or supportedConfigurations.

I made a Stack Blitz showing that when ran with Firefox, the native navigator.requestMediaKeySystemAccess indicates support, while after applying the polyfill, it is not supported.
https://shaka-player-eme-polyfill-cbcs-issue.stackblitz.io/
https://stackblitz.com/edit/shaka-player-eme-polyfill-cbcs-issue?file=index.js&view=editor
(Note that their editor's preview iframe doesn't provide permissions for encrypted-media, so it must be opened in a new tab)

We're undergoing an effort to remove any OS version detection in favor of feature detection as the User Agent is becoming unreliable. We're detecting CBCS support with similar code to the example in the Stack Blitz, which is working with the exception of Firefox. The current workaround is to get a reference to the native navigator.requestMediaKeySystemAccess prior to the polyfill being applied, calling that reference, then falling back to the post-polyfilled navigator.requestMediaKeySystemAccess if the native version doesn't indicate success.

Something has gone wrong with transpilation since dependency upgrades in 761dece, and now the last three releases all contain ES6 code. This causes issues Shaka Player tests to fail on Tizen with:

Safari 3.0 (Tizen 3.0) ERROR
  An error was thrown in afterAll
  Uncaught SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode

The export code at the bottom of the module seems to be broken. It seems it was not tested thoroughly enough in its final form.

Hi,

Using the polyfill recently we faced an issue with PlayReady DRM playback on a specific version of the legacy MS Edge browser (42.17134.1098.0) that playready DRM is not supported.

After debugging it was observed that the issue occurs in hasEncryptionScheme check. When there is no video or audio capabilities it will throw an error
https://github.com/google/eme-encryption-scheme-polyfill/blob/96a56700b293fbe2a801a19706b3f8708bc16b68/index.js#L482-L494

Microsoft Edge 42.17134.1098.0 has the issue with incorrect capabilities, so we see the error

This MR will resolve this issue #14

See #62