The build system is updated to generate two CSS outputs:
A legacy stylesheet (.css) where CSS custom properties are flattened
using postcss-custom-properties for compatibility with older browsers. A
modern stylesheet (.modern.css) that preserves CSS custom properties for
modern browsers.
Both outputs are generated from the same LESS source and processed
through Autoprefixer and cssnano, ensuring consistent styling while
supporting different browser capabilities. This enables a gradual
migration path between legacy and modern UI styling without breaking
existing consumers.
Close https://github.com/shaka-project/shaka-player/issues/10145
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
- Remove duplicate entry in the 5.0 list
- Rename the 5.1 list as 6.0 (named for the version in which something
is removed, with a note about the deprecation version)
- Reindent the set of related config changes
Noticed while preparing CAF for 5.0 compatibility
I went ahead and implemented the full structured preference system that
was discussed in
https://github.com/shaka-project/shaka-player/issues/1591.
Instead of just expanding languages to arrays, I replaced all 14
individual preference fields with 3 structured arrays:
```tsx
preferredAudio (language, role, label, channelCount, codec, spatialAudio)
preferredText (language, role, format, forced)
preferredVideo (label, role, codec, hdrLevel, layout)
```
Each array entry works as an AND filter - so you can say things like "I
want Korean with 5.1 surround, but if not available, English is fine
too":
```tsx
player.configure('preferredAudio', [
{language: 'ko', channelCount: 6},
{language: 'ko'},
{language: 'en'},
]);
```
<img width="1728" height="965" alt="image"
src="https://github.com/user-attachments/assets/7b088150-139b-475e-bdba-5bc77dd4e524"
/>
**Config** - Replaced the 14 individual fields with 3 arrays of typed
preference objects (AudioPreference, TextPreference, VideoPreference).
The old fields still work at runtime with a deprecation warning, so
existing apps won't break immediately.
**Demo** - The demo config UI now shows inline expandable preference
lists instead of flat text inputs. You can add/remove entries and
configure each field per entry. URL hash serialization was updated to
use JSON format, with legacy param fallbacks preserved.
This change is feat! because it no longer allows modifying the
`currentTime` of the mediaElement in the streaming event. With this
change, only `updateStartTime` can be called to update the time, and the
user should always use the `canupdatestarttime` event instead of
`streaming` event when they need it.
Fixes https://github.com/shaka-project/shaka-player/issues/9661
We previously deprecated setTextTrackVisibility, this PR removes it from
the public API.
This'll allow us to further strip down the distinction between selecting
a text track and toggling its visibility internally. Atleast we'll no
longer have users rely on this API from v5 onwards.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
`airplay` button uses WebKit's proprietary API. In newer versions, this
has been replaced by the RemotePlayback API, which is available in
`remote` button.
More info: https://caniuse.com/mdn-api_remoteplayback
---------
Co-authored-by: Theodore Abshire <TheodoreAbshire@Gmail.com>
- The following buttons are registered: play_pause, mute, fullscreen,
rewind, fast_forward, picture_in_picture, remote, loop, skip_next,
skip_previous
- SmallPlayButton and BigPlayButton are removed
- The following buttons are used by default on mobile: skip_previous,
play_pause, skip_next
The previous description suggested that Shaka Player was a DASH-only
player.
In reality, Shaka Player supports multiple adaptive streaming formats,
including DASH and HLS.
This change updates the documentation to accurately reflect the player's
capabilities and align it with the README.
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.
This change allows to execute request filter on every request attempt.
It can be useful i.e. to update credentials when first request fails.
New field `attempt` has been added to `shaka.extern.Request` which
informs which attempt is currently ongoing. This is needed to not do the
unnecessary work multiple times.
HTTP 401 Unauthorized and 403 Forbidden are no longer treated as
immediate critical errors, as tokens can be updated during retry
process.