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.
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
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
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>
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
Unfortunately, modern browsers do not support any CSS property that
directly maps to tts:textOutline. However, the non-standard (but still
commonly implemented) -webkit-text-stroke-width and
-webkit-text-stroke-color properties, when used together, can
replicate the functionality of tts:textOutline, with the exception of
the optional blur radius.
Closes#3612
Change-Id: I863d09fc447765646bd405c59b0b20960362a594
When an external subtitle track is added and you are using DAI, the external track does not take into account the ads that the video has, so this PR makes this internally take into account when generating the external track.
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
This adds two new player events, 'downloadheadersreceived' and
'downloadfailed', to allow users to measure network performance
in greater detail.
Issue #3533
Change-Id: I33a3bd411d815e926d4bea2184e8d3ea69e2bb49
Thumbnail segments may be structured for a certain grid size and
duration, but the segment references may have their duration truncated
due to the end of a period or the end of the presentation. This was
causing us to calculate the wrong duration for those individual
thumbnails, and therefore return the wrong
thumbnail.
We also did not have any way to indicate to an application how long a
thumbnail should be shown.
This fixes the duration calculation by retaining the original,
untruncated duration in SegmentReference. This also exposes startTime
and duration information on the Thumbnail object, so that applications
know when/where and how long to show a given thumbnail.
Closes#3517
Change-Id: I84aa7705a19691fc6ae68eee9944fecbd7067fe0
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
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
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
Some internal Google tools that are meant to find XSS vulnerabilities
complain about some parts of Shaka Player. In particular:
- Using setAttribute instead of a src property
- Using setAttribute with a variable key
- Using URL.createObjectURL
This resolves these internal XSS checks. As far as I can tell, there
are no serious XSS risks from any of these, as the complaining checks
are meant to catch things that could be executed as scripts. None of
these user-controlled inputs are treated as such, but it seems that
the compiler involved can't tell that.
This goes part of the way toward solving #3378.
Change-Id: I302b9eb56a374854c9b8525b21960ef64fd386f1
In DrmEngine, previously we created MediaKeySystemConfiguration for the
variants, and called navigator.requestMediaKeySystemAccess() to get the
mediaKeySystemAccess, and set up MediaKeys.
Now we can use the mediaKeySystemAccess from the decodingInfo results of
the variants directly to set up MediaKeys.
Issue #1391
Change-Id: Id93a5e2fed7f6827317ae11644967185fc0cffbd
Make the DASH keySystems configurable, so that any developer could chose to opt-in for recommendation based on DASH DRM UUID.
Example:
player.configure({
dash: {
keySystemsByURI: {
'urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95': 'com.microsoft.playready.recommendation',
}
}
});
The developers should be able to set the config to use
MediaCapabilities.
If set to true, we'll use mediaCapabilities.decodingInfo() to
get the variants' decodingInfo.
If set to false, we'll fallback to use
MediaSource.isTypeSupported() and
navigator.requestMediaKeyAccess().
Issue #1391
Change-Id: I1acbfb12780291e998d56a91156ae2c47a87c7ae
In StreamUtils, use MediaCapabilities.decodingInfo() instead of
MediaSource.isTypeSupported() to check if the stream is supported.
MediaCapabilities.decodingInfo() takes an
MediaDecodingConfiguration object as input, and returns a Promise
with a MediaCapabilitiesInfo object. The returned object tells us
whether decoding the media is supported, smooth, and
powerefficient.
Steps:
1. Create a MediaDecodingConfiguration object for each variant as
the input.
2. Query the decodingInfo API with the config.
3. Get the 'supported' info from the decodingInfo result, to know
whether the variant is supported.
Issue #1391
Change-Id: I8fc2d3ec6a9868f38269d550d35f45c298faae98
Sets the type of the google.ima.settings object extern to
`google.ima.ImaSdkSettings` to avoid duplicating the defined methods.
Also adds the setVpaidMode method and VpaidMode enum to the
google.ima.ImaSdkSettings class extern.
When downloading content for storage, it's useful to know how much storage space
will be needed before storing. This is extremely important for mobile devices
that have limited space. See google/shaka-player-embedded#167.
Use the info in the manifest and make HEAD requests to determine the
size of the content we're downloading.
Add a downloadSizeCallback that will be called with the size once we know it.
The callback determine if the content can be downloaded due to its estimated
size.
Closes#3049 .
In our isTypeSupported polyfill for Cast, we use the HEVC profile ("hevc1.2") as
an indication of the HDR transfer function, which is not always accurate.
The polyfill should stop assuming that 10-bit color HEVC means HDR, and remove
the extra eotf="smpte2084" parameter. Instead, the manifest parser should
extract HDR profile information from the DASH manifest and pass that info along
through the Stream object.
Issue #3116 .