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
1. When the video hasn't started playing and is buffering, display
playback rate as 1x.
2. When the video is buffering and the playback rate gets updated,
display the newly selected playback rate.
Closes#2526.
Change-Id: I2e8764cfabdcc675a94e26bd9cd18cbc056a35f9
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
If a value given to player.trickPlay() is outside of what
the browsers accepts for video.playbackRate, fall back
to fast forward by seeking, same as we do for rewind.
Closes#1957.
Change-Id: I12275377b70dc1d0e2ece7f5647e6590f0304cf5
PlayRateController could get stuck in a state in which playbackRate
would be stuck at 0. It had to do with the order of modifiers
BUFFERING and ZERO_RATE. If they occurred in that order (BUFFERING
because of underflow, followed by ZERO_RATE because of a ratechange
event), then ZERO_RATE would stick.
In some cases (~10%) we would see this as a test failure in "Player
plays while changing languages with short Periods". In the demo app,
it could be easily reproduced by changing resolutions through the UI.
The solution is to remove ZERO_RATE, which doesn't seem to be useful.
Based on the comments in the code, this was to handle seeking in Edge,
where the browser sets playbackRate to 0 during a seek, then restores
it afterward. If that's the case, just ignore the ratechange event
to 0, and let the browser restore it afterwards. No need to track
that as far as I can tell.
With ZERO_RATE removed, it doesn't make sense to keep a BUFFERING
constant, so the whole set has been replaced with a boolean.
Broken in Change-Id: Id462cda2c5eb82c3713237341424b91891bd38ea
This bug did not affect any release or beta versions.
Closes#1886
b/130758100
Change-Id: I8c6455c3cdd7c9f353740425fb9337733908b2c9
Use a fudge factor to fix infinite buffering at the end of a native
HLS playback. This could go away once we stop managing buffering
state above the browser using playbackRate=0.
Issue #997
Change-Id: Ib4a6fd5aa10dd84f9cfa4972d57db2cc63d7668d
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
Joey Parrish
michellezhuo
Jacob Trimble
Álvaro Velad Galván
Sandra Lokshina
Aaron Vaage