`AbortController` polyfill attaches to the global object and it messes up with feature detection for projects that are using shaka. As it is not able to properly abort ongoing requests, it doesn't give much value.
This upgrades the compiler and reworks the AbortSignal polyfill to match
the new compiler externs for that class. This is important to make Shaka
Player compatible with the latest compilers in use inside Google.
Note that the Closure compiler is deprecated, so this should be our
final upgrade. We will some day move to TypeScript.
This does _not_ update the Closure library, because the latest version
causes failures we don't understand in the loading mechanism in
test/test/boot.js.
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.
Wojciech Tyczyński
Agajan J.
Joey Parrish
Álvaro Velad Galván
Wojciech Tyczyński
Mathieu Côté
theodab
Steve Anton
FernandoGarciaDiez
Casey Occhialini
Julian Domingo
Zhenghang Chen
Dave Nicholas
Matthias
Martin Stark
Álvaro Velad Galván
bcupac