Video.js: `waiting` event not firing

[shshaw]

Based on our discussion in #1225, I thought it'd be best to start a new issue since it's not directly related.

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, but other events are firing correctly. On the JSBin example, I do see the waiting being fired.

I moved the same code from localhost to a server, and I still am not getting the waiting event to fire.

Let me see if I can simplify/reduce the code and replicate it to be able to provide an example.

Edit: I can get it to fire occasionally, but it is not firing whenever the video is actually buffering.

[heff]

You might also test a bare video element's events to make sure, though it really shouldn't work any differently.

Also you might want to also listen for other related events like stalled and suspend, incase the browser is running into other issues or just confused. This could very well be a browser bug we need to file.

[gkatsev]

waiting isn't supposed to be fired during a buffer, that's what stalled and suspend are for.
See http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents for more info.

[gkatsev]

We're using waiting in the newly added discontinuity support for hls.

[mmcc]

TIL :thumbsup:. Thanks for the clarification, @gkatsev.

[shshaw]

What event is supposed to be fired when the browser has stopped playing the video to buffer data?

According to the Media Events Summary on W3C:

• suspend is when the browser is intentionally NOT fetching content. In my tests, this gets fired while the browser is buffering normally, but choosing to wait to fetch more data.
• stalled is when the browser tries to fetch data, but doesn't get it. This is not fired when the browser is paused due to buffering, but perhaps when there's an error getting a response from the server.
• waiting seems like the most likely candidate ( Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course. ), but that isn't firing in this case either.

So I guess the question is: does the browser fire an event for buffering, or is my method of checking if the current time is updating while the status is not paused the best way to determine this?

[shshaw]

I ran some more tests, and it looks like this might be a Blink/Webkit issue.

• Firefox fires waiting when the video is buffering or after seeking to an unbuffered position, then fires canplay when it resumes playing automatically.
• Chrome and Safari fire waiting after seeking to a new position.
  
  
  
  • Safari fires canplay when it has enough data to play, but nothing fires when it resumes playing.
  
  
  • Chrome fires canplay when it resumes playing, but not in a buffering context.
  
  

I cannot get stalled to fire consistently, which I believe it only fires when there's issue with the browser receiving data from the server, but not in a buffering context.

Here's a simple JS Bin Example showing the events being fired. I've commented out the suspend event because it fires so much while the browser is loading normally. To simulate a slow connection, I'm using SpeedLimit on the host "ellcreative.com".

[heff]

Yeah, waiting is what I would expect for buffering. The waiting preconditions:

readyState is equal to or less than HAVE_CURRENT_DATA, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for other reasons without paused being false, but those reasons do not fire this event (and when those situations resolve, a separate playing event is not fired either): e.g. the element is newly blocked on its media controller, or playback ended, or playback stopped due to errors, or the element has paused for user interaction or paused for in-band content.

To me that sounds like waiting would be fired when the browser is buffering (waiting for the data for the current frame). And after it gets it a playing event should be fired.

However testing the jsbin it would seem that stalled is the event that gets fired. That could also be how my bandwidth throttler (Charles) is working. The difference in definition seems to only be whether or not the data is expected to be coming. stalled: "data is unexpectedly not forthcoming"

The worst thing seems to be that Chrome (and possibly Safari too) never fire an event that would allow us to know stalled has stopped. I remember having to remove stalled from the spinner events for that reason.

Chrome

Firefox

Safari

[shshaw]

@heff Great test results. Seems like each browser vendor is interpreting the Media Events spec differently. I still find it strange that there's no actual buffering event in the spec!

Agreed that the worst aspect is not knowing that the video has actually stopped playing, but no event is fired to indicate that. This is the reason I had to track the video's current time while the video is not paused to see if the video was buffering.

[heff]

Actually the ‘progress’ event is for buffering. I guess we could be using that to know that stalled has cleared.

On July 2, 2014 at 6:46:53 AM, Shaw ([email protected]) wrote:

@heff Great test results. Seems like each browser vendor is interpreting the Media Events spec differently. I still find it strange that there's no actual buffering event in the spec!

Agreed that the worst aspect is not knowing that the video has actually stopped playing, but no event is fired to indicate that. This is the reason I had to track the video's current time while the video is not paused to see if the video was buffering.

—
Reply to this email directly or view it on GitHub.

[norlin]

Is there any progress with that bug?

I'm using VJS 4.12 and see it's firing 'waiting' event only for very first buffering (when started to play video). But then in case of slow connection video stucks, but no any event fired, at least in Chrome.

[gkatsev]

Anyone had a chance to look at this with videojs 5?
I think that ultimately, it's up the browser (we have some control of it in the swf, I guess) on how and when to fire these events. waiting is fired when it's played back through all the data available and no longer has any more data to play. progress events fire when it's downloading more data. Browsers may or may not fire those reliably.
Though, I would wonder whether the browsers are more reliable now than they were back then.
To reliably know that the video has stopped playing back, you probably would want to listen to timeupdate and propgress events and set a timer each time (we do that in the videojs-errors to throw an error if nothing has been playing in 45 seconds).

I dont think there's much we can do in videojs. Closing this issue but if you have questions or comments, please add them.