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
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
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;
}
```
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
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'
Adding the "preferredVideoCodecs" and "preferredAudioCodecs"
configuration, so that the application can set their own preferences
when choosing a codec.
Issue: #2179
Change-Id: Ib56aec10613dda9b7dce8e465c5f1d81540c34fd
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
MediaCapabilities supports 'vp09...' codecs, but not 'vp9'. Translate
vp9 codec strings into 'vp09...', to allow such content to play with
mediaCapabilities enabled.
Change-Id: Iff7ddae379efb8a9f0766c89a62b85a325f81e93
When we use decodingInfo() with the drmInfo of the variants to get media
keys, the decodingInfo result can tell us whether the variant's DRM is
supported by the platform. Thus, filterManifestByDrm_() is no longer
needed with MediaCapabilities enabled.
Issue #1391Closes#3334
Change-Id: I34fbb3e11877f02cae1d435e9dbf274ce0e691dc
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
If we have a multiplexd stream with audio and video, the video
codecs are a combined string containing both audio and video codecs.
Before sending the request to decodingInfo(), we should check which
codec is audio and which one is video.
This is a follow-up of commit 966a756.
Issue #1391
Change-Id: Ic9b1c5972a99f63a715c74ae068b85f43efac447
In StreamUtils, add a MediaCapabilitiesKeySystemConfiguration
for each key system for the encrypted variant passed to the
decodingInfo API, to get the mediaKeySystemAccess as a part of
the decodingInfo results.
We create a list of mediaDecodingConfigurations for each variant,
and call decodingInfo() with each mediaDecodingConfiguration to
get the mediaKeySystemAccess.
Eventually, we'll use the mediaKeySystemAccess from the
decodingInfo results to replace the call of
navigator.requestMediaKeySystemAccess() in DrmEngine. That will be
in the next CL.
Also, adding MediaCapabilties polyfill with mediaKeysSystemAccess.
Issue #1391
Change-Id: Ied4a27dd8a1ade43209bcf07f21f0c9b31c2693c
If we have a multiplexd content with audio and video, we combine
the audio and video codecs in the manifest parser.
For example, a multiplexed stream would be with:
mimeType="video/mp4", codecs="avc1.64001e,mp4a.40.2".
When sending the request to MediaCapabilities.decodingInfo(), we
need to have the config for both audio and video to get the result
as "supported".
The video config would be:
contentType='video/mp4, codecs="avc1.64001e"'.
The audio config would be:
contentType='audio/mp4, codecs="mp4a.40.2"'.
Issue #1391
Change-Id: I74a8580c07228e9600dc40c611ebd5d34f8cd7ee
Previously, we fill in the variants' drmInfos with the drm
configurations of |clearKeys|, |servers| and |advanced| during
initializing the DrmEngine, before we query the media keys.
Now we need to call |MediaCapabilities.decodingInfo()| to get the
mediaKeySystemAccess of the variants after the DrmEngine is
created and configured, and the drm values are filled in for the
variants, and before |DrmEngine.queryMediaKey_()|.
The steps would be:
0. StreamUtils.setDecodingInfo() should not be called before
DrmEngine is initialized and configured.
1. Create and configure DrmEngine.
2. Fill in drm values for the variants with configurations.
3. Call StreamUtils.setDecodingInfo() to get the decodingInfo of
the variants.
4. Use the decodingInfo results to set up the Drm mediaKeys in
DrmEngine.
5. When StreamUtils.filterManifest() is called, we can reuse the
decodingInfo results instead of calling decodingInfo again.
Previously we call filterManifest() when parsing the manifest, to
filter out the unsupported streams.
Now decodingInfo can tell us if a variant is supported and its
MediaKeys at once. When initializing the DrmEngine, we get the
decodingInfo results of the variants, and only use the supported
streams to set up the MediaKeys. After that, we filter the manifest
right after DrmEngine is initialized.
Thus, we can skip filterManifest() in manifest parsers.
Using decodingInfo to get media keys will be in the next CL.
Issue #1391
Change-Id: Ieb401a1e4dfbcc958f7a14fa96df546237b0f446
When querying MediaCapabilities.decodingInfo(), if the video width
or height is not present, set 1 as default. Linux Firefox would
claim the variant is unsupported via decodingInfo() if the values
are falsy.
Issue #1391
Change-Id: Idc27e6869a1276585a0ca35bd380e1b7ad1db242
If navigator.mediaCapabilties is not supported by the browser, use
MediaSource.isTypeSupported to check if the stream is supported.
Issue #1391
Change-Id: Iee0c7e339add2a07028ed14a03df14e4d36a203e
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
Before this change, our codec choice only worked when all codecs had the same resolutions available.
When one codec had a different set of resolutions available, we might end up choosing the wrong one. This is because our choice was based on the average bandwidth of all resolutions for that codec. So a "better" codec with higher resolutions available would also end up having a higher average bitrate, and would be avoided.
This fixes the issue by only considering the resolutions that all codecs have in common, then taking the average bitrate among those to choose a codec.
StreamUtils.filterManifest() filters the manifest with four steps:
1. Filter out the variants unsupported by the platform
2. Filter out the variants unsupported by DRM
3. Filter out the variants uncompatible with the current variant
4. Filter out unsupported text streams.
We re-filter the manifest after the streams are chosen, and we only
need to filter out the variants uncompatible with the current
variant. Skip step 1,2,4 in StreamUtils.filterManifest(), to
avoid duplicate calls to MediaCapabilities.decodingInfo().
Issue #1391
Change-Id: Ia792f94d4ac3d93267741ef63db0872f30189fda
Player.filterManifest() does two things:
1. Filter the manifest with Drm, codecs and currentVariant's
compatibility in StreamUtil.
2. Filter the manifest with PlayerConfiguration.restrictions.
In applyConfig_(), only the restrictions config affects filtering
the manifests. We don't need to call StreamUtils.filterManifest().
2. Make the filterManifest function async.
Issue #1391
Change-Id: I2fba9cabb3f3a3e89f5d990c4eeb19cc74924de9
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 .
This enables the eslint rule requiring jsdocs on all class
declarations, function declarations, and methods.
Unfortunately, there are two problems with this:
1. We don't use class _declarations_, we use class _expressions_,
which are not covered by this rule. So it does not enforce jsdoc at
the class level.
2. We tend to document a class at the class-level, rather than at the
constructor. But a constructor counts as a method for eslint, so it
requires docs on the constructor. There is no way to configure it to
make an exception for trivial constructors.
So for all trivial (no-argument) constructors, we add empty jsdocs:
/** */
constructor() {
This was quicker and easier than setting up some alternative plugin in
eslint to make an exception for us.
The good news is that this rule caught several undocumented parameters
and places where the jsdoc comment was malformed. So fixing those
also improves the compiler's ability to enforce types.
Change-Id: Icbc46ed690c94e53d354648a883119524f8fca45
This pertains to #2648 (although this is a new feature, not a replacement) and #1404. A CEA-708 decoder that follows the CEA-708-E standard, decodes closed caption data from User Data Registered by Rec. ITU-T T.35 SEI messages, and returns them as cues in Shaka's internal cue format. Furthermore, this pull request fixes and cements some of the logic surrounding CEA-608 and CEA-708 tag parsing on the Dash Manifest Parser.
Format:
Similar to the CEA-608 decoder, cues are emitted in Shaka's internal format (lib/text/cue.js). This decoder makes use of nested cues. The top level cue is always a blank cue with no text, and each nested cue inside it contains text, as well as a specific style, or linebreak cues to facilitate line breaks. This also allows for inline style (color, italics, underline) changes.
Details:
- ASCII (G0), Latin-1 (G1), and CEA-708 specific charsets (G2 and G3) all supported.
- Underlines, colors, and Italics supported, set as a property on each nested cue.
- Positioning of text is supported. (Exception: In CEA-708 the default positioning is left, in this decoder it is centered.)
- Positioning of windows not supported, but relevant fields that could be used to support this are extracted and left as a TODO.
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
This is only defined on Stream, not Variant. This bug has was
introduced in PR #2332 and the v2.5.8 release and affects v2.5.8 -
v2.5.10. The corresponding feature (frameRate restrictions) has
actually never worked.
This was caught by a compiler upgrade which is still in progress.
Change-Id: I0409d9be8d3f6eb0794775ca29f28b98208bab4f
This removes periods from the internal manifest structure and cleans
up code and tests accordingly. This leaves us unable to play
multi-period DASH & offline streams until the main period-flattening
algorithm is completed in shaka.util.Periods.
Three test cases have been disabled for the moment.
Multi-period playback will be restored in a smaller, more focused
follow-up commit, with disabled tests re-enabled.
Issue #1339 (flatten periods)
Issue #1698 (rapid period transitions issue)
Issue #856 (audio change causes bitrate change)
Closes#892 (refactor StreamingEngine)
Change-Id: I0cbf3b56bfdb51add15229df323b902f0b2e643a
When playing an asset, the player will first choose a codec, based
on the lowest average bandwidth.
However, the storage mechanism did not have any such filtering;
instead, all it did (if using the default track filtering plugin) was
pick the middle-bandwidth audio track. This lead to it sometimes making
different codec decisions than the player would have.
This CL breaks the codec filtering logic out into a helper function, and
calls it both for playback and storage.
It also adds headers comments to some functions in the demo page.
Closes#2390
Change-Id: I09f1a24753121afd0e7500577c0f64ccffe5a4d1
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
Joey Parrish
Álvaro Velad Galván
Joey Parrish
Theodore Abshire
theRealRobG
Michelle Zhuo
Denis Seleznev
Muhammad Haris
Jacob Trimble