- 05 Jan, 2016 1 commit
-
-
- 22 Dec, 2015 5 commits
-
-
-
-
cue.frame.data should now be accessed as cue.value.data to match iOS behavior.
David LaPalomento committed
-
- 17 Dec, 2015 1 commit
- 16 Dec, 2015 3 commits
-
-
readyState should have been a function all along added a test for expired seconds tracking not beginning until firstplay is triggered
jrivera committed -
Don't increment seekable until the live stream has started to play. This more closely matches Safari's behavior WRT live stream and seekable.
jrivera committed -
-
- 15 Dec, 2015 2 commits
- 14 Dec, 2015 1 commit
-
-
The code these describes was removed a while back but these vestigial comments remained
jrivera committed
-
- 11 Dec, 2015 7 commits
-
-
Firefox doesn't allow you to seek until 'canplay' is fired and doesn't fire canplay until after playback has begun. As a result, seeking to the right point in a live stream requires setupFirstPlay to wait for 'canplay' and check that the readyState signifies that we can finally seek.
jrivera committed -
The state of the player can change between fillBuffer and drainBuffer so we should decide where to place a segment when we decided which segment to fetch
jrivera committed -
There is no guarantee that different playlists have the same media-sequence number in a live stream. This would throw off expired calculations and make all our times useless. The fetcher should eventually fetch a segment with timing information and that will bring our expired calculation back in line.
jrivera committed -
-
- 09 Dec, 2015 2 commits
- 08 Dec, 2015 1 commit
-
-
- 07 Dec, 2015 1 commit
- 05 Dec, 2015 2 commits
-
-
(development branch) fix calling abort on a sourceBuffer whose mediaSource.readyState != open
David LaPalomento committed -
-
- 04 Dec, 2015 1 commit
-
-
- 01 Dec, 2015 1 commit
-
-
- 30 Nov, 2015 3 commits
-
-
…allback is no longer valid In XHR, aborts eventually cause timeouts which cause the callback to be issued again later. We would see that it was a timeout and clear two important state holding properties on the Hls object which could cause problems processing the current segment
jrivera committed -
We can simplify this code since we no longer try to store segment start information We also try to be more conservative in what data we save. If the last append somehow resulted in more than one change we can't be sure which end-point is the one that belongs to the segment so save nothing.
jrivera committed -
We are no longer storing start information in the segments which allows us to greatly simplify this function
jrivera committed
-
- 27 Nov, 2015 5 commits
-
-
-
Track player events and display counts on the stats page. Add a toggle to force Flash mode.
David LaPalomento committed -
getMediaIndexForTime() looks to have a boundary issue that is causing seeks to be unreliable in live streams. While we track that down, add a tiny delta to seeks to avoid the problem.
David LaPalomento committed -
When we switch playlists in a live video, we have to find the right place in the new playlist to continue buffering. This is complicated because we can't guarantee the two variants are segmented at the same time positions or that the windows of time they represent are exactly in sync. Most of the time, they're pretty close to one another and we can use that fact to make better guesses at which segment to download when switching. This PR adds back tracking of expired content in the playlist loader, which can then be used to estimate the seekable window for live playlists even before we've buffered any segments from them. This also allows seekable to be accurate even when the player has paused for a long time and all the segment timing information we gathered has gone out of date. To make rejoining or seeking in a live stream even more robust, we detect when a seek "misses" the live window and seek again to a safe position.
David LaPalomento committed
-
- 21 Nov, 2015 2 commits
-
-
- 20 Nov, 2015 2 commits
-
-
Make the default bandwidth estimate a bit less conservative. On bad connections, this may lead to slower startups but it can be overridden through options or by setting the bandwidth property early.
David LaPalomento committed -
Look forward and backward through the playlist to find an anchor to base seekable calculations on. This is helpful for live playlists in particular, where the only way to determine the correct starting position for the seekable range is to look at where future segments have ended up in the buffer. Without this change, the start of seekable was always zero, even if the live sliding window had moved forward.
David LaPalomento committed
-