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
This change:
- drops incompatible variants for XBOX before parsing codes and checking them against media capabilities API
- avoids redeclaring variables each time in the loop
Co-authored-by: Ivan Kohut <ivan.kohut@lamin.ar>
Preferred track selection was implemented differently for MSE and native
playback. In fact, native playback even had different implementations
for audio and text. It leads to inconsistencies during track selection,
i.e. if track language contains locale, but language preference not, on
MSE we're looking for closest locale and on src= we're making direct
string comparison which leads to different results.
To unify that, both MSE and native will now use
`StreamUtils.filterStreamsByLanguageAndRole()` to find matching track.
This method is designed to use on `shaka.extern.Stream` but luckily it
uses the very same fields as defined in `shaka.extern.Track` so we can
use it without major changes.
Moreover, using this more robust method also allows us to get rid of
double-selection workaround used so far. Observe that we were first
selecting track without preferred role and then with preferred role.
Shaka in most of places normalizes tracks' language code to be compliant with ISO 639-1 when possible. However, it does not do that all the time (i.e. normalization is missing in MSS parser) and there is no way to get value that has been explicitly set in a manifest. Moreover, documentation is misleading, as it claims that value is taken directly from a manifest.
Normalization should take place, specifically to easify PeriodCombiner algorithm and also to not break existing applications.
However, original value can be desired for some implementations.
This PR introduces new field to get original language value from the manifest.
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.
This configuration value allows the manifest variants to be filtered based on the HDR level of their video stream.
By default this is set to an auto-detect setting, which chooses PQ or SDR based on the device's detected capabilities.
This fixes legacy codec support by rewriting the codec metadata in the
Stream objects. After capability checking, the converted codec
information will be used.
Co-authored-by: Joey Parrish <joeyparrish@users.noreply.github.com>
Caches the results of MediaSource.isTypeSupported, which is slow on some platforms, to reduce the
number of calls needed. This is especially helpful on manifests with many similar variants (multiple languages, etc).
Data collected from 2 months of practical testing shows that this helps reduce the start lag by 40% on Chromecast, 15% on WebOS, and 12% on Tizen.
This PR caches the result of `requestMediaKeySystemAccess` saving time
on subsequent calls.
It also makes the calls to `decodingInfo` synchronous. The reason for
this, is the result of testing on multiple devices that the behaviour of
`requestMediaKeySystemAccess` appears to be synchronous, making this
synchronous can save over a second on older TVs.
Closes#4574
Tests for VP9 codec checks were failing on Firefox on our M1 Mac. This
addresses the issue by changing some default values that get used in a testing
environment, and another default value that is used in production.
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
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
theodab
Álvaro Velad Galván
Ivan
Dave Nicholas
Wojciech Tyczyński
lonebyte
/zɒ̃ge/
Fernando Neira
YuChao Liang
Zhenghang Chen
Joey Parrish
Casey Occhialini
Gaetan Hervouet
Albert Daurell
Álvaro Velad Galván
Joey Parrish
theRealRobG
Michelle Zhuo