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.
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
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
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
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
Embedded CEA-608 captions don't work on multi period live DASH DAI streams after new periods appear in the manifest because commas are appended the streams originalId string, which disrupts some stream matching code in text_engine.js
The problem has been resolved by preventing makeTextStreamsForClosedCaptions() from altering the PeriodCombiner.textStreams_ array.
Fixes#3783
Fixes#3729
If the video variant stream contains information about `hdr`, then we now use that to provide a value for `transferFunction`, when constructing the [`VideoConfiguration`](https://w3c.github.io/media-capabilities/#videoconfiguration) object used to get decoding info from media capabilities API.
The following applies:
```js
switch (video.hdr) {
case 'SDR':
mediaDecodingConfig.video.transferFunction = 'srgb';
break;
case 'PQ':
mediaDecodingConfig.video.transferFunction = 'pq';
break;
case 'HLG':
mediaDecodingConfig.video.transferFunction = 'hlg';
break;
}
```
Previously, many events were being defined with a data dictionary
that used variable-type keys (e.g. {key: value}). This worked fine
in uncompiled mode, but in compiled mode it lead to those properties
being obfuscated.
This changes the FakeEvent constructor to take a map rather than an
object, so the compiler will force the keys to be strings.
Closes#3710
Change-Id: I67b1a391540a5ee21f0aaf940ae054d26f4c10a4
Add support for including Common Media Client Data (CMCD) in outgoing requests.
Fixes#3619
NOTE: The following fields have not been implemented: rtp, nrr, nor, dl
Co-authored-by: Dan Sparacio <daniel.sparacio@cbsinteractive.com>
While working on the issues tagged below, I needed to explicitly debug
the many possible error cases in the XML parser. Now, each one is a
unique return with its own error log.
The order of checks has also been changed so that, for example, a
parser error at the root of the document isn't misunderstood to be a
mismatch of the root element's tag name.
Issue #3636
Issue #3627
Change-Id: I75ded6eaab2137892b93b5530023e0b39156f1ae
Only create the segment index for a stream when the stream is chosen.
When switching to another stream, release the segment index of the
original stream, and create the segment index of the new stream during
the next update.
Change-Id: I4d8a64e0e52d3e7edb71d402a97ab1dcd7f561dd
When unboxing TKHD, the reader read int64 as trackId instead of int32. Thus unable to find matching timescale when doing TFHD unboxing. Therefore when parsing MDAT, the default timescale will be used which is 90000. All CC timestamps will then be incorrect.
This also fixes "Shaka Error MEDIA.VIDEO_ERROR (3,,PIPELINE_ERROR_DECODE: Failed to parse H.264 stream)" error when playing DASH MP4 H.264 streams with CEA-608 CC embedded. It's likely that the VDA bundled in Chromium-based browsers have already included EPB detection & prevention. If we let the player to remove the byte, VDA will complain about stream conformance.
Closes#3502
This refactors the storage mechanism so that the method that
attaches a segment to the manifest is be a stateless async method,
and no longer needs to be in the same session as the method that
stored the manifest.
This is the end of phase one of the work towards allowing Shaka
Player to use background fetch to store assets offline.
This change will allow a service worker to store the segments as
they are downloaded, without having to keep the Shaka Player
instance alive.
Issue #879
Change-Id: I6a3545c57bacaf7229fe8c32669e88c6cc4e4138
If it's srcEquals, the 'type' element of the input object when querying mediaCapabilities should be 'file'. Otherwise it should be 'media-source' .
Issue: #3530
This changes the order that things happen when the offline storage
mechanism stores a manifest, so that the manifest is made and the
segments are downloaded in separate steps.
This is in preparation for adding background fetch support.
Issue #879
Change-Id: I4451db839b654f6134f06a58c240a9ca98d31a4e
When playing multiperiod content, we should not require thumbnails to
be present in every period. This fixes this case and adds a
regression test.
Closes#3383
Change-Id: I4403a1b8670cffcc46de32470e2d830dc199c9f4
We filter out duplicate streams for all other types, so we should do
this for images, as well.
This also updates all PeriodCombiner test cases to include the
imageStreams property.
Issue #3383
Change-Id: I63355f85d4e12bd25c1cadce29a040d17c4e7d61
Matching image streams across periods was not working correctly with
multiple streams per period. Matching was done on MIME type only,
meaning there was no way to differentiate multiple streams.
Resolution is a better signal, so this uses the same logic as for
video resolution in thumbnail resolution matching.
This also adds extra error logs that helped track down the issue, and
fixes some comment typos.
Issue #3383
Change-Id: I067de59c222a165d58926646f53fa61862853377
Added support for efficient preprocessing of DASH manifest after they have been parsed into an XMLDocument
This is configured with the new manifest.dash.manifestPreprocessor setting.
This is need to efficiently repair manifests that are not compatible with Shaka Player.
Closes#3339
This site has an easy search function for all Microsoft error codes,
which is better than the two other links.
Change-Id: I4a2d67e3412c43200e38b7abf3086b6b14de778b
Currently a full chain comparison is done, but in video and audio codecs, you may want H.265/VP9 with no profile preference, with this change it is possible to do this.
Examples:
'hvc1' instead of 'hvc1.1.2.L123.80' and 'hvc1.1.2.L153.80'
'vp09' instead of 'vp09.00.40.08.00.02.02.02.00'
When concatenating trick mode streams, at the moment, the period
combiner assumes that the streams already have segment indexes.
However, we never actually make those segment indexes in the period
combiner, causing it to break in that situation.
This modifies the period combiner to also create the segment index
of a video stream's trick mode stream when creating the main segment
index of the stream.
Fixes#3423
Change-Id: I4ca6f14879b7a5d3dae735e931d2fb1f8d1673be
Adding the "preferredVideoCodecs" and "preferredAudioCodecs"
configuration, so that the application can set their own preferences
when choosing a codec.
Issue: #2179
Change-Id: Ib56aec10613dda9b7dce8e465c5f1d81540c34fd
An async process handles the appending of partial segments for LL-DASH. This fixes the caller to wait on the results, so that partial segments are always appended in order.
Fixes#3404
We'll allow users to configure the decoding attributes they prefer when
choosing codecs through the configuration. The attributes include
'smooth', 'powerEfficient' and 'bandwidth'.
For example, if the user configures the field as ['smooth',
'powerEfficient'], we'll filter the variants and keep the smooth ones
first, and if we have more than one available variants, we'll filter and
keep the power efficient variants.
After that, we choose the codecs with lowest bandwidth if we have
multiple codecs available.
Issue #1391
Change-Id: Ief3f6d8ff98fabff5ec99bb0365cdc6a36d2ab2d
Previously, we faked a single "video/mp4" variant for all src=
playbacks. This resulted in a failure when someone tried to use src=
with encrypted WebM and ClearKey. The correct MIME type and codec
needs to be sent to DrmEngine so that it can send the correct metadata
to EME.
Closes#3366
Change-Id: If4f12e0a800d07e84caaae0f6322f549a90b2a95
We'll allow users to configure key system priorities through the
'drm.preferredKeySystems' configuration.
Edge now supports both Widevine and PlayReady, and users should be
able to configure the priorities of the key systems.
If no key system is preferred, or no preferred key systems is valid,
we'll fall back to the original behavior of choosing the first key
system with configured license server url in the manifest.
Example:
player.configure('drm.preferredKeySystems', [
'com.widevine.alpha',
'com.microsoft.playready',
]);
If both Widevine and Playready have a license server and are
supported, the config sets Widevine as the first choice, and
PlayReady as the second.
Issue #3002
Change-Id: Idb881ef4921259bb3e1879cd8ec2bb6966d6580d