This means that a retryOnError is removed and is no longer needed for
this behavior, which means that during source selection, if a source
fails, it'll try the next source that's available, to match the video
element.
BREAKING CHANGE: remove retryOnError option, turn it on by default
* remove statement that handles attributes in props argument
* clean up function
* add unit test
* add unit test
* remove duplicate set attr
* revert function cleanup
Don't call tech.paused() in the requestVideoFrameCallback fallback if the tech is not ready. I've seen this is an issue in the Flash tech, as its methods are set up after the swf loads. Yes, Flash, it's 2022, but in theory another tech could be impacted if it's also async.
Use the timeupdate event as well as the rvfc and raf callbacks to check cues. This is a bit overkill for "usual" playback but avoids edge cases. If the more preceise callback trigger first the cue will update but the timeupdate event should catch any that were missed, notwithstanding that timeupdate was always somewhat unpredictable.
Fixes#7910 (audio in video els and Samsung being weird) and fixes#7902 (no updates off screen).
Safari's requestVideoFrameCallback is (intentionally?) broken when DRM is playing, so in that case use the fallback with requestAnimationFrame instead.
Add a new `displayNegative` option on the remaining time display to not show a negative sign in front of the time.
The default value is true to maintain current behavior.
Closes#7565
We were always setting `scrubbing(true)` on mouse down. This means, that
we'd use `fastSeek` even when seeking while clicking, rather than only
when scrubbing.
The main fix involves knowing in `handleMouseMove` whether we were
called directly as a `mousemove` handler or whether it was called from
`handleMouseDown`. This means that when `handleMouseMove` is called via
`handleMouseDown` we can skip setting `scrubbing(true)` and only do it
when we are scrubbing directly.
We try and enable the liveui on canplay, however, we only do it the first time after the LiveTracker is enabled. This means that if you change sources, we may not catch that the liveui should be enabled. This is particularly important for browsers where native playback is used, like Safari, as the metadata may not be available until canplay.
This is a follow-up from #7114 which enabled listening to canplay but didn't account for switching videos in the same player.
Some live streams with a 30s live window can actually fluctuate between below and above the 30s threshold we have. Instead, we should have a slightly lower default to have those streams get the liveui.
Mapping the promise returned from the helpers to the executor's resolve, and reject
methods. We also need to catch the error in the promise chain that's
created inside exitFullscreenHelper_.
Fixes#7298.
Previously, when autoplay was set to any or muted, we would accidentally swallow the autoplay rejection when we reset the muted state back to what it was. Instead, we want to re-throw the error.
To get it working, we also had to update our tests to try/catch in our fake promise.
iPhone's native fullscreen isn't always desirable as you can't overlay controls or anything else. Adds an option to prefer "full window" mode over the video el's fullscreen.
If the preferFullWindow option is set to true, on a browser that does not support the proper fullscreen API but does support fullscreen on the video element (i.e. iPhone), then requestFullscreenHelper_() should call enterFullWindow() instead of fullscreen on the tech.
This PR adds a new option to treat autoplay: true the same as autoplay: 'play'. In general we want video.js to handle as much of the autoplay logic itself as possible, since the browser's treatment of the video element's autoplay attribute is less predictable. For now the default option value is false, but it may be made the default behavior in a future major version.
Adds a new playbackRates() method that takes an Array of numbers
representing the rates that are wanted to show up in the playback rates
menu. When new rates are given, a playbackrateschange event will trigger, which
will be used by the PlaybackRatesMenuButton to update itself.
An empty array will hide the menu. No value will return the currently
set playback rates. Other values will be ignored.
Fixes#7198
Menus with one item are hidden if they have a title, because adding the title increments the hide threshold, but the title is not counted as an item. e.g. the chapters menu if there is a single chapter.
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>
