Fix spinner events about clappr HOT 9 CLOSED

It seems that clappr is not handling rebuffering events after the first one on html5 playback. Since we don't have events like flash's BUFFERING and BUFFER_FULL , I think that the best approach is to follow currentTime and buffered.end() values and figure out a good heuristics to define if the playback is stuck or not.

from clappr.

@flavioribeiro Are you testing the html5 playback with a mp4 or m3u8? Can you share the URL you are using for the tests?

It's possible that the stalled/waiting events are being discarded due to the readyState informing that the player has future data available. It could either be a bug on the html5 playback or a weird browser behavior.

from clappr.

yes, I'm trying with mp4 and the main problem is indeed with media api (video tag behavior). I'm gonna try to suggest something here in a pr.

from clappr.

@flavioribeiro Seems to be a bug on Chrome and other Chrome based browsers. Other browsers such as Safari and Firefox trigger the stalled and waiting events normally. Analyzing further, Chrome apparently doesn't set the element readyState correctly as well. It really looks like we can't work around it.

from clappr.

indeed there's an old bug (2011) which was not solved yet. I found this stackoverflow thread also. I think that a "good" workaround is to look if currentTime >= buffered.end(buffered.length -1) and if so, dispatch the buffering event. We could check it every timeupdate or progress event, for example. What do u think about it?

from clappr.

I think it could work well. I'd rather use the progress event to track this, only to be sure it will be called whenever there's change on network activity.
Using timeupdate might break more easily if it stops being called whenever data is not ready on the buffer.

from clappr.

something like this might work. I made some tests using charles and it worked fine, however there's some entropy on the numbers reported when the bandwidth is floating right in the same rate of the video (there's some cases where the browser says it has 3 seconds of buffered video but it keeps stuck). To summarize, this snippet should solve 90% of the cases.

diff --git src/playbacks/html5_video/html5_video.js src/playbacks/html5_video/html5_video.js
index 4424ecb..e47affe 100644
--- src/playbacks/html5_video/html5_video.js
+++ src/playbacks/html5_video/html5_video.js
@@ -198,9 +198,20 @@ class HTML5Video extends Playback {
         break
       }
     }
+    this.checkPlaybackState()
     this.trigger(Events.PLAYBACK_PROGRESS, this.el.buffered.start(bufferedPos), this.el.buffered.end(bufferedPos), this.el.duration, this.name)
   }

+  checkPlaybackState() {
+    if (this.el.currentTime >= this.el.buffered.end(this.el.buffered.length - 1)) {
+      this.trigger(Events.PLAYBACK_BUFFERING, this.name)
+      this.buffering = true
+    } else if (this.buffering === true) {
+      this.trigger(Events.PLAYBACK_BUFFERFULL, this.name)
+      this.buffering = false
+    }
+  }
+
   typeFor(src) {
     return (src.indexOf('.m3u8') > 0) ? 'application/vnd.apple.mpegurl' : 'video/mp4'
   }

from clappr.

Maybe instead of checking this.el.buffered.length -1, you should use bufferedPos. If the user seeks back to a unbuffered position and the player stalls, checkPlaybackState() would not set the buffering state correctly.

from clappr.

yes, you are right! I'm gonna change this and submit a pull request.

from clappr.