This fixes all the license headers in the main library, which corrects
the appearance of the main license in the compiled output.
It seems that the `!` in the header forces the compiler to keep it in
the output. I believe older compiler releases did this purely based
on `@license`.
Issue #2638
Change-Id: I7f0e918caad10c9af689c9d07672b7fe9be7b2f3
This removes periods from the internal manifest structure and cleans
up code and tests accordingly. This leaves us unable to play
multi-period DASH & offline streams until the main period-flattening
algorithm is completed in shaka.util.Periods.
Three test cases have been disabled for the moment.
Multi-period playback will be restored in a smaller, more focused
follow-up commit, with disabled tests re-enabled.
Issue #1339 (flatten periods)
Issue #1698 (rapid period transitions issue)
Issue #856 (audio change causes bitrate change)
Closes#892 (refactor StreamingEngine)
Change-Id: I0cbf3b56bfdb51add15229df323b902f0b2e643a
This reflects changes in Google's policy on JavaScript license
headers, which should be smaller to avoid increasing the size of the
binary unnecessarily.
This also updates the company name from "Google, Inc" to "Google LLC".
Change-Id: I3f8b9ed3700b6351f43173d50c94d35c333e82b4
During startup, there was a race between the video element's ready
state and seeking to the requested start position. If the video
became ready before the seek to the start position, there could
briefly be 0 tracks. Reproducing this required a first period start
> 0 and a start position > 0, such that a lookup of the "current"
period during this brief window would return null.
The problem was more likely to be seen on Chromecast, where the time
between load() and the completion of a seek was much larger than on
desktops.
The bug was caused by Playhead, which both seeks to the start position
and manages the concept of "current time", returning the start
position during startup and the video element's position thereafter.
This fixes the race, making sure that startup is not considered
complete by Playhead until the initial seek is over. This adds an
appropriate regression test and simulated content that can reproduce
the conditions in the original bug report.
Fixes b/138941217
Fixes#2045
Change-Id: Ie8a57283468d88697619349a29e37a804586e5ef
This is a fully automated change. The linter will fail because the
extra indentation caused line-length errors. These won't be fixed
automatically. They are fixed in a follow-up to make this one fully
automated.
Change-Id: I4d8cf9c998985add2bcd24a81c8d65495668c4f3
With the new style rule, we cannot have two statements on the same line.
So we can no longer have an "if" on a single line and we cannot have
an arrow function with a body on the same line as when it is used.
This is mostly a manual change.
Change-Id: I2285202dd5ecbad764308bc725e6d317ff2ee7f0
A coming update to the Google eslint config will require using "const"
over "let". This makes that one change to isolate the big changes.
Change-Id: I7d0974c3ae15c53cc45a6b07bf9f6586e2d34aca
This change moves the trick play logic out of the video wrapper so that
it will be more available to the src= code. By doing this, I hope that
we can make it clearer how we are working with the playback rate and
ensure a tighter integration with it.
Issue #816
Issue #997
Change-Id: Id462cda2c5eb82c3713237341424b91891bd38ea
This CL creates the "loaded with src=" node and its initial
implementation. Adding this node required some changed to the routing
logic as a new destination was created.
We will use src= when given mp4 content or media source is unavailable.
We detect mp4 content via the mimeType in |load| and/or the file
extension. When media source is not available on a platform, we fall
back to using src=. To do this, we check if media source is available
whenever |load| is called, and will route to the src= branch if media
source is not found.
To avoid pre-initializing media source (when it is not available) we
modify the |initializeMediaSource| flag in |attach| and |unload| when
media source is not available.
Doing this showed that we had inconsistent behaviour between |attach|
and |unload|. |attach| would default to initializing media source
whereas |unload| would not. This has been fixed.
Issue #816
Issue #997
Change-Id: I00599832b49c9079e273e65a4b827fee736479cc
We need to have a playhead for media source and src=, however the
current playhead implementation is tied very tightly to manifests.
Rather than working to refactor playhead, this change defines an
interface and makes the old playhead the Media Source implementation of
the interface.
In a later change the src= version will be introduced to allow playhead
functionality when we don't have a manifest.
Issue #816
Issue #997
Change-Id: Ie74e50839c79c3cd3acf14000849e3d5fa71a42f
Make the stall detector configurable via Player.configure. This
should make it easier for developers to work around stall issues
and make it easier for us to find ideal configuration for
different platforms.
This exposes:
- Enabled : A flag for whether or not the player should
initialize and use a stall detector.
- Threshold : The number of seconds that must pass without
progress before firing the stall-event.
- Skip : The number of seconds to skip forward after a
stall-event.
To make enable possible, the stall detector was made optional and
is now passed into the gap jumper. This allows Playhead to evaluate
the config and create the detector as desired.
Issue #1839
Change-Id: Ife1bf34b4cfc7b469f4b0beb312a06d5b5cd81a9
In our tests, it was possible for a timeout to fire after |clearTimeout|
was called. This CL makes sure that cannot happen by adding an "alive"
flag to each timeout.
To ensure that the change was as well defined as possible, this CL
changes how |shaka.util.Timer| is implemented and updates the API to
better communicate what is happening internally.
Change-Id: I57e3899046a762bff3293b9822a7e8f7ac804042
This change takes playhead and its internal members and moves them
over to use the IReleasable interfaces instead of the IDestroyable
interface.
Change-Id: Iddb525725591a29a61ca6b5e2ad519ab708164eb
Updated the shaka.util.Timer class to ES6. In this upgrade, the implementation
was slightly changed to make better use of arrow-functions.
Documentation for the class was expanded on to better document how multiple
calls to start would work. To ensure consistency, both "schedule*" methods were
merged into a single "start" method.
Issue #1157
Change-Id: Iae86cae4d9cb751f0985ef20c371c0023c40bd53
This change removes all internal references to manifest from playhead. It still
takes in a manifest as part of the constructor to help limit the scope of this
change. Changing the constructor will follow in another change.
Issue #816
Change-Id: I2ed477d678f4ac166e972b319c710a33e4db06c2
Before, we would pass a manifest to the gap jumping controller
just to use the presentation timeline. To avoid needing to have
a manifest, we can just pass the presentation timeline to it.
Issue #816
Change-Id: I606645cbfcc82811ee95f1f39d750f99f8e7efaf
In an effort to decouple Manifest from Playhead this change removes
the utility function getRebufferingGoal.
getRebufferingGoal was only used in playhead.js, playhead_observer.js, and
streaming_engine.js. However, it was used in two different ways:
- playhead.js and playhead_observer.js always used it with a scale of
one.
- streaming_engine.js used it with a custom scale and then with another
buffering value.
Since the logic inside the function was so simple and the use of the function
between call sites were different enough, there appeared to be little value
in keeping the function.
Change-Id: Ie0983a1f84516a3cf5de34cd5ed87d1e786862d8
Playhead.onSeeking_ assumes that seeking is nearly instant;
thus, it has 0.001s tolerance. That works fine on most platforms, but
on some slow platforms (e.g. v1 Chromecasts), this can actually be a
problem. Specifically, it can cause them to get stuck in a loop of
repeatedly seeking, when playing HLS livestreams.
This changes Playhead.onSeeking_ so that it will only attempt to undo
a seek once every second. This way, if running on a slow platform, it
won't get stuck trying to seek to start time.
Closes#1411
Change-Id: Ia4fa6da8bcd90eb04b80d80c3f793bba2a7f382d
On Chromecast, some streams were unable to keep up with the narrow
seek window, and got stuck perpetually seeking forward.
This change increases the seek window to 3 seconds long, which some
initial testing has shown to be the shortest value to play without
uncomfortable choppiness.
Unfortunately, v1 Chromecasts still have issues, even with this.
It seems like they have a separate issue.
Issue #1411
Change-Id: I597315cd418861b18e63a859197a8c2585cb4fd0
This fixes a weird edge case where StreamingEngine could get stuck
waiting for Playhead.
If StreamingEngine is playing close to the left edge of a live stream,
a manifest update can evict segments it needs. This causes
StreamingEngine to wait for segment references. This condition won't,
change, though, until Playhead seeks back into the seek range.
Playhead wouldn't seek back into the seek range until video.seeking
became false, which couldn't happen until StreamingEngine appended
some content that intersected with video.currentTime.
There seems to be no good reason for Playhead to care about the
video.seeking.
This resolves a startup failure while trying to play live streams at
the left edge of the seek range on slow embedded devices such as the
v1 Chromecast.
Bug: 75276747
Change-Id: Iaa084e8220ace174909d3ad91abe0c1eac00cea9
This fixes how we determine the seek window for live content. This
also allows for a slight margin for small seek windows in reposition_
so we don't repeatedly seek with that.
Closes#1331
Change-Id: I70e5e7c134677350d89d42cb0b5abfa784061b9e
This makes a large number of small typo fixes. It also rewords a
number of comments and JSDoc descriptions, and does some
formatting standardization.
This doesn't fix every single issue, but it fixes a lot. Notably,
there were some formatting issues I declined to standardize due to
ambivalence on what the proper standardization would be; for example,
when and where empty lines should show up in JSDoc.
Change-Id: Ibce58f022b79de5efd5c0f3d5ab40a6042055b3f
To allow playing live stream from certain offset from live edge, we
allow setting the value of opt_startTime parameter for player's load()
function.
Closes#1178.
Change-Id: I23a2375ba8ee5946791ee79714ed017c4e677c9a
When there is a zero-width seek range, don't repeatedly try to
reposition the playhead to keep within that range. This simply adds a
small buffer around zero-width seek ranges.
Closes#1331
Change-Id: I87b787f1454750eaa2caafa7c23cb9e37d3328e6
Google style guide requires adding curly braces to all block statements
even if it is only has one line. This fixes it by using eslint's
--fix flag followed by running clang-format to reformat the change.
Change-Id: Idc086c2aa8c02df5ef8b2140a11bfb9128eeb4bd
The browser should handle extremely small gaps for us. So having the
browser handle these gaps, this avoids an infinite loop if there are
rounding errors.
Closes#1309
Change-Id: I365f44185f570571f6b093bdcaad92fef49b5b16
Rather than using the availability window, Playhead should use the
seek range to restrict the playhead's position.
Closes#1224
Change-Id: I8612bfafb53bbb214e32aae2d71af52d748a3aee
This is part of a change to convert all usages of 'var' with either
'let' or 'const'. This takes a conservative approach for 'const' where
it will only be used for aliases and storing the "original" values in
tests.
Change-Id: If4792c1bd3d5a82c24a4b2f0f84790d4eed22e67
This splits some of the independent code from Playhead into several
new helper classes. This allows Playhead to be simpler and easier to
understand.
This keeps the new behaviors and classes as private pieces of Playhead
to keep Playhead conceptually in-charge of handing the Playhead. It
still has the same responsibilities, but the code is split into other
files.
Issue #1224
Change-Id: Ia828f902ba9490d128f4ca9cb1e34119ec93f188
This changes onPollGapJump_ to not gap jump if the video is seeking
but a seeking event has not yet occurred.
This also adds a unit test that tests for the bug in issue #1061.
Closes#1061
Change-Id: I8662f5878006ed8626ca8df55f0506edb2dd970e
Seeking to or starting playback at the duration does not work well
across browsers. Any seek or startup time at or past the duration of
VOD or IPR content will be bumped back by a configurable amount
(default 1s).
Closes#1014
Bug: 69874888
Change-Id: I6d21ecd8e211f0f823a093b8eb8b95d329b4385f
On Edge & IE, the timing of "loadedmetadata" and "timeupdate" events
is different, and exposed a race condition in the fix for #1105.
This solves the race by canceling any pending "early seek" handling
once "loadedmetadata" fires.
A fix for the fix of issue #1105
Change-Id: I5587a72e12c6b28beb0b3ea36f2665a0f1e39f08
We shall not buffer live stream, when the video is paused and the
playhead falls out of the seek range.
Closes#1121.
Change-Id: I66bbe1e62017f6ae8d121f072f324763f73da0f4
There are two ways Playhead should be able to recover from a drifting
stream:
1. Wait until the initial position is available
2. Seek to another position
Neither of these was working. For one, we couldn't detect seeks
before content was loaded. For another, we were constantly updating
the initial streaming position, so a drifted stream would never catch
up to our expectations.
This fixes both issues so that a drifting stream can at least recover.
Relates to issue #999 (drift tolerance)
Closes#1105
Change-Id: I8d2eedcff25b92b42ecd2e1f361d45ecbddd26ba
This also changes the tests so they mirror the |video.seeking|
property to reveal the problem that change created. That change
broke seeking into gaps and gaps before the start.
Issue #1149
Issue #1150Reopens#1061
Change-Id: I18fb65b1529acdacd0becd77078780625e0a955b
Use of setInterval has unpredictable behavior when the device goes
to sleep or is in a background tab. Adds a function to the shaka
Timer class which reproduces setInterval functionality using
setTimeout.
Change-Id: I0b2db8a5a9197527717bc4566c7beb109270f8ea
Fixing: when a livestream is paused, we force the playhead back in
if the playhead falls out of the seek range, which makes the paused
image change.
Now we'll jump when the user hits play.
Closes#982.
Change-Id: I3f9e05e15c710488477b70ea7642f007c771ea92
Sometimes, when seeking backwards, the seek takes long enough for the playhead
to erroneously detect a gap and gap jump back to its previous position.
This only seems to happen when casting, presumably due to the additional
delay from message-passing.
This prevents gap jumps from happening while the video is seeking, and it should
solve the issue.
Closes#1061
Change-Id: I363c69428d84029a7808229c9c0e18eb691dd7f8
This reverts commit ffa46a2602.
Reason for revert: This does not fix the problem. It only adds another layer of code. When we remove Shaka Player and go down to the basic web classes, this problem does not exist.
Change-Id: I63b4050bf83287a18a045658d16b3163780b5ff2
Browser behaviour for when you seek to duration differs between
each browser but it appears that seeking just before duration
behaves the same regardless to browser.
When seeking, can check if we are seeking to the video's
duration and if so, push the time back a little.
Closes#1014
Change-Id: I49ba61ee7cac69a20e0ea1202efd4660371928ac
When the user seeks using Edge's native controls, Edge sets
playbackRate to 0 first. This confused Playhead and resulted in a
playbackRate stuck at 0 after the seek.
To fix it, we filter out rate changes to 0 in the code that remembers
the previous setting during a buffering event.
Closes#951
Change-Id: Ia7a9a2a6d65dcf2d74ea6fb4d92594070a1ebe6a
Joey Parrish
Sandra Lokshina
Álvaro Velad Galván
Michelle Zhuo
Jacob Trimble
Aaron Vaage
Tomáš Tichý
theodab
Tim Plummer