Add vjs-waiting class when waiting. Update loading spinner to use it.

[heff]

The player should listen for waiting events and add the the vjs-waiting class, then listen for playing events to remove it. Similar to the onPlay function in the player.
https://github.com/videojs/video.js/blob/v4.5.1/src/js/player.js#L434
https://github.com/videojs/video.js/blob/v4.5.1/src/js/player.js#L95
The class should also be removed on the loadstart event (new source).

At the same time the loading spinner should be updated to use that classname to show itself when waiting, instead of using the hide/show methods.

Related issues: #684, #733, #518, #586

[shshaw]

I ran into this issue of trying to tell when the video is buffering since vjs doesn't fire a waiting event. My solution within the current vjs setup was attaching a check to the progress event.

var lastTime = 0;

myVideo.on("progress",function(){
      // As video downloads, check if the video is actually playing.
      // (this.paused() will return true even if it's buffering, so we have to check the time advancement)
      var currentTime = this.currentTime();

      if ( lastTime !== currentTime ) {
        // Update the lastTime if the time has changed.
        lastTime = currentTime;
      } else if ( this.paused() === false ) {
        // Video is buffering/waiting.
      }
});

For my purposes, I pause the video and resume after a certain amount has buffered.

var lastTime = 0,
    lastBuffer = 0,
    buffered = false,
    bufferPause = false;

myVideo.on("progress",function(){
      // As video downloads, check if the video is actually playing.
      // (this.paused() will return true even if it's buffering, so we have to check the time advancement)
      var currentTime = this.currentTime();

      if ( lastTime !== currentTime ) {
        // Update the lastTime if the time has changed.
        lastTime = currentTime;
      } else if ( this.paused() === false ) {
        // Video is buffering/waiting.
        buffered = false;

        // If we haven't already paused the video, pause it so the video isn't attempting to replay all the time
        this.pause();
        bufferPause = true; // To indicate pause was initiated by this buffer check

        // Cache the last buffered percent so we can see how much is loaded
        lastBuffer = this.bufferedPercent();
      } else if ( !buffered && ( this.bufferedPercent() - lastBuffer > 0.2 || this.bufferedPercent() > 0.9 ) ) {
        buffered = true;
        // Resume playing if an additional 20% has been buffered.
        if ( bufferPause ) { this.play(); }
      }
}).on("play",function(){
      // Ensure that bufferPause is reset
      bufferPause = false;
});

Not sure if this might be helpful for cross-browser support (no idea if all HTML5 Video browsers fire the waiting event) or the Flash player.

[heff]

That's an interesting way to do it. What was the specific case (including browser info) where you were expecting waiting to fire and it didn't? Video.js does fire a waiting event when the underlying tech does, and HTML5 browsers should be firing the event in the case you appear to be solving for.
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#event-media-waiting

[shshaw]

Really? I'm currently testing locally in Chrome 35 and using speedlimit to simulate a slow connection.

I tried myVideo.on("waiting", ...) but the event never fired. myVideo.addEventListener("waiting", ...) returns undefined is not a function. Is there another method to listen for the waiting event?

[heff]

Open this JSbin, click the "console" at the top and then "run with JS", and make sure you're seeing "waiting fired".
http://jsbin.com/zubig/1/edit

You got the play an progress events working, so I don't think you're listening to events wrong. Do you have a live example or reduced test case available?

[shshaw]

Yes. Waiting fired hits in the console of the JS Bin you provided. Maybe it has something to do with localhost. I'll push to the server and test again.

[mmcc]

@shshaw let us know what you see from the non-localhost test.

[shshaw]

@mmcc Since this is separate from the original issue, I've started a new issue #1318 where I have posted some more tests and results.

[mmcc]

Ah right. Appreciate it!

[heff]

This one was closed by #1351, if anyone wants to try it out.