Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

onBufferChange on chrome is buggy

onBufferChange on chrome doesn't work properlly.

My code:

jwplayer('video-player').setup({
file: 'video.mp4?t=' + Math.random(),
width: '500px',
events:{
onBufferChange: function(e) {
console.log(e.bufferPercent);
}
}
});

Note that every time this runs, the video URL is different so I don't use a possibily cached version of the video.

On firefox I get many log events in the console:
11
18
21
32
39
46
50
60
71
74
81
88
99
100

On chrome I only get:
100

And the worst part about jwplayer in chrome is that I'm getting this 100 at a very early stage of the prebuffering. By looking at the network tab in dev tools, I'm getting it when the first part of the mp4 finishes (with a 206 partial content response code) which is very very early. After that another part (or more parts) are downloaded, but the onBufferChange with "100" has already fired.

Thus, in Chrome, I don't really know when the video file has finished buffering.

Is this fixable?

13 Community Answers

Up Down

Cooper Reid

JW Player Support Agent  
0 rated :

Is your player showing in HTML5 mode or Flash mode for each of those browsers?
-Cooper

Up Down

ewqewq

User  
0 rated :

Both in Chrome and Firefox it says "About JW Player 6.10.4906 (Pro edition)".

I've also tried with the latest JW Player version and the problem is the same.

Up Down

Cooper Reid

JW Player Support Agent  
0 rated :

Interesting – can we have a link to your page so we can troubleshoot/confirm the issue?
Cooper

Up Down

jc

User  
0 rated :

Here is a minimal page which reproduces the problem.

https://dl.dropboxusercontent.com/u/2540358/temp/jwplayer/index.html

Visit the page, open dev tools on the console tab and press play on JW Player. On chrome you'll quickly see the 100 (and just 100), but if you then go to the network tab (media tab) you'll see that the mp4 file is still downloading.
Firefox works as expected.

Up Down

Cooper Reid

JW Player Support Agent  
0 rated :

I just tested this locally, and it appears the issue has been resolved in JW6.12. You can download 6.12 from your account: https://account.jwplayer.com/#/account
Cooper

Up Down

jc

User  
0 rated :

Unfortunatelly I do not confirm.

In https://dl.dropboxusercontent.com/u/2540358/temp/jwplayer/index612.html I load JW6.12.4945 and still the result is the same. I get one and only one callback execution, with the value 100, and this happens way before the whole video is downloaded to the browser in Chrome 40.

Up Down

Cooper Reid

JW Player Support Agent  
0 rated :

You’re using deprecated syntax. I tested with this and it’s working for me in Chrome 40.0

jwplayer(“player”).setup({
file: ‘bunny.mp4’,
image: ‘bunny.jpg’,
width:‘100%’,
primary: ‘flash’
});

jwplayer().onBufferChange(function(e) {
console.log(e.bufferPercent);
});

-Cooper

Up Down

jc

User  
0 rated :

Sorry, nothing changed again. Callback is called only once with "100" and very very early.

see https://dl.dropboxusercontent.com/u/2540358/temp/jwplayer/index612-new-syntax.html where I've pulled the onBufferChange event outside as in your example.

By "deprecated syntax" you mean that I don't use "primary: flash"? Because I'd like to use HTML5 and have correct buffer change events on chrome.

Up Down

Cooper Reid

JW Player Support Agent  
0 rated :

I meant that this syntax

jwplayer().setup({
//events parameter
events: {
onSomeEvent: function() {

} }

})

is deprecated -

I believe this issue has to do with the way that the mp4 is being served. I just tested several mp4’s being served locally and the buffer % is reported perfectly.

Cooper

Up Down

jc

User  
0 rated :

When you say locally, you mean under the file:// protocol? Did you get any other valye apart "100"?

My sample is served via dropbox (they use nginx), and I experience the exact same behavior when served via apache 2.2.

Up Down

jc

User  
0 rated :

And BTW, do you reproduce the problem on chrome 40 at https://dl.dropboxusercontent.com/u/2540358/temp/jwplayer/index612-new-syntax ?

Up Down

jherrieven

User  
1 rated :

Seems your particular video file, used in conjunction with Chrome is either too small or too well optimised in order for it to report incremental buffer events. It is downloading instantly.

Try loading the following in the console of your same demo:

jwplayer().load([{"file":"https://content.jwplatform.com/videos/HkauGhRi-1280.mp4", "type":"mp4"}])

Now you'll see Chrome reporting buffer events.

James Herrieven

Up Down

jc

User  
0 rated :

Thanks jherrieven for poping into this thread and for your valuable input. My file is not small and not loading instantly. I test on a slow remote server and via throtling in chrome dev tools. The initial problem was discovered on a 15MB file which is much larger than your mp4 (8.8MB).

The good news is that after I inspected your mp4 and mine and found out that the problem is caused by the way my mp4 is encoded.

I use ffmpeg for encoding and I was missing the "-movflags +faststart" option. As noted in https://www.ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv this option allows for the metadata of the file to be placed at the start of the file, instead of at the end. This solves the problem for me.

Having said that I think that there should be a way to solve this on javascript level on JW. The fact that firefox doesn't have this problem on the same "problematic" mp4 served from the same server means that there should be a way, probably via a different js api, to figure out the total size of the file and correct current state of the download, which you could probably integrate into JW in order to solve this case in a safe way for all of your users. Thats because you cannot expect all users to be serving "streaming friendly" mp4 files. Note that the default option of ffmpeg (a very common encoder) is to have this disabled:

> -movflags faststart
> Run a second pass moving the index (moov atom) to the beginning of the file. This operation can take a while, and will not work in various situations such as fragmented output, thus it is not enabled by default.

If you don't plan on researching on this any further, you could just add a note on the onBufferChange documentation, and mention that for things to work smoothly on some browsers, a streaming friendly video needs to be supplied.

thanks

This question has received the maximum number of answers.