It seems all Tizen versions do not support smooth codec switch for now.
Additionally I removed webOS versions listed here, as they don't have
`SourceBuffer.changeType()` API anyway. They're available since Chrome
70, but webOS 5 uses Chrome 68.
And rephrased docs a bit.
With this config we will use the fullscreen API of the video element
itself if it is available in Vision OS. This is useful to be able to
access 3D experiences that are only allowed with the fullscreen of the
video element itself.
Recent tests have shown that although `SourceBuffer.changeType()` exists on PS5, calling it when switching between AAC and EC3 always throws an exception. Disable smooth codec switch on that platform together with PS4.
Previously, we added a 1 second "cooldown" period between attempts to
perform a corrective seek.
This was for the benefit of old v1 Chromecasts, which found the process
of seeking so slow that they would sometimes get stuck in an infinite
loop trying to start a presentation.
However, that cooldown period was causing issues in some situations
during seeking, so this PR removes the restriction on everything but
pre-Android Chromecast devices.
Fixes#4393Fixes#5202
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
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.
In some cases, Fuchsia Chromecast tests will fail with the error: "The
play() request was interrupted because video-only background media was
paused to save power."
This resolves the issue by ensuring tests run un-muted on that platform,
based on this Chrome code, which indicates the "paused to save power"
logic does not activate when sound is playing:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/media/web_media_player_impl.cc;l=3535;drc=d23075f3
This also fixes two places in our tests where the `createVideoElement()`
was bypassed. This should always be used, because it is a central place
to apply workarounds such as this.
This makes it easier to debug hardware resolution issues through the
support page, which can now show hardware resolution. To show the
support page on Chromecast devices, use chromecast-webdriver-cli.
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__`.
Adding EC-3 test case for codec switching integration suite, as some
platforms, i.e. Tizen 3 do not support Opus
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
webOS platforms don't contain OS version explicitly in user agent,
instead they signal it via chrome version. This PR fixes webOS 4 & 5
methods and unifies all webOS check methods.
Xbox One was being misdetected as Chrome, causing some mistakes in which
tests are skipped.
This does not appear to affect the library itself, since isChrome() and
chromeVersion() are only used in tests currently.
In order to get the playback working, I am excluding VirginMedia device
from isApple() platform test, otherwise it incorrectly fails at
isBrowserSupported().
Fixes#4676
Co-authored-by: Casey Occhialini <1508707+littlespex@users.noreply.github.com>
The `isBrowserSupported` function in the `utils/player.js` fails if the Safari Version is < 13. However, this check doesn't work for Amazon Fire TV devices. Even though they have a `Version/4.0` in the user agent string, the browser still supports all other requirements to support playback with Shaka Player.
Here are a couple of examples of the different FireTV device user agents:
Fire TV Stick 4K - 1st Gen:
Mozilla/5.0 (Linux; Android 7.1.2; AFTMM Build/NS6289; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/100.0.4896.127 Mobile Safari/537.36
Fire TV Stick - 3rd Gen:
Mozilla/5.0 (Linux; Android 9; AFTSSS Build/PS7285.2877N; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/96.0.4664.92 Mobile Safari/537.36
The fix involves identifying the Amazon Fire TV device based on the parameters described [in the Amazon Fire TV docs](https://developer.amazon.com/docs/fire-tv/identify-amazon-fire-tv-devices.html) and disabling the Safari version check for these devices.
The EOS set-top box, built by Liberty Global, has WebKit embedded and should play MSE (+ EME) compatible streams. With the latest version (`4`), streams didn't play. When attaching a debugger to the box, I noticed that the srcEquals node is selected.
The EOS box identifies itself as an Apple device, which is wrong. `Platform.isApple()` returns true, therefore `shouldUseSrcEquals_` (in combination with `config_.streaming.useNativeHlsOnSafari`) returns true as-well. The native playback check is not holding it from selecting srcEquals (https://github.com/shaka-project/shaka-player/blob/main/lib/player.js#L1273) as EOS supports MPEG-DASH natively (but not in combination with DRM, as far as I know). Nonetheless, MSE is preferred.
In Tizen 2/3 and WebOS 3.x there is no support for SourceBuffer.mode=sequence so as a result of change #2337, it necessary disable support for the HLS parser so that the user can at least use the native one with src= .