- 20 Jan, 2016 1 commit
-
- 19 Jan, 2016 5 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 2 commits
-
-
* Added a media2.m3u8 file since that was the only variant that was missing and it just so happens that fixing selection meant media2 became very commonly selected in tests * Rendition selection test for non-exact player dimensions
jrivera committed
-
- 11 Jan, 2016 1 commit
-
-
jrivera committed
-
- 05 Jan, 2016 1 commit
-
-
jrivera committed
-
- 22 Dec, 2015 5 commits
-
-
jrivera committed
-
jrivera committed
-
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 -
David LaPalomento 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 -
jrivera committed
-
jrivera committed
- 09 Dec, 2015 2 commits
- 08 Dec, 2015 1 commit
-
-
jrivera committed
-
- 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 -
Josep Vinyals committed
-
- 04 Dec, 2015 1 commit
-
-
jrivera committed
-
- 01 Dec, 2015 1 commit
-
-
jrivera committed
-
- 30 Nov, 2015 1 commit
-
-
…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
-
