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.
This uses very explicit ref names for both source and destination, to
fix this error during branch creation:
> TAG=v4.12.0
> BRANCH=$(echo "$TAG" | sed -e 's/\.0$/.x/')
> git push origin HEAD:"$BRANCH"
>
> error: The destination you provided is not a full refname (i.e.,
> starting with "refs/"). We tried to guess what you meant by:
>
> - Looking for a ref that matches 'v4.12.x' on the remote side.
> - Checking if the <src> being pushed ('HEAD')
> is a ref in "refs/{heads,tags}/". If so we add a corresponding
> refs/{heads,tags}/ prefix on the remote side.
>
> Neither worked, so we gave up. You must fully qualify the ref.
> hint: The <src> part of the refspec is a commit object.
> hint: Did you mean to create a new branch by pushing to
> hint: 'HEAD:refs/heads/v4.12.x'?
> error: failed to push some refs to
'https://github.com/shaka-project/shaka-player'
> Error: Process completed with exit code 1.
To report commit status on a PR, the head commit must be used, not the
merge of that head back into the target (e.g. into main).
I would prefer to make status reporting special, so that we can run
tests and other operations against the merge (for more realistic results
and to avoid test failures that only show up after a merge). But this is
the quickest way for me to fix this critical feedback.
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.
Álvaro Velad Galván
Wojciech Tyczyński
theodab
vlazh
ncocaign
Joey Parrish
Shaka Bot
has992