- 08 Feb, 2016 3 commits
-
-
-
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
- 04 Feb, 2016 1 commit
-
-
- 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 2 commits
-
- 22 Jan, 2016 1 commit
-
-
- 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 -
- 18 Jan, 2016 1 commit
-
-
- 15 Jan, 2016 1 commit
-
-
- 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
-
-
- 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 -
-