Previously, if the presentation delay was not specified either by the
manifest or by configuration, we defaulted to 1.5 * minBufferTime. That
approach worked for most content, but in some cases it could cause live
streams to start out with a seekRangeEnd that was before the live edge.
This would lead to a brief pause in the beginning of the presentation,
while the live edge caught up.
This changes the DASH parser to use the segmentAvailabilityDuration if
it is lower than 1.5 * minBufferTime, which fixes that issue.
It also changes how that part of the code to be formatted, in order to
hopefully make the increasingly-complex logic for determining the
presentation delay more clear.
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.
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
Based on the work of @gmcgarry Thank you very much!
Currently the codec adds supplemental codecs to the list of allCodecs
and has an implicit priority order to select a codec. Support for the
codec is tested with MediaSource.isTypeSupported().
There are multiple issues with this approach:
- the priority is implicit
- MediaSource.isTypeSupported() decision is effectively overriding
platform-specific MediaCapabilities logic
- MediaSource.isTypeSupported() is frequently wrong depending on whether
the content is encrypted
This patch duplicates the variant with each supplemental codec and
defers codec priority and codec selection until after
MediaCapabilities.decodingInfo().
This fixes support for DolbyVision Profile 8, which is otherwise broken
because the chromium browsers always return false from
MediaSource.isTypeSupported(), and DolbyVision is commonly only
available in a secure hardware decode pipeline.
Note: Safari does not have this problem since it supports Dolby Vision
in clear
---------
Co-authored-by: Wojciech Tyczyński <tykus160@gmail.com>
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
The PR is solving playback error in a Multi period manifest when the
start time is not 0.
Additionally, solving the error code 3015 due to the clear of the buffer
during the playback.
Fixes https://github.com/shaka-project/shaka-player/issues/7401
This piggybacks on the media quality observer to also check whether the
audio track changed and the change was in label, language, or role.
Currently, this new event is triggered is `observeQualityChanges` is
set. This could be moved to a separate config.
I do play to add a test or two to the integration tests.
For verifying the role/label, I was testing against this public test
stream
https://demo.unified-streaming.com/k8s/features/stable/video/tears-of-steel/tears-of-steel-desc-aud.ism/.mpd
(though, it does seem to error out every so often). There might be other
test streams. Angel One is a great one for language.
Also, something that we noticed, but won't be part of this PR. The
timing of this event is likely incorrect if the track was switched and
safeMargin was set. We have some changes for this locally that we can
PR, but there are some issues we found around devices for it, so, it
isn't a straightforward change.