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.
The HLS parser used isLive_() in some places, which was equal to
presentationType_ != VOD, and in other places, checked presentationType_
directly.
In fact, isLive_()'s old formulation was checking for all dynamic
content (live & event types), so it should be called isDynamic_(). But
some usages of the old isLive_() actually only cared about live, and
should exclude event types.
This cleans up usage and clarifies each condition to either strictly
live (excluding VOD & event types) or all dynamic content (live & event,
excluding VOD). This is done both inside and outside the HLS parser.
This also makes one behavioral change to HLS event type streams. These
are now shown as "in progress" (dynamic, finite duration) instead of
"live" (dynamic, infinite duration).
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
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>
Adds a replacement for removed JSDoc checks from ESLint v9.
Additionally fixes lots of issues found in the JSDoc, such as:
- missing `@param`/`@return` annotations
- bad formatting
- params order
- param name in the same line as type definition (tried to disable it,
but it was causing other issues and we didn't have lots of places with
such formatting)
Minor fixes in code found by Closure Compiler after fixing JSDoc are
also included.
Migrates old config file to new flat config recommended by ESLint now.
Removes jsdoc rules, as they are not available anymore in ESLint.
Instead, if we want to have them, we should use `eslint-jsdoc-plugin`.
The autoLowLatencyMode config is removed because it's no longer
necessary. Now lowLatencyMode only enable low latency if the stream is
low latency.
A new method is added (configurationForLowLatency) to allow configure
the Low Latency config more easily
Related to
https://github.com/shaka-project/shaka-player/issues/7602#issuecomment-2479518970
From 23009-1:
The value of the minimum buffer time does not provide any instructions
to the client on how long
to buffer the media. The value however describes how much buffer a
client should have under
ideal network conditions. As such, MBT is not describing the burstiness
or jitter in the network,
it is describing the burstiness or jitter in the content encoding.
Together with the BW value, it is
a property of the content. Using the "leaky bucket" model, it is the
size of the bucket that makes
BW true, given the way the content is encoded