On WebOS 3.0 we've noticed an issue in production, where TVs are slowly
starting to throw the following error after a user has watched at least
30+ episodes: `Code: 6006 Category: 6 Severity: 2 ["EME v0.1b key
error",{"errorCode":{"code":1,"systemCode":65535}},"0xffff"]` and can
only be resolved by clearing the app cache, or unplugging the TV.
Further investigation revealed that current workflow, where MSE is
destroyed before DRM Engine causes that old EME implementation is not
able to close session properly.
Few bugfixes to support DT Zenterio platform:
- Zenterio seems to have a problem with the EME onKeyStatus event payload (the key statuses map), where the map key ID comes in as empty. This is not correct based on the EME spec:
https://w3c.github.io/encrypted-media/#dom-mediakeysession-keystatuses
- Add polyfills that are used to fix issues with older webkits, same as for older safari browsers
We've tried to enable setting server certificates to optimize playback
start, but turned out that with our widevine certificate shaka was
throwing 6004 error. The issue is not reproducible starting from Tizen
5.5. The same certificate was working properly also on Chrome.
On PlayStation, cached `MediaKeySystemAccess` objects may corrupt after
several playbacks, and they are not able anymore to properly create
`MediaKeys` objects. To prevent it, clear the cache after each playback.
Make it configurable via `streaming.clearDecodingCache`.
This shim requires the latest version of the Chromecast WebDriver Server's receiver app, which can receive messages and proxy async access to `cast.__platform__`.
This is not needed since Chrome 61 and was not even registered in
uncompiled mode. (An audit of polyfills found this was the only one
missing from uncompiled mode.)
Although Chromecast natively supports TS content, it does not work in
all cases. In particular, we have some sample live streams where some TS
segments can be parsed by external tools as valid TS, but cause the
Chromecast to throw a parsing error.
We should reject TS content on Chromecast, and allow the builtin
transmuxer to take over parsing.
This also removes the use of `cast.__platform__.canDisplayType` to patch
MediaSource.isTypeSupported on Chromecast. Current versions of Shaka
Player are doing very rough filtering with isTypeSupported before
calling MediaCapabilities.decodingInfo. And our MediaCapabilities
polyfill calls `cast.__platform__.canDisplayType` directly, bypassing
any polyfill we might install on isTypeSupported. So there is no longer
any purpose to canDisplayType in isTypeSupported.
Closes#5278
`screen.orientation.unlock` is not defined on Safari, even though `screen.orientation` is.
This changes our orientation polyfill to add that method to `screen.orientation`.
Fixes#5437
Caches the results of MediaSource.isTypeSupported, which is slow on some platforms, to reduce the
number of calls needed. This is especially helpful on manifests with many similar variants (multiple languages, etc).
Data collected from 2 months of practical testing shows that this helps reduce the start lag by 40% on Chromecast, 15% on WebOS, and 12% on Tizen.
See https://github.com/shaka-project/shaka-player/issues/4726 for more
context.
This allows Cast devices to properly filter stream variants with a
resolution surpassing that of the device's capabilities.
We place the fix in the `MediaCapabilities` polyfill since it's intended
to be the right way to check for anything related to platform support.
HDR support checks will require `eotf=smpte2048`, as indicated in
https://github.com/shaka-project/shaka-player/issues/2813#issue-684874730.
Specifically, a `{hev|hvc}1.2` profile is only an *indication* of an HDR
transfer function, but *may* be a non-HDR 10-bit color stream.
In Cast, the platform can distinguish between the two by explicitly
providing the transfer function; it uses `smpte2048` (`"PQ"`) because
this is the "basis of HDR video formats..."
(https://en.wikipedia.org/wiki/Perceptual_quantizer).
This PR caches the result of `requestMediaKeySystemAccess` saving time
on subsequent calls.
It also makes the calls to `decodingInfo` synchronous. The reason for
this, is the result of testing on multiple devices that the behaviour of
`requestMediaKeySystemAccess` appears to be synchronous, making this
synchronous can save over a second on older TVs.
Closes#4574
We started using AbortController in HlsParser in 777c27ee, but that
change was made while the Tizen TV in our lab was offline. This restores
functionality to Tizen.
This polyfill uses getters, a feature of ES6 that the compiler won't
transpile into ES3, so this also changes the output language to ES5.
This should not be an issue, since ES5 has been well supported in all
browsers since IE10.
An internal build system failed to compile v4.3.0 due to the use of
static "this". This change fixes it.
Unfortunately, we are already running the latest public compiler
release, so there is no way we could have caught this on GitHub.
It appears that the problems we previously had with TS content
on Safari have been fixed. We no longer need the workaround where
we transmuxed TS on that platform.
Add support for HLS com.apple.streamingkeydelivery through MSE/EME implementation.
Close#3346
## Tests
Tested on:
- Mac 11.6 Safari 15.2
- iOS 15.2 Safari 15.2
- Mac 11.6 Chrome 96 (for potential regressions on Widevine keySystem)
| Mode | DRM API | TS | CMAF (mono-key and multi-keys)
|---|---|---|---|
| file | EME | ✅ | ✅ |
| file | Legacy-prefixed | ✅ | ✅ |
| media-source | EME | **mux-js**: `encrypted` never fired<br />**real MSE**: `encrypted` event received, but with incorrect `sinf` initData (*1) | ✅ |
| media-source | Legacy-prefixed | **mux-js**: `webkitneedkey` never fired<br/>**real MSE**: TBD | 🔴 fails to append media segment to SourceBuffer (init segment ok) `(video:4) – "failed fetch and append: code=3015"` |
## Support table
| Mode | DRM API | TS | CMAF (mono-key and multi-keys)
|---|---|---|---|
| file | EME | ✅ | ✅ |
| file | Legacy-prefixed | ✅ | ✅ |
| media-source | EME | 🚫 `4040: HLS_MSE_ENCRYPTED_MP2T_NOT_SUPPORTED` | ✅ |
| media-source | Legacy-prefixed | 🚫 `4041: HLS_MSE_ENCRYPTED_LEGACY_APPLE_MEDIA_KEYS_NOT_SUPPORTED` |🚫 `4041: HLS_MSE_ENCRYPTED_LEGACY_APPLE_MEDIA_KEYS_NOT_SUPPORTED` |
⚠️ Use EME APIs with multi-keys CMAF makes the video stalling with the audio continuing alone after a short time (~3 minutes in the stream, could be shorter, could be longer). Didn't find an explanation to that yet. I've observed the same behaviour with hls.js code so I don't think this is a player issue.
Revert "fix: Work around override of MediaCapabilities polyfill in Apple browsers (#3668)"
This reverts commit 31c0cd4b8c.
Fixes#3843 (usage of Shaka without polyfills)
Re-opens #3530 (MediaCapabilities polyfill not working on Safari)
Change-Id: Ib5aff1b38759e1a39200332f3f07d3d6bd3bd2e1
Wojciech Tyczyński
Álvaro Velad Galván
Joey Parrish
Mathieu Côté
theodab
Steve Anton
FernandoGarciaDiez
Casey Occhialini
Julian Domingo
Zhenghang Chen
Dave Nicholas
Matthias
Martin Stark
Álvaro Velad Galván
bcupac
Vincent Valot
Joey Parrish