- 15 Jun, 2015 4 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 10 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 -
Seeking is clamped to the seekable ranges, which are empty for an empty playlist. Making seeking a harmless no-op to match the spec in this case.
David LaPalomento committed -
We don't need a PCR stream for a program to keep synchronized but it's not a problem if one is included. Parse out the PCR PID when it's specified and make sure the warning message isn't output when they are encountered.
David LaPalomento committed -
When a NIT was present, we would warn about unrecognized PIDs every time it was encountered. Capture the PID value so we can silently ignore it. Add a test case for NIT parsing.
David LaPalomento committed -
-
-
-
-
- 27 May, 2015 4 commits
-
-