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
Currently, if the interstitial lasts 30 and we have a stream that lasts
31 seconds, we would go back to live after the interstitial, but with 1
extra second of latency. This PR solves this by limiting the play range
to 30.
Related to https://github.com/shaka-project/shaka-player/pull/7480
Currently, if the interstitial lasts 30 and we have a stream that lasts
31 seconds, we would go back to live after the interstitial, but with 1
extra second of latency. This PR solves this by limiting the play range
to 30.
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
fix(DASH): Live DASH allows segment overlap in the updated manifest for
first new segments to avoid creating GAP with ms inaccurate manifest vs
Segment duration and start time
Fixes https://github.com/shaka-project/shaka-player/issues/7397
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.
Recent tests have shown that although `SourceBuffer.changeType()` exists on PS5, calling it when switching between AAC and EC3 always throws an exception. Disable smooth codec switch on that platform together with PS4.
In #7368, we get stuck in a loop loading forever. This regression was
introduced in v4.4.0 and affects all v4.4, v4.5, v4.6, v4.7, and v4.8
releases, as well as v4.9.0-28, v4.9.2-caf1, v4.10.0-20, and v4.11.0-6.
The loop is composed of these elements:
1. an error that triggers disabling a stream
2. an error that doesn't resolve itself over time
3. an error that is slow enough to trigger that the first streams get
re-enabled
4. VOD content that doesn't change while we sit in the loop
5. enough streams to avoid exhausting them during the cycle
Only `TIMEOUT` errors can trigger this bug AFAICT, so we should exclude
those from the logic to disable streams. Note also that live streaming
already retries indefinitely by default, and that normal ABR logic will
change streams for us if we timeout due to a lack of bandwidth.
Disabling streams on `TIMEOUT` was suggested initially in #4764, but was
not a requirement of the OP. It was added out of caution in #4769, but
not really vetted. Because it was not ever explicitly needed, excluding
it is not a regression.
Closes#7368
Álvaro Velad Galván
Wojciech Tyczyński
Iragne
Gregory McGarry
Gregory McGarry
Joey Parrish