This is upgrades rollup and uglify to latest versions. It also rewrites the rollup config to take advantage of the newest features of rollup. Minification is also split up into a separate process, mostly to speed up the build. The total build type can go down from about 2.5 minutes to around 1 minute for all the generated javascript files.
Makes it easier to extend the seekbar and change the default event handlers. If you extend the seekbar component you can choose to override setEventHandlers_ or keep it default. If you do override setEventHandlers_ and call super() in the constructor, you get your own event handlers + the functionality provided by Slider.
There is no need to listen for user activity until a play is requested on the player and it just adds an extra timer for a player that hasn't started playing yet. Instead, just wait till the first `play` event.
Closes#5076.
SourceHandlers that use MSE have a problem: if they push a segment into a SourceBuffer and then seek close to the end, playback will stall and/or there will be a massive downswitch in quality. The general approach to fixing this that was discussed on slack was by setting the playback rate of the player to zero, buffering all that was required, and then restoring the previous playback rate. In my implementation, I've done this in the source handler (see: videojs/videojs-contrib-hls#1374).
From the video.js perspective, it should ensure that the UI reflects the buffering status and that the player API behaves like you'd expect -- that is to say, that it will fire seeking immediately after a call to currentTime, and it will fire seeked, canplay, canplaythrough, and playing when everything is buffered.
In Chrome/Firefox/Safari appending a <source> element when the media element has no source, causes what we think of as a `sourceset`. These changes make our code actual fire that event.
This was found due to the work done in #4660. Basically we reload the video element twice on every source with preload set to auto. This can potentially cause the same data to be downloaded twice.
This PR is to add HLS playback support built into video.js for 7.0 via videojs-http-streaming (shorthand VHS). VHS is the next major version of videojs-contrib-hls that removes HLS Flash playback and includes some experimental DASH support (hence the rename). The purpose is to improve the out-of-the-box experience for video.js and allow cross browser HLS compatibility.
The proposed changes are to have the standard video.js browser and module scripts contain VHS and provide an alternate video.js browser script that does not contain VHS.
A video.js/core export is provided for importing without VHS.
If .load() is called, we don't know what the new source will be because of the asynchronous nature of the resource selection algorithm. However, we can know if the src attribute is set on the video element because that's what will be chosen. So, set the src property on the event object to be the src attribute or be the empty string. This matches how currentSrc works where it is an empty string when no source is set. So, when sourceset is triggered and src is "" in the event object, it means that the source is changing.
In addition, we're going to be releasing sourceset as an experimental feature so we could improve the API and make changes in minor releases.
This reverts commit 6fe7a9a.
The PR #4804, which fixes#4720, causes a regression #5005. When testing for the regression, the original issue is no longer reproducible so the fix should be backed out. If someone is still using the old version of chrome and seeing the behavior of #4720, they can continue using the versions of Video.js that contain the fixed made in #4804: 6.5.2, 6.6x, 6.7.x.
Fixes#5005.
If CSS Grid is available, the Captions Settings Dialog will use it for the layout to begin making it more responsive.
It will fallback to the current layout method if CSS Grid isn't available.
