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.
* test: Switch local Chrome, Edge, Firefox, and Safari launchers to WebDriver-based
This will enable WebDriver-based screenshot tests in local test runs.
* test: Add screenshots for Edge on Mac
The screenshot review page now has options to organize screenshots either by test or by platform. Previously, it was only by test. This is useful if you want to review many anomalous screenshots for a particular device.
Instead of pixel-wise comparison with a change threshold, we now use a
structural similarity (ssim) module to decide how much a screenshot
has changed. This better tolerates small rendering differences due to
differences in GPUs across machines.
The recent changes to TTML parsing, to not inherit regions,
inadvertently ended up breaking text alignment in situations
where a region with alignment was on the p or div above a span.
Previously, we only inherited the text and display alignment
from a region on leaf nodes... which was a problem, since we
also didn't apply any styles to text nodes.
Change-Id: I62ac155bc4310a5f7da52c10ca2dd434f8015c97
The proposed solution checks that all variants, apart from being checked in mediaCapabilities.decodingInfo, are also checked with MediaSource.isTypeSupported
There are some browser implementations that return a true mediaCapabilities.decodingInfo for unknown mimetypes and codecs and that can cause an application-level problem. For example, EDGE on Windows 10 returns true to HEVC even if you don't have the extension installed to support HEVC, instead MediaSource.isTypeSupported does take this into account
Fixes: #3860
This changes the TTML parser to not allow cue regions to be inherited
to the children of the element the region was originally assigned on,
except for the purposes of styles (colors, etc).
To allow regions on elements "above" the cues in TTML, such as the
<body> or <div> elements, this also changes the TTML parser to render
the full structure of the TTML file as a tree of cues. The end result
will be a single cue representing the <body>, with children
representing the <div> elements inside it, and those <divs> will have
children that represent the actual cues. Now that our text displayer
can intelligently update child cues as they enter or leave the display
window, this approach should be possible.
Closes#3850Closes#3741
Change-Id: Ia8d750daa06920610c04e9b26e29d2d304eaf8a9
Previously, we only cleared the buffer if the media state had
something buffered. This ensured that we did not pointlessly clear the
buffer when nothing was there.
However, this lead to problems if a seek was performed early during the
loading process, before the source buffer is initialized. During that
time, nothing is buffered, so we would not clear the buffer on a seek.
This lead to us accidentally fetching content from the beginning of the
presentation, rather than starting from the new clock time.
This changes the streaming engine to also clear the buffer if
mediaState.performingUpdate is true, to avoid that situation.
Closes#3299
The tb (top bitrate) property should honor bitrate/size ABR constraints and only report the top playable bitrate.
The tb property should only report the bandwidth for that segments type (audio, video, muxed).
Fix incorrect top bitrate CMCD reporting by:
Honoring the player's current bitrate/size ABR constraints.
Only reporting the bandwidth for that segments type (audio, video, muxed).
Fixes#3851
Co-authored-by: Dan Sparacio <daniel.sparacio@cbsinteractive.com>
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
If a rounding error in the DASH parser created an extra "phantom"
segment that extended just beyond the presentation duration, this was
causing a playback failure. Now StreamingEngine will tolerate these
small offsets and end playback at the correct time.
Fixes#3717
Change-Id: I00780a664aff4148b6b1046d8322a68da745de40
This makes the HLS parser honor more attributes for image tracks.
It also makes some changes to player.getImageTracks, so that the
returned track shows the size of a single thumbnail rather than the
entire sheet.
Closes#3840
Change-Id: I2ae096f455864201e08a85e29f0f02a3e06eb07f
In an internal Google build environment, the closure conformance proto
needed to be reformatted. Rather than do that each time the code is
synced to that environment, do it here in the upstream repo.
Change-Id: I3160a9a13df1c9b60ec1fed38aabe571b8431b42
If CMCD is disabled, there is no reason to use randomUUID. And if
tests or applications are running in plain HTTP URLs (what the web
platform calls an "insecure context"), then WebCrypto APIs like
randomUUID don't exist.
If a site or test is running in plain HTTP, and CMCD is disabled
(which is the default), there shouldn't be any need to install the
randomUUID polyfill (which should be optional).
This changes the CMCD utility to skip generating a session ID if CMCD
is disabled.
Change-Id: Iaf9c3fe94bc03c0f5ce46a082d18513ad05fb341