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
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.
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
Since our tests already test VAST and VMAP this is no longer necessary,
and the tests were disabled because the IMA library is buggy in Tizen.
On the other hand, removing the IMA load reduces the test loading time.
This deduplicates a platform support check that was run in
player_integration.js, and declares the pre-existing central support map
in an extern so we can clean up its use.
This stops a DRM integration test from timing out on FirefoxWindows. It
still gets skipped, though, due to a failing Widevine check, so there
will be follow-on work for that.
Issue #7449
The promise for DOM auto setup tests doesn't guarantee that load() is
complete, only that we started it. So checking video duration causes
flake, in particular on slow devices like Tizen. Instead, check for the
player to have an asset URI.
In 4425dca2, we broke auto-loading content with `<source>` tags or
`src=` in the UI, such that we tried to load content before we had
attached a video element. That was almost a year ago. Oops!
This also adds an appropriate unit test.
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
Needed for #5022
This PR does not enable AirPlay on MSE yet, but moves shaka from using
`src` attribute to `source` tags. With this change we will be able to
enable it more easily, as `src` and `source` should not be used
together.
In #7345, we disabled Jasmine's global error handler. However, jasmine
still tries to call this. So instead of replacing it with null, replace
it with a stub.
Also add comments about why we are able to do this and still handle
global errors in our own way.
Previously, there were situations where, when handling `trackschanged` events, the manifest would not yet have been
copied from the preload manager to the player. This would prevent developers from properly handling those events.
This PR changes the order of operations slightly, such that the manifest is copied over earlier.
If we fail certain actions during test setup, we should log those
unconditionally through Karma's dump() function, and not just when
browser console logs are enabled with --enable-logging.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
We get strange uncaught errors sometimes on Cast devices. These are
unreadable "script error" events that have nothing to do with our tests
(see https://sentry.io/answers/script-error/), and we intend to ignore
them.
However, our existing logic to ignore those is not sufficient, because
in addition to our own error handler (via
window.addEventListener("error")), Jasmine has its own unconditional
error handler (via window.onerror).
To take complete control over how these are handled, we need to remove
Jasmine's handler.
Jasmine's handler is installed at the top of its execute() function, so
our top-level beforeAll() is the best place to remove it.
On some real Cast devices, you can't delete window.cast. This is fine,
and shouldn't cause the test to fail. If this happens, skip the test
instead. The test, which mocks everything including the platform
detection and the Cast API, is still valid on platforms where we can get
away with those mocks.
Álvaro Velad Galván
vlazh
ncocaign
Joey Parrish
theodab
Gregory McGarry
Gregory McGarry
Iragne
Wojciech Tyczyński
/zɒ̃ge/