Codecov Report

Merging #1142 (99dd2d9) into main (0f35f7e) will increase coverage by 0.00%. The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1142   +/-   ##
=======================================
  Coverage   86.45%   86.46%           
=======================================
  Files          39       39           
  Lines        9489     9492    +3     
  Branches     2189     2190    +1     
=======================================
+ Hits         8204     8207    +3     
  Misses       1285     1285           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 0f35f7e...99dd2d9. Read the comment docs.

Description

Set a default for the option MaxPlaylistRetries (default should have been Infinity, seems like there was a bad merge)

Requirements Checklist

• [ ] Feature implemented / Bug fixed
• [ ] If necessary, more likely in a feature request than a bug fix
  • [ ] Unit Tests updated or fixed
  • [ ] Docs/guides updated
  • [ ] Example created (starter template on JSBin)
• [ ] Reviewed by Two Core Contributors

也遇到了这个问题，有没有解决方案

可以试着卸载 @videojs/http-streaming video.js 7.x包含了这个库: https://blog.videojs.com/video-js-7-is-here/

If the ad controller wraps the entire UI, there would need to be a new set of controls that fire ad specific events so that the ad controller could differentiate between the content actions and ad actions.

Had more thoughts on this one, incase UI level integrations are still a direction we need to go. I don't know that we would need ad specific UI events here. The ad-controller could add event listeners to media-play-request and other events, and preventDefault to block further actions when needed (similar to how the IMA SDK works). This is a benefits of having every request funneled through the controller now rather than UI elements talking directly to the media element. Then the ad-controller can rely on its own current media-ad-playing state to determine if UI events should apply to the ad or the media.

There does seem to be a key long term implication to consider here, which is whether or not <media-controller> base media states (e.g. media-duration, media-current-time) are updated to reflect the ad state or maintain the primary media's state. For example if media-current-time is updated to reflect the ad's current time, then external elements now need to be "ad-aware". For example an external text transcript that's following along with the video. Or just a captions element. I think the answer is we don't want that.

(this is very complicated... sorry for the all the long exploratory comments)

Pulling from various ideas, here's a proposal...

1. Add first-class ad states to media-controller

<media-controller media-ad-playing media-ad-duration="100" media-ad-current-time="10" ...>

2. media-controller listens for ad-events on the media element, and updates ad state accordingly

<media-controller media-ad-playing>
  <jw-player></jw-player> <!-- media element with internal ads -->
</media-controller>

3a. A UI-level client-side ad integration can wrap media-controller and update its ad state accordingly.

The ad integration element can listen for a media-play-request on media-controller and preventDefault to block media playback and play an ad.

<media-ima-ads>
  <media-controller media-ad-playing>
    <video></video>
  </media-controller>
</media-ima-ads>

3b. A UI-level client-side ad integration could also wrap the media element, taking the the place of the media and exposing the html5 video API.

<media-controller media-ad-playing>
  <ima-video slot="media">
    <hls-video></hls-video>
  <ima-video>
</media-controller>

