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
A previous PR, #5950, added support for variants that contain multiple
different codecs.
It was supposed to also add support for variants with multiple
mimeTypes, but that part didn't work correctly. This reworks a lot of
#5950 and #6047, to change how they handle such complicated variants.
This has the side-effect of allowing the stream utils to differentiate
between content that has multiple codecs because of type changes, and
content that has multiple codecs because of being muxed video+audio.
Fixes#6010
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
The state engine mechanism, designed for the player class, was
over-engineered. The structure of the class makes debugging player
errors unnecessarily annoying, by obfuscating the code-path the error
followed, and in general
has created a significant amount of technical debt.
This changes the player to use an async-await setup for the top-level
operations, laying things out much more cleanly
and linearly.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
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.
Now that DRM info is only parsed after playback has begun, the manifest
parser needs to communicate back to the other components that new DRM
info is available after lazy-loading a playlist.
Closes#4622
In some cases, indexedDB.open() can end up calling neither callback.
When this does happen, according to my initial testing, it happens
consistently when reloading the page, so it's not a one-off fluke but
presumably some sort of implementation or browser install problem. If
that does happen, the init promise of the storage muxer hangs forever,
potentially blocking other operations from happening. This adds a
timeout to the invocation of indexedDB.open(), after which the operation
fails with a new error.
fix: Fix HLS dynamic to static transition
- Keep maxSegmentEndTime_ updated in PresentationTimeline by calling
notifySegments on each HLS playlist update, so that the seek range
doesn't revert to the original playlist size when it becomes
static.
- Wait to change the presentation type to VOD until after _all_
active playlists have an ENDLIST tag, to avoid missing the final
segments in one type or the other.
- Stop updating the playlists after transition to VOD.
- Update the MSE duration at exactly the same time as we transition
to VOD, to avoid a loophole where the UI knows it's VOD, but
doesn't have any way to get the correct duration. Previously, this
state would persist until the final segments were appended.
Closes#4431
Xbox One tests have been failing often for some time now, so it went
unnoticed that offline was not working. It seems that IndexedDB is
not working properly on Xbox, and the platform throws `UnknownError`.
This restricts offline so that it is not triggered on Xbox One, and
this also fixes the filtering of our offline tests to respect the
offline storage muxer's support method.
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
If a storage operation is aborted (via API, not via closing the page),
this will now be cleaned up from the database. More work is needed to
find and remove orphaned segments in the database.
Related to #4166 and follow-up to PR #4176.
By waiting for all segment data to be written to the database before updating the manifest, we can speed up offline storage in the foreground by ~87%.
Closes#4166