Deprecate lingering references to hls from the old videojs-contrib-hls
project, as well as dash. Ensure all references use `tech().vhs` instead.
Co-authored-by: Garrett Singer <gesinger@gmail.com>
Co-authored-by: Gary Katsevman <git@gkatsev.com>
This change adds two new events to `SegmentLoader`. The first `appendsdone` is fired whenever an append is complete on any main, audio, or subtitle loader. The second `playlistupdate` is fired whenever a playlist is changed on the segment loader.
Using these new events `PlaybackWatcher` watches for the `SegmentLoaders` `buffered_()` function to return a different buffered time range after each append. If it finds that we are not changing the buffered time range after three appends it will exclude the playlist or disable and remove the text track causing the issue.
Finally `PlaybackWatcher` will reset the buffered change counter whenever `playlistupdate` is fired on the `SegmentLoader` or when `seeking`/`seeked` fire on the `Tech`.
- fix: only save timeline mappings for main loader
Timeline mappings should only be saved for the main loader. This is for multiple
reasons:
1) Only one mapping is saved per timeline, meaning that if both the audio loader
and the main loader try to save the timeline mapping, whichever comes later
will overwrite the first. In theory this is OK, as the mappings should be the
same, however, it breaks for (2)
2) In the event of a live stream, the initial live point will make for a somewhat
arbitrary mapping. If audio and video streams are not perfectly in-sync, then
the mapping will be off for one of the streams, dependent on which one was
first saved (see (1)).
3) Primary timing goes by video in VHS, so the mapping should be video.
Since the audio loader will wait for the main loader to load the first segment,
the main loader will save the first timeline mapping, and ensure that there won't
be a case where audio loads two segments without saving a mapping (thus leading
to missing segment timing info).
- Add playback watcher check to correct cases where seek point ends up just before content.
If audio and video streams are not perfectly aligned, a seek can result in the buffer
starting just after the seek position. In that event, playback watcher should seek into
the buffered contents to resume playback.
* Add allowSeeksWithinUnsafeLiveWindow property
This property will prevent the playback watcher from attempting to
correct seeks that fall outside of the safe live window, but still fall
within the playlist boundaries.
It can help resolve issues where the playback watcher's gap skipper tries
to seek past a gap, but the playback watcher then detects an illegal seek
and corrects it to the safe live point, which, being content already
played, leads to repeated content.
Run a test pass with video.js 6 and video.js 5.
Also, use in-publish to not run build when running `npm install`.
Consolidate karma configs into one config but keep npm scripts for them.
Add `this.clock.tick(1)` after player creation to support video.js 6.
* add playback watcher check for unknown player waiting
* do not do unknownwaiting check when the tech fires a native waiting event
* dont track current time waiting when at the end of the buffer
* call techWaiting_ when we detect a stall at the end of buffer
* Fix a bug with the combination of seek-to-live (#1006) and resync-on-a-poor-guess (#1016) behaviors
* Added tests to ensure the proper sequence of events for seekable and resync logic
* Unregister the seekablechanged event handler from the tech on dispose
* Fix resuming after long pause on live streams by keeping seekable updated
* If new sync info shows we are trying to seek outside of seekable range, seek back to live point
* Set seekable to main when audio seekable and main seekable have no intersection
* Always trigger syncinfoupdate when updating a segment loader playlist
* Move seeking outside of seekable check to playback watcher
* Add events for underflow and live resync
For QoS measurement purposes, it may be useful to know how often the playback watcher is activating. Add new events for when the player falls off the back of the live window or stalls due to a video buffer gap.
* Review comments
Minor cleanup and an additional assertion.
Fixed seeking behavior
Updated getMediaIndexForTime to be simple and stupid
Remove spurious console logs
Fixed an issue with forward seeks and a different problem with backwards seeking (thanks Matt!). Fixed fast rendition change behavior.
Remove limits on gap-skipper. Skip instantly without waiting.
Use the proper native MediaSource duration for buffer removals.
Improvements for live stream rendition changes
Fixed an undefined variable bug
Some more simplification and a very conservative live stream rendition change approach
VOD fixes
Experimental change to the way we throttle the fetcher
Use GOAL_BUFFER_LENGTH again
Continued massive changes to segment fetching. Cleanup and comments.
Fixed a bug where we were fetching starting at mediaIndex 0 on every seek.
Refactor probing code in preparation for pulling into it's own module or class
Moved sync-related logic out of segment-loader and into a new sync-controller class
Removed expired from the SegmentLoader
Update mux.js dependency to 2.5.0
Don't error when the tsprobe returns null
Fixed two issues: MAAT switching and Flash seeking
Rename duration variable
fix flash failing first segment load (#859)
dont use tech for has played (#861)
Code Coverage and Unit tests for Simple Fetcher (#862)
fix has played returning false on vod (#866)
Fixed preload="none" behavior and reduced the incidence of repeating initial segment requests (#878)
Provide option to set contrib-hls first in the HTML5 tech (#889)
This reverts commit 59ddbe1188.
Add playback tests (#894)
Fixed MSE and environment test helpers, restore properly
Removed unused test files
remove expired time tracking and use sync points to calculate seekable (#898)
Fixing a few tests for QUnit 2.0
* Seek to live point if we fall off the back of a live playlist
* Remove extraneous checks from always-be-playing
* Remove side effects from always-be-playing check functions
* Rename AlwaysBePlaying to PlaybackWatcher
* Skip gaps caused by video underflow
In the event that there is a small gap in the video buffer, Chrome will consider it video underflow, and will continue playing audio for ~3 seconds while video remains frozen. The current time of the player will update to reflect the audio playback. Due to the audio overplay, the gap skipper will think we are in a buffered region, and will not skip over the gap. This adds support for skipping over gaps caused by a browser's interpretation of video underflow.
Brandon Casey