- 01 Mar, 2016 1 commit
-
-
jrivera committed
-
- 12 Feb, 2016 1 commit
-
-
getComputedStyle returns null when in an iframe with display: none so be careful dereferencing it.
David LaPalomento committed
-
- 10 Feb, 2016 2 commits
-
- 09 Feb, 2016 3 commits
-
-
jrivera committed
-
…n enough information exists to do so * Moved endOfstream and playlist updating code out of `updateendHandler` * We now update segment durations when we have a previous segment with a known end-time * Always trigger endOfStream when we append the last fragment in addition to triggering it if we are in a buffer that touches the end of the stream (duration) after an append
jrivera committed -
- If the playlist hasn't been loaded yet, use 0. - If the playlist duration is Infinity, use the playlist duration. - If the mediaSource doesn't exist, use the playlist duration. - In all other cases, use the mediaSource's duration.
jrivera committed
-
- 08 Feb, 2016 1 commit
-
-
In Firefox, the updateend event is triggered for both removing from the buffer and adding to the buffer. To prevent our update end handler from executing on removals, we wait for segmentInfo to have a filled in buffered value before we continue processing.
Garrett Singer committed
-
- 29 Jan, 2016 2 commits
-
-
Don't use the literal "3" for the number of segments required for stable live playback.
David LaPalomento committed
- 25 Jan, 2016 1 commit
-
-
Dylan Dove committed
-
- 20 Jan, 2016 1 commit
-
- 19 Jan, 2016 4 commits
-
-
- Addressed internal function issues as well as removed a potential fillBuffer bug - Added tests for byte-range requests
Dylan Dove committed -
Katrina Ellison Geltman committed
- 18 Jan, 2016 1 commit
-
-
jrivera committed
-
- 15 Jan, 2016 1 commit
-
-
jrivera committed
-
- 14 Jan, 2016 1 commit
-
- 11 Jan, 2016 1 commit
-
-
jrivera committed
-
- 16 Dec, 2015 1 commit
-
-
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 1 commit
-
- 14 Dec, 2015 1 commit
-
-
The code these describes was removed a while back but these vestigial comments remained
jrivera committed
-
- 11 Dec, 2015 4 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 -
jrivera committed
-
- 09 Dec, 2015 1 commit
-
-
jrivera committed
-
- 07 Dec, 2015 1 commit
-
- 05 Dec, 2015 1 commit
-
-
Josep Vinyals committed
-
- 04 Dec, 2015 1 commit
-
-
jrivera committed
-
- 01 Dec, 2015 1 commit
-
-
jrivera committed
-
- 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 2 commits
-
-
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 1 commit
-
- 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
-
