- 26 Jun, 2015 5 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
- 25 Jun, 2015 1 commit
-
-
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 1 commit
-
-
- 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
-
-
-
-
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 7 commits
-
-
-
-
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
- 04 Jun, 2015 2 commits
-
-
Keep track of the accurate durations of expired segments in the playlist loader so that it's possible to accurately calculate the start and end points of the seekable ranges relative to media timeline position zero, even if we switch variant streams or seek within a live stream. Track the media timeline position of the last discontinuity to allow for PTS-based variant stream synchronization instead of the incorrect media sequence based method we're currently using. Stop rewriting timestamps in the transmuxed FLV tags for that reason as well. Add m3u8 parser support for EXT-X-DISCONTINUITY-SEQUENCE.
David LaPalomento committed
- 02 Jun, 2015 1 commit
-
-
Override the Flash tech's seekable method to take into account live playlists.
David LaPalomento committed
-
- 01 Jun, 2015 1 commit
-
-
Mock out metadata stream support. Comment javascript simulation parameters. Simulation results currently always buffer the first segment because of the bandwidth scaling factor applied to deal with real-world discrepancies between m3u8 download times and steady-state downloads. Behavior after the first segment still looks good.
David LaPalomento committed
-
- 29 May, 2015 5 commits
-
-
-
-
A metadata tag injected into the generated FLV when a random access indicator was encountered in the adaptation field of a TS packet causes Firefox 38 on OSX to apply frame diffs against the wrong keyframe. This leads to ugly artifacts for a few seconds after seeking. Now metadata tags are only generated at the start of a segment and IDRs. Fixes #289.
David LaPalomento committed
-
- 28 May, 2015 2 commits
-
-
-
If bandwidth drops off precipitously, it's not a good idea to fetch a higher quality segment while waiting for the new media playlist to load. Delay segment loading instead. Less fetching will be done in parallel after this change but: - the player will adjust to dramatic bandwidth drops more quickly - the player will upshift more quickly when bandwidth returns
David LaPalomento committed
-