- 26 Jun, 2015 13 commits
-
-
jforbes committed
-
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 -
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 -
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 -
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 7 commits
-
-
David LaPalomento committed
-
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
-
-
David LaPalomento committed
-
David LaPalomento committed
-
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 7 commits
-
-
jforbes committed
-
David LaPalomento committed
-
Two tools used to inject TXXX frames terminate the value field with a null byte. Make sure that isn't included in the parsed representation.
David LaPalomento committed -
If the segment parser timestamp offset isn't at the start of the last encountered discontinuity, it was impossible to recover the associated media time. Track the media time alongside the timestamp offset so that when a stream is first loaded and the last discontinuity segment start is unavailable, it's still possible to properly translate timestamps. Also, make sure that cue points ahead of current time are cleaned out of the in-band metadata track on seeking. We previously assumed they were ordered by start time but that doesn't seem to be the case for Chrome on OS X. Use the dev version of video.js because of Google Closure compiler gobbling some part of the requiremed machinery for removing cues.
David LaPalomento committed -
Previously, in-band metadata cues were added whenever they were encountered during the segment parsing process. If you seeked in a stream, this would cause the same cues to be added multiple times when its containing segment was re-buffered. Now, cues that occur after current time are cleared on every seek which allows them to be re-added without duplication after they're re-parsed. Cues before the current time are retained because re-buffering would not cause them to be recreated. Adjust cue point creation to take live stream segment expiration into account.
David LaPalomento committed
