- 26 Jan, 2016 1 commit
-
-
added notifications back to travis fixed sinon version in package.json got unit tests working by modifying the karma config Added back manifest/expected.js to the build pipeline Added a script to build/watch/clean them Added script execution to package.json got switcher partially working again
brandonocasey 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 -
-
- 09 Dec, 2015 2 commits
- 08 Dec, 2015 1 commit
-
-
- 07 Dec, 2015 1 commit
- 05 Dec, 2015 1 commit
-
-
(development branch) fix calling abort on a sourceBuffer whose mediaSource.readyState != open
David LaPalomento committed
-