4a. For all cases, controls could then be built with a special control bar (Matt's idea) that translates events/states

<media-controller>
  <video></video>
  <media-control-bar> <!-- control bar for media -->
    <media-play-button />
  </media-control-bar>
  <media-ad-control-bar> <!-- control bar for ads (special) -->
    <media-play-button />
  </media-ad-control-bar>
</media-controller>

4b. For the media-controller wrapping ad integration case, controls could also optionally live outside the media-controller, and not require a special control bar.

<media-ima-ads>
  <media-controller media-ad-playing>
    <video></video>
    <media-control-bar /> <!-- control bar for media -->
  </media-controller>
  <media-control-bar /> <!-- control bar for ads (not special) -->
</media-ima-ads>

Thoughts on that?

Description

When using native HLS in Safari, the qualityLevels() collection never gets populated. Doing some debugging, it appears that a lot of the internal methods that populate this collection never gets called.

Disabling native hls allows the qualityLevels to get populated

html5: {
	vhs: {
		overrideNative: true,
	},
	nativeAudioTracks: false,
	nativeVideoTracks: false,
},

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

1. Load a player with the videojs-contrib-quality-levels plugin enabled and an adaptive streaming playlist set as the source
2. Check the player's .qualityLevels() property, it will be empty.

Results

Expected

The qualityLevels() should return an array of the different Representations.

Actual

qualityLevels() returns an empty array.

versions

videojs

7.11.8

browsers

Safari

OSes

MacOS

plugins

videojs-contrib-quality-levels v2.1.0

Also, worth noting that you can't run non-native HLS on iPhones,

Thanks for that bit of info! I think that is the decider for us 😄 We'll need to try something clever with our quality chooser instead.

Cool, yeah, these types of things are generally a problem of the plugin. Have been busy so I couldn't look at it.

Sort of both. The risk is likely not that big at this point (it used to be much bigger a long time ago). If you test your stream, and it works for you, I wouldn't worry too much. Also, worth noting that you can't run non-native HLS on iPhones, though, you can on iPads. This is a platform limitation.

should we use rollup-plugin-stub in tests to prevent having to remove stuff from the main build? This is what we do in video.js https://github.com/videojs/video.js/blob/main/test/unit/player.test.js#L947-L955

test('Calling exponential moving average won\'t decay average unless new bandwidth data was provided', function(assert) {

Most uses of videojs-generator-rollup-config return Object.values(config.builds), since objects store keep insertion ordering, it means that tests get built before the browser builds.

Instead, build the regular build first, which will reduce time to wait for testing against the local index.html examples.

By default, Safari uses the native playback engine. Safari doesn't provide the ability to switch renditions. If you need to use quality-levels on Safari, you'll need to overrideNative,

Thanks for that confirmation. I was thinking about it more and it started to make sense why it wasn't working.

though, I would recommend running HLS natively on Safari. We don't test our playback engine on Safari on a regular basis.

Is this just a matter of things may break with a future update and not be caught immediately? Or there may be cases currently where something may be broken and nobody has noticed yet?

Just trying to get an idea of the actual risk of running non-native HLS in safari. We'd really like our player to look the same across platforms if possible, and if necessary (if non-native HLS is really a bad idea) we'll need to put in some special cases for our quality chooser.

Description

Hello VideoJS maintainers, I am developing with VideoJS and I am using the silvermine chromecast plugin (that you refer to yourselves). Whether the problem I am facing is related to videoJS or the plugin itself is beyond me, however. I have an issue thread up on the chromecast repo, but I will briefly explain what is going on here as well. First, the reduced test case, I am quite new to web development myself (approx 6 months so far), so bear with me as I try to elaborate on this. I am developing a web app that includes dynamically loaded and disposed videoplayers, and this has been working excellently for me so far (I am utilizing your angular component to create and destroy players as I go). The issue pertains to event listeners not detaching themselves properly on player.dispose(), causing memory leaks and clogging up my console.

Steps to reproduce

1. Go to the reduced test case (duh), make sure you have a casting device available or the plugin won't fire (you do not need to cast, the plugin simply needs to load).
2. Press play. Pause the movie if you want, this is irrelevant.
3. Open the console log.
4. Press the mute button, I have wired it to cause the player to dispose.
5. Tab to another browser tab or change application completely (make sure you cannot visually see the test case page with the now dismantled player).
6. Tab back in to the browser tab with the player gone. Check the console log. An error similar to this should appear

Results

See steps to reproduce

Expected

Console log should be empty because the event listeners should be gone.

Actual

Event listeners are processing requests from the cast API framework to a removed player, thus causing it to produce aforementioned error.

Error output

See steps to reproduce

Additional Information

I found a similar thread upon searching for this specific issue, and therefore I thought it would be warranted to at least notify you about this problem. The actual code that should add/remove event listeners for the plugin is located at @silvermine/videojs-chromecast/src/js/chromecast/ChromecastSessionManager.js, on lines 40 through 80:

   init: function(player) {
      this.player = player;
      this._addCastContextEventListeners();

      // Remove global event listeners when this player instance is destroyed to prevent
      // memory leaks.
      this.player.on('dispose', this._removeCastContextEventListeners.bind(this));
      this._notifyPlayerOfDevicesAvailabilityChange(this.getCastContext().getCastState());
      this.remotePlayer = new cast.framework.RemotePlayer();
      this.remotePlayerController = new cast.framework.RemotePlayerController(this.remotePlayer);
   },

   // Add event listeners for events triggered on the current CastContext.
   _addCastContextEventListeners: function() {
      var sessionStateChangedEvt = cast.framework.CastContextEventType.SESSION_STATE_CHANGED,
          castStateChangedEvt = cast.framework.CastContextEventType.CAST_STATE_CHANGED;

      this.getCastContext().addEventListener(sessionStateChangedEvt, this._onSessionStateChange.bind(this));
      this.getCastContext().addEventListener(castStateChangedEvt, this._onCastStateChange.bind(this));
   },

   // Remove event listeners that were added in _addCastContextEventListeners}.
   _removeCastContextEventListeners: function() {
      var sessionStateChangedEvt = cast.framework.CastContextEventType.SESSION_STATE_CHANGED,
          castStateChangedEvt = cast.framework.CastContextEventType.CAST_STATE_CHANGED;

      this.getCastContext().removeEventListener(sessionStateChangedEvt);
      this.getCastContext().removeEventListener(castStateChangedEvt);
   },

I can confirm that this code indeed gets called upon dispose, but the event listeners do not get removed. I would very much appreciate to know if I am mis-using the player, the plugin or the framework in some way, but at this point I am starting to believe that there is some other problem going on.

I also fully understand if you do not recognize this as an issue because it is the event listeners of a plugin that do not get removed properly. If you firmly believe that the problem lies with the plugin, then this can be closed.

versions

videojs

Latest and 7.10.2, both produce the same error.

browsers

Chrome: 91.0.4472.101

OSes

Windows 10

plugins

Chromecast plugin: 1.3.1

Thank you for your time, as well as your time spent developing Video.js! Regards, Daniel

Found the issue, see the referenced thread in the other repo. Closing this, sorry for the inconvenience.

hi, can i get the sei info by muxjs? or should i get it by myself?

@brandonocasey Thanks a lot.

Got it, I see now. Thanks for clearing that up.

One thing I'm feeling through all of this is media-controller probably needs a set of defined ad events, to at least be able to proxy ad state. But otherwise, I think we might need to break up the different ad situations into their own problem sets, because they might need to be solved differently. Let me try to enumerate them...

Server-side ads

The media element itself needs to be able to emit standardized ad events at minimum, if not other functions like blocking scrubbing, handling clicks on the ad, and sending ad click reports.

Client-side ads

Client-side ads via an ad-supporting media element, e.g. <theo-player> or <video-js>

The media element needs to emit standardized ad events, or it can just handle the ad UI internally (not ideal, but an option).

Client side ads via a custom media-chrome element integration

All the options we've discussed... but new questions

• Is a downside that you could simply delete the ad-controller element to remove ads?
• If the video el lives in the shadow dom, can you still pass it to the IMA sdk that's not in the shadow dom?

After laying that out...I think ad playback might need to live in the media element, while ad UI can live in media-chrome. Everything gets pretty complex if we try to let the ad integration live in the UI layer. Whereas if we can separate ad playback from ad UI, then media-chrome can still play to its strengths. And we're going to have to support media-els-with-ads either way, unless we're going to force you to use the media-chrome ad integration, and I don't love that.

At its simplest it might look like <video-ima> as a media element that also emits standardized ad events, but doesn't worry about UI. Then media chrome passes state like media-ad-playing, that the UI can be built around.

The downside would be that you can't just easily add ad support at will to any media element like <hls-video> or <youtube-video>. Is there a way to make that easy? Or is that ok, at least for v0 of media-chrome? Am I missing anything else major?

Most uses of videojs-generator-rollup-config return Object.values(config.builds), since objects store keep insertion ordering, it means that tests get built before the browser builds.

Instead, build the regular build first, which will reduce time to wait for testing against the local index.html examples.

Wrote a test for this https://github.com/videojs/http-streaming/pull/1141 Once the other PR passes review (I'm doing something I'm unsure about) I'll get all the stuff merged in.

Description

Video.js recently added new functionality for autoplay that triggers autoplay-success or autoplay-failure events depending on the result of the autoplay attempt. However, that functionality relies on the initial play promise being resolved/rejected naturally, so it is not compatible with the contrib-ads callPlay() middleware which terminates the first play request.

This PR adds an option to bypass that play termination if the player intends to autoplay. It does this by conditionally setting _shouldBlockPlay to false in the BeforePreroll state if the option is true and player.autoplay() is truthy.