Add a `retryOnError` option. When set, during source selection, if a source fails to load, we will retry the next item in the sources list. In the future, we may enable this by default.
A source that fails during playback will *not* trigger this behavior.
Fixes#1805.
When preloadTextTracks option is set to false, it still preloads the default text track. This leads to duplicate tracks once the mode changes to showing and the track is loaded a second time. This includes the default text track in the behavior defined by the preloadTextTracks option.
Fixes#7019
Follow up from #6982. We previously threw an error, but we've seen it
happen unexpectedly. Instead, we should log an error.
We will still throw an error if the event is undefined or null.
Here, if we have a `log` object on the current object, we should use it,
otherwise, we use a default `log` object.
Fixes an issue in native Safari and Android HLS playback where liveCurrentTime returns Infinity (as we don't have a seekableEnd or seekableEnd is actually Infinity). Which causes the new live ui to show up when we don't really have a live window.
Instead of returning Infinity when liveCurrentTime is Infinity, return 0. So that everything knows that we do not have a seekable window of live playback.
The video dimensions aren't necessarily known at loadedmetadata particularly with native playback on iOS. In fluid mode, the player defaults to 16:9 and does not update once the dimensions are known.
- Updates player styles on resize events.
- Fixes arguments passed to addEventedCallback so the callbacks are executed.
Fixes#6939
Allows the editing of a track's label after its creation. Menu buttons will listen for the labelchange event and update their content accordingly.
This is technically divergent from the spec, which says it's readonly, but it can be useful for Video.js users.
Co-authored-by: Claudia Hinkle <chinkle@chinkle-mn1.linkedin.biz>
This uses offsetX and offsetY on the MouseEvents which helps account for transforms on the player. Unfortunately, this isn't available on TouchEvents, so, while this helps desktop devices with using a mouse, it doesn't help mobile devices using touch.
Fixes#6726, fixes#1102.
When `debug(true)` is called, it will fire a `debugon` event that plugins and components can then use to do extra logging or anything else that's helpful to for debugging. It will also set the log level to debug.
When `debug(false)` is called, it will fire a `debugoff` event that plugins and components can then use to stop doing extra logging or helpful debugging. It will reset the log level to whatever it was previously.
Co-authored-by: ipadilla4 <ipadilla@brightcove.com>
The requestPictureInPicture API and button currently assume thta if the browser supports the PIP API, the tech supports it. This results in a broken button with certain techs, such as youtube or HTML5 with an audio el.
Checks if disablePictureInPicture is exactly false. If true it's disabled and if undefined the tech does not support it.
Fixes#6398.
The fix in #6297 doesn't work where the child to insert before is an element rather than a component, e.g. the video element.
Check if the child to insert before is an element, as well as checking if it has an el_
In the cases where the player isn't ready, or we are in the middle of changing sources, we will wait for `canplay` and then seek to the provided time without requiring Video.js users to handle this themselves.
Co-authored-by: Marco Garay <mgaray@brightcove.com>
It seems we have never triggered change events on remoteTextTrack when we were using native text tracks. This was a problem for VHS, which exclusively uses text tracks.
This makes it so we do trigger the event. Main issue with this change is that it creates a potential for a false positive where a change event was triggered from a non-remote text track but the remoteTextTrack list still received a change event. This issue is mitigated by best practices of looping through the list looking for the modes that you care about.
Co-authored-by: Kevin Kipp <kevin.kipp@gmail.com>
Co-authored-by: Kyle Boutette <kyleveB@gmail.com>
When a player is created without an id on the embed code, Video.js automatically assigns it one based on an auto-incrementing number (a.k.a. a GUID). For the longest time, this has happened to result in the default id of the first player being vjs_video_3.
It was never intended for users to rely on this value being consistent, but users do strange and inadvisable things.
PR #6103 had an unintended side effect in that it changed the default id to vjs_video_2, which we worry could affect some users of Video.js.
