This PR introduces a Web Worker for transmuxing resolving
https://github.com/shaka-project/shaka-player/issues/1735
- The worker bundle is compiled separately
- The build output is embedded as a string constant and then wrapped in
a Blob to create an inline Worker URL (HLS.js does this very similarly)
- `TransmuxerProxy` is created wrapping a real transmuxer, but no worker
is started yet - on the first `transmux()` call, it checks if the device
supports worker transmuxing
- For each transmux() call: the buffer is copied, then zero-copy
transferred to the worker. A PublicPromise is stored under a reqId with
a timeout timer, and the main thread awaits it.
- The worker transmuxes and posts back transmuxed (or error). The shared
message listener routes the response to the right proxy instance by id,
which resolves the promise and cancels the timer.
- When the last proxy instance is destroyed, the worker is terminated
and the blob URL is revoked.
loaded inside the worker.
- Some low-end devices have been excluded since their Worker support is
questionable
There most likely is a better way to do this - please let me know
```js
player.addTextTrackAsync("...", "en", "subtitles");
const textTracks = player.getTextTracks();
// Text tracks has a length of 1, but immediately selecting it would fail.
player.selectTextTrack(textTracks[0]);
```
Text track preference runs after we manually selected a text track, in
`src=` we'd wait for `loadeddata` before figuring out which initial text
track should be selected. The fix is to bail out when we already have a
text track active when trying to select an initial text track.
HLS SUPPLEMENTAL-CODECS (e.g. Dolby Vision dvh1) creates duplicate
variant tags with different codecs but the same media playlist URI. Due
to lazy-loading, only one variant gets its drmInfos populated via
createSegmentIndex(). The other variant remains with empty drmInfos and
is treated as unencrypted by getDecodingConfigs_().
In the preferredKeySystems loop, the filter rejected these unencrypted
configs (undefined !== preferredKeySystem), leaving the variant with no
decodingInfo and causing it to be dropped.
Fix: allow unencrypted configs (!keySystem) to pass through, matching
the pattern already used in the second (fallback) loop.
Propagating drmInfos in HLS parser would be more correct but is complex
because stream duplication happens at the tag level with separate cache
keys (URI + codecs) in createStreamInfoFromVariantTags_.
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.
In chooseCodecsAndFilterManifest, there was a real lack of comments. So
first and foremost, this adds comments.
Second, group IDs for audio & video streams were made by concatenating
various properties, but without delimiters, so there may have been a
possibility for collisions. This adds delimiters in the group ID
construction.
Third, streams are already sorted by bandwidth before we start grouping
them, so the grouping code for audio & video doesn't need to check
`stream.bandwidth < previousStream.bandwidth`. This should always be
true.
Fourth, the video stream sorting conditions were too nested and hard to
read. This flattens those out in a way that makes them easier to
understand.
Finally, because we're always only allowing one codec per group,
skipping a stream due to `!supportsSmoothSwitch` makes no sense. We're
only ever adding streams to our filter list when their codecs match
what's already in the group. So the check on `supportsSmoothSwitch` is
removed.
This fixes the `active` property on text tracks returned by
`Player#getTextTracks()` still being `true` after calling
`Player#selectTextTrack(null)` when the load mode is `SRC_EQUALS`, this
was also causing the text track selector to still show the text track as
selected after clicking `Off`.
The text track selector UI issue is only a problem on the main branch
(v5.0) as #9048 hasn't been released in any of the release branches yet.
The changes in this PR add support for non-square pixels, e.g. SAR value
of 2:1 (or any other) to the Resolution Selection Menu.
Currently, some contents can be falsely detected as portrait video by
getResolutionLabel_, e.g. a 960x1080p content with a SAR value of 2:1
would be detected as portrait and have its width and height swapped by
getResolutionLabel_. However it is a landscape content: the horizontal
pixels would be stretched to display a horizontal video.
Pick a multi DRM asset, set `preferredKeySystems` to prefer PlayReady
over Widevine and run on a device that does not support PlayReady (eg;
Chrome).
A `REQUESTED_KEY_SYSTEM_CONFIG_UNAVAILABLE` is thrown.
This is due to the logic in `getDecodingInfosForVariants` where we bail
out on probing other decodingInfos when we found a prefered one, but we
didn't check whether it was supported or not. As a result, Widevine was
never checked and PlayReady was left marked as unsupported.
`queryMediaKeys()` was able to work both with variants and key system
configs. The latter option was needed only for `initForRemoval()`
method. By removing it we are able to make the logic more easy to
follow.
Additionally, compiled build is now 2 KB smaller.
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>
This changes the `drm.advanced.videoRobustness` and `audioRobustness`
config options from a string to an array of strings. Internally, in the
drm engine, this gets expanded into an array of `DrmInfos` which have
those values as strings.
Best way to review this change is with whitespace turned off in the diff
options.
---------
Co-authored-by: Wojciech Tyczyński <tykus160@gmail.com>
Ivan
Matthias Van Parijs
dong-heun
Wojciech Tyczyński
Álvaro Velad Galván
Joey Parrish
absidue
Romualdas Paskevicius
Gary Katsevman
vlazh
stefangehrer