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
It seems all Tizen versions do not support smooth codec switch for now.
Additionally I removed webOS versions listed here, as they don't have
`SourceBuffer.changeType()` API anyway. They're available since Chrome
70, but webOS 5 uses Chrome 68.
And rephrased docs a bit.
For some niche cases where content is only available at resolutions
beyond the device's native resolution, and you are confident it can be
decoded and downscaled, this flag can allow playback when it would
otherwise fail.
This PR excludes the use of text segments when calculating the max
segment size.
This is due to Shaka using the max value between the buffer behind and
max segment size.
The max segment size of text segments can be a lot larger than video
segments.
This can cause the buffer behind to be extremely large and is a
particular problem for low
powered devices, which have memory constraints.
---------
Co-authored-by: Joey Parrish <joeyparrish@users.noreply.github.com>
With this config we will use the fullscreen API of the video element
itself if it is available in Vision OS. This is useful to be able to
access 3D experiences that are only allowed with the fullscreen of the
video element itself.
Previously, the PreloadManager would consider a preload "finished" after a few major files like the manifest had been preloaded. It would start prefetching some segments, but wouldn't wait on it to notify the developer.
This PR changes the PreloadManager so that
PreloadManager.waitForFinish won't return until the prefetched segments have finished loading.
Because of that, this also better surfaces errors thrown during segment prefetching, when preloading.
Issue #7520
Instead of checking for both lastSegmentReference and
lastInitSegmentReference, we shoould only check lastSegmentReference.
As of shaka-project/shaka-player#6929, init segment references aren't
cleared on clearBuffer, this onInitSegmentAppended not account for the
safe margin properly.
Previously we relied on an event triggered by the video itself which was
launched 4 to 60 times per second, which meant that we had an update (in
the worst case) of 250ms. Now we use a timer that is triggered every
25ms, which considerably reduces the delay.
This is important so as not to show anything from the original ad's
live.
With this change, no default flags are used. It seems that when a sample
has to use the default flags, in Safari, it can cause problems with MSS.
With HLS this does not happen.
Fixes https://github.com/shaka-project/shaka-player/issues/7509
Álvaro Velad Galván
Wojciech Tyczyński
theodab
vlazh
ncocaign
Shaka Bot
Joey Parrish
has992
Gary Katsevman
Iragne