- 29 Jun, 2015 1 commit
-
-
- 26 Jun, 2015 14 commits
-
-
-
-
Simplify the PR rebasing. Make sure the editor isn't invoked to amend the merge commit with the changelog update. Move tests to after the change has been fully merged.
David LaPalomento committed -
If currentTime is called with a value outside the current seekable range, seek to the closest valid playback position instead.
David LaPalomento committed -
If the player has fallen out of the live window, seek back to the earliest safe position when playback resumes. If the player is paused too far ahead of the live point, seek back to the latest safe position when resuming.
David LaPalomento committed -
Modify the accept-as-is contrib.json task to add the changelog entry to a custom merge commit.
David LaPalomento committed -
Simplify the PR rebasing. Make sure the editor isn't invoked to amend the merge commit with the changelog update. Move tests to after the change has been fully merged.
David LaPalomento committed -
- 25 Jun, 2015 3 commits
-
-
If currentTime is called with a value outside the current seekable range, seek to the closest valid playback position instead.
David LaPalomento committed -
If the player has fallen out of the live window, seek back to the earliest safe position when playback resumes. If the player is paused too far ahead of the live point, seek back to the latest safe position when resuming.
David LaPalomento committed -
When upswitching, we try to find the best resolution based on bandwidth and based on the player dimensions. However, player.width will return the set width value of the player (https://github.com/videojs/video.js/issues/2282) instead of the current value which means that in fullscreen we don't think we the player changes size and so we don't upswitch.
Gary Katsevman committed
-
- 24 Jun, 2015 2 commits
-
-
Modify the accept-as-is contrib.json task to add the changelog entry to a custom merge commit.
David LaPalomento committed -
-
- 21 Jun, 2015 1 commit
-
-
Use the time range covered by the union of audio and video track PTS values when calculating duration. For non-live content, this matches the NetStream's duration calculation to within a millisecond or so. Make sure that segment PTS information is preserved when live playlists are refreshed. Remove FlvTag.durationFromTags in favor of Playlist.duration() since the latter handles durations across segments and discontinuities. For #314.
David LaPalomento committed
-
- 18 Jun, 2015 1 commit
-
-
Segment duration can have different interpretations in different contexts. To ensure we have all the information we need to seek accurately, record PTS values for the audio and video streams within a segment. For #314.
David LaPalomento committed
-
- 15 Jun, 2015 8 commits
-
-
Setup grunt-github-releaser for subsequent releases. Remove a leading newline that caused chg to mis-parse the changelog for 0.17.2.
David LaPalomento committed -
-
-
When you first called play() on a live stream, the seek wouldn't complete because of a condition in fillBuffer() that prevented buffering until the player had started. Allow fillBuffer() to begin buffering in a live stream at a specified position, which ensures drainBuffer() will clean up the seek correctly.
David LaPalomento committed -
Deprecate getMediaIndexByTime and replace it with a PlaylistLoader.getMediaIndexForTime_ that considers expired content in live playlists. Fix an issues that would allow the return value to be less than zero or greater than the index of the last available media segment. Currently, this code does not take into account rounding of segment durations in HLS v3.
David LaPalomento committed
-
- 14 Jun, 2015 2 commits
-
-
Include the video element config in the example code. Link to the demo on gh-pages.
David LaPalomento committed
- 08 Jun, 2015 4 commits
-
-
-
-
If play() was called before the media playlist has been downloaded, when the playlist finally was received we would still update media index to the live point to start buffering. We would have skipped the code that adjusted currentTime however, so playback would seem to begin at zero instead of seekable().end(0). That would cause media-timeline relative positions to be off by the live window length and things like cue points would fire 60 seconds (for example) after they should have. Now, don't preload live video at all and just seek to live immediately on play, updating the currentTime at that point.
David LaPalomento committed
-
- 05 Jun, 2015 4 commits
-