This is the first step in a series of efforts to simplify how we handle
text tracks internally.
The purpose of `autoShowText` has always felt a bit unclear. It was
originally added because Shaka wasn't flexible enough when choosing an
initial text track. I don't think we should try to handle every possible
scenario for initial text track selection. Instead, we should respect
`config.preferredTextLanguage` and let the application decide if it
needs more granular control. Apps can already do this easily with
`getTextTracks()` and `selectTextTrack(track)`.
Ultimately, I'd like to move toward a simpler API where either a text
track is selected or none is. If nothing is selected, we shouldn't
stream any text at all.
See https://github.com/shaka-project/shaka-player/issues/9301 for extra
context.
The goal is to simplify and abstract feature logic detection. Currently
lots of places depend on various calls to `shaka.util.Platform` and
mainteinance of this is hard & not easy to read.
By introducing device API ideally rest of the player logic would look
into device features instead of directly checking platform. Additionally
we can more easily cache needed values, so we won't have to parse user
agent several times anymore.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
On Xbox One, Media Source claims it's not able to play Dolby Vision codecs. However, when it's created using their AVC/HEVC equivalent, it plays fine DV content.
With the addition of the changeType API for MediaSource, it is theoretically possible for a variant to change between multiple codecs for a given buffer, over the course of playback.
This adds support for the DASH player to stitch together periods which have such multi-codec variants, but only as a last resort. For example, if one period only has audio in aac, and another period only has opus audio, the player will now stitch those periods together as one, but if there is a throughline that does not involve changing codecs it will go for that instead.
Closes#5961
Propagate `preferredKeySystems` config to `getDecodingInfosForVariants()` method.
By doing that, shaka can only ask for `MediaKeySystemAccess` objects that will be used during playback.
If any preferred key system is available, player will stop requesting for MKSA.
If none of preferred key systems is available, player will try to get MKSA for any existing configuration, as usual.
When a `NETWORK HTTP_ERROR` is thrown, we'll temporarily disable the variant for `shaka.extern.Restrictions.maxDisabledTime` seconds (default will be 30 seconds).
Closes#4121Closes#1542
This change fixes tests on Chromecast by loading tests later in the process. Test scripts are now dynamically inserted by boot.js, rather than loaded by Karma. The bootstrapping code then awaits the completion of that before starting the Karma frameworks (Jasmine) to run the tests.
This also removes the use of goog.provide/goog.require in tests and test utils. We don't need to load test utils or library sources dynamically in each test, and this gives us more explicit control over script loading and ordering.
Closes#4094
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
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
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
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.
This corrects/normalizes license headers in misc. files, such as
config files, docs, build tools, tests, and externs. This does not
affect the compiled output, and is only done for consistency.
Issue #2638
Change-Id: I9d8da2de55243b08d7df2b743aac73c6f15e858a
We used to alias static utility methods by assigning the method itself
to a local variable. This is not allowed by the new Closure Compiler
release that we are adopting, and for good reason.
The old compiler did not understand the use of "this" in static
methods, but the new one does. And it turns out that when we start
using "this" in static methods (see #2532), aliasing the method itself
can break everything.
When you refer to "this" in a static method, it refers to the class.
This is really useful in utility classes that have private static
methods they use to perform common tasks. However, just as it ruins
the value of "this" to alias an instance method, the same is true of
an ES6 class's static method.
The fix is to always alias the class instead of the method. The new
compiler will simply not let us get away with the old way any more, so
regressions after this are unlikely.
Issue #2528 (compiler upgrade)
Issue #2532 (static "this")
Change-Id: Id800d466e639c7cbcf4aa6fbb05114c772a2229f
Matthias Van Parijs
Álvaro Velad Galván
Wojciech Tyczyński
vlazh
theodab
Dave Nicholas
lonebyte
Wojciech Tyczyński
/zɒ̃ge/
Albert Daurell
Joey Parrish
Joey Parrish
theRealRobG
Álvaro Velad Galván
Michelle Zhuo
Denis Seleznev