When enabled, if the NetworkInformation API is available, it will be used for bandwidth estimation, If our estimation is greater than 10MBps and the downlink returns 10MBps, then our estimation is used.
* Don't switch renditions when the pending rendition is the rendition we would switch to
* Don't switch renditions before playback starts for llhls
* Don't set seekable until all source buffers have been created
* Take into account parts and preload segments when during duration calculations
* Reset the segment loader on rendition change for live streams, still resync for vod
* Try to choose an independent first part if we have no buffered data
* Determine if we made a bad part guess for our segment download
Chrome 92 introduced a limit (75) on the number of media elements that can exist in a page at a time and we were going over that limit in our tests, causing them to fail.
Add an option for caption services metadata in case the user wants to specify labels for 608/708 captions, override the ones provided in the manifest, or needs to add more information like character encoding (this isn't currently available but will be added some time in the future).
For HLS, an EXT-X-MEDIA tag can be specified with an INSTREAM-ID attribute. We already support this. https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-08#section-4.4.6.1
This PR updated mpd-parser which uses the ANSI 214 supplemental spec section 7.2 to parse out the same information from MPD files. videojs/mpd-parser#131.
Adds a property called captionServices which has properties of the caption service IDs like CC1 or SERVICE1 and allows a user to specify a language and label.
Introduce a new option `maxPlaylistRetries`, which defaults to Infinity to match existing behavior. If set, this will cause a playlist to be excluded indefinitely when the threshold is crossed. When a playlist is requested successfully, the count is reset.
If a stream has multiple playlists, all playlists will need to cross the max retries threshold for playback to completely fail.
Co-authored-by: Evan farina <efarina@linkedin.com>
Co-authored-by: Gary Katsevman <git@gkatsev.com>
Co-authored-by: brandonocasey <brandonocasey@gmail.com>
Deprecate smoothQualityChange_ on the MPC, but otherwise, always do fast quality change whenever a user requests a rendition change and on fullscreen change
Although the audio status is set in onTrackChanged for media groups, and
the function is called when the media groups are first set up, the track
is not always considered changed. This means that for demuxed audio, the
main loader may still think it should be using its own audio itself,
leading to issues when crossing discontinuities (i.e., the main loader
will cross the discontinuity before waiting for the audio loader to be
ready, leading to audio timestamps that aren't correct).
This change ensures that the audio status is set on setup, regardless of
whether the track is considered changed. Subsequent changes are handled
in onTrackChanged.
Previously, for DASH, pausing a media loader would end up pausing the
main loader as well (via removal of the main loader's minimum update
period). For live streams which required manifest refreshes, this meant
that on media changes, the main loader would be paused and sometimes
never resumed.
This change ensures that when a media loader is paused it won't remove
the main loader's minimum update period timeout.
In addition, a change was made so that loading a main DASH playlist
loader recreates a minimum update period timeout if the main DASH loader
was previously paused (and the timeout cleared).
Co-authored-by: Brandon Casey <2381475+brandonocasey@users.noreply.github.com>
Evan Farina