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
This reverts commit 6667ea5edf and
reimplements it using a fallback to an arbitrary media element when
there isn't one yet.
This also adds a regression test that would have caught the issue
sooner.
Closes#2326
Change-Id: I44573ae551db51f788d7c97b9680dfd45adee0a0
This reflects changes in Google's policy on JavaScript license
headers, which should be smaller to avoid increasing the size of the
binary unnecessarily.
This also updates the company name from "Google, Inc" to "Google LLC".
Change-Id: I3f8b9ed3700b6351f43173d50c94d35c333e82b4
This is a fully automated change. The linter will fail because the
extra indentation caused line-length errors. These won't be fixed
automatically. They are fixed in a follow-up to make this one fully
automated.
Change-Id: I4d8cf9c998985add2bcd24a81c8d65495668c4f3
Instead of triggering src= based on 'video/mp4' MIME types, ask the
browser what it can support using video.canPlayType().
Querying canPlayType() also allows us to detect src= support for
native HLS in Safari.
The original version of this change also added a complete fallback
system to detect MIME types based on common file extensions and
fetch MIME types via HEAD request when necessary, but the load graph
system does not yet allow us to make async decisions about destination
node. So this async MIME detection is commented out for now.
Closes#816 (src= single file playback)
Issue #997 (native HLS in Safari)
Change-Id: If1930ca4fd5710481a925d63fb312d9a5b15fec8
Now iOS is supported for HLS through src=, so isBrowserSupported
needs to reflect that. This makes MediaSource optional for any
browser with src= playback of HLS.
This also fixes probeSupport() to reflect the capabilities of non-MSE
platforms such as iOS, which is critical for our demo app to be able
to show the correct set of playable assets.
Issue #997Closes#1857
Change-Id: Ic6e18587db90fff2b097a2038c16cc928e2b9438
This CL creates the "loaded with src=" node and its initial
implementation. Adding this node required some changed to the routing
logic as a new destination was created.
We will use src= when given mp4 content or media source is unavailable.
We detect mp4 content via the mimeType in |load| and/or the file
extension. When media source is not available on a platform, we fall
back to using src=. To do this, we check if media source is available
whenever |load| is called, and will route to the src= branch if media
source is not found.
To avoid pre-initializing media source (when it is not available) we
modify the |initializeMediaSource| flag in |attach| and |unload| when
media source is not available.
Doing this showed that we had inconsistent behaviour between |attach|
and |unload|. |attach| would default to initializing media source
whereas |unload| would not. This has been fixed.
Issue #816
Issue #997
Change-Id: I00599832b49c9079e273e65a4b827fee736479cc
We have a utility to test what platform we are running on. It looks
like the chromecast tests were not making use of it.
Change-Id: I0eddbf1fe1aa2c1707947a3c268672a3808ec4dc
To make it easier to know where we are check what platform something is
(normally a sign of a work-around), this change isolates the logic to
make the check into functions.
Now looking for uses of |shaka.util.Platform| should show when we are
using platform-specific logic.
Change-Id: Ief49837c503e951f7138ec08a83355fe1c46db88
Vincent Valot
Casey Occhialini
Joey Parrish
Álvaro Velad Galván
Oren Me
Jacob Trimble
Peter Nycander
LanaIV
Sandra Lokshina
Aaron Vaage