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= .
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.
Some platforms seem to ignore EME if the first init segment appended
at the MSE level does not indicate encryption. To work around this,
we will detect such platforms, and if EME is set up, we will insert
fake encryption metadata into the init segment to convince the
platform to be ready to decrypt.
Closes#2759
Change-Id: Iccf6b8589cf9265ac9bef0d083f4a72f6f2dd628
We only just gained the ability to test on new Chromium-based Edge
(google/generic-webdriver-server@475ec746), so we did not previously
know which workarounds were specific to legacy Edge. Now all but one
of those workarounds has been limited to legacy Edge only, and will
not be applied to new Chromium-based Edge.
Change-Id: I70b7480ccb61064b796c3d9b41bbe95cabfdf850
This fixes all the license headers in the main library, which corrects
the appearance of the main license in the compiled output.
It seems that the `!` in the header forces the compiler to keep it in
the output. I believe older compiler releases did this purely based
on `@license`.
Issue #2638
Change-Id: I7f0e918caad10c9af689c9d07672b7fe9be7b2f3
querySelector isn't available in Shaka Player Embedded. Since we only
use it to find nodes with a specific tag name, we can usually use
getElementsByTagName.
Issue google/shaka-player-embedded#113
Change-Id: Ia225e5d1f7598b13bd05db868fe2ea566dca4493
`'webkitneedkey'` events are fired with the same `event.initData` for the video and audio tracks, and a new session is needed for each.
Closes#813 (duplicate sessions required on Tizen)
Closes#2447 (polyfills broken on Tizen)
Closes#2448 (PlayReady broken on Tizen)
For Video Futur platform, like for Tizen, key IDs should not be
transformed to big-endian UUIDs, it causes `4012
RESTRICTIONS_CANNOT_BE_MET` error.
Issue #2189
Because we have some polyfills and blacklists that are specific to
Safari and iOS, we need to detect specific versions of Safari and iOS.
The existing detection of Safari/iOS versions was in multiple places,
and did not account for non-Safari browsers on iOS. This refactor
allows us to correctly detect iOS Chrome, and fixes a fatal exception
thrown in the MediaSource polyfill for all non-Safari browsers on iOS.
Change-Id: Ic88dc1a4c82087054cd4791dbf295b7ea2aeab09
Wojciech Tyczyński
Álvaro Velad Galván
Joey Parrish
MichaelSweden
Viktor Vasylkovskyi
Vasanthavanan Devarajan
Will Harris
Dave Nicholas
Agajan J
Julian Domingo
Subhan Ahmed
bcupac
Matthias
Álvaro Velad Galván
Vincent Valot
Casey Occhialini
Joey Parrish
Oren Me
Jacob Trimble
Peter Nycander
LanaIV