Chrome loader really slow

[video-dev]

Chrome loader really slow

[mangui]

@DannyZB
hls.js just uses a standard XHR... i don't see how you could have a chrome specific issue ?
maybe a chrome extension is messing up ?

regarding your video, are you testing with latest hls.js/master ?
I just tested on FF/OSX and it is working fine, there is no request loop.
http://dailymotion.github.io/hls.js/demo/?src=https%3A%2F%2Fnl3.seedr.co.il%2Fmedia%2Fvideo%2Flq_hls%2Fc4d55aafa6a931fe63619e48e699ee759dc0f7d4%2Fvid.m3u8

[DannyZB]

I ran it through chrome incognito ( i.e no extensions ) and download speeds are still subpar.
Really baffled at what can cause this.

Looks to me like something in the request is triggering some mechanism.

What version of chrome did you use ?

[DannyZB]

http://i.imgur.com/HJs7Dqe.png?1

you can see the ridiculous loading times .. make absolutely no sense.
Direct-downloading those segments ends in a fraction of a second

For perspective, I am connected from a 100mbit connection , and the server :
Selecting best server based on latency...
Hosted by SoftLayer Technologies, Inc. (Amsterdam) [0.77 km]: 2.109 ms
Testing download speed........................................
Download: 875.40 Mbit/s
Testing upload speed..................................................
Upload: 373.93 Mbit/s

Looks like there is ample bandwidth on both ends

[mangui]

my Chrome UA is
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

the frag XHR is performed here: https://github.com/dailymotion/hls.js/blob/master/src/utils/xhr-loader.js#L46-L57

[DannyZB]

Do you have a unit-test for fragment loading ?
I think one would be in order .. browsers sometimes really muck things up

config.xhrSetup -> where is the code for that ?
I'm trying to write a short test script to isolate the cause

p.s. we run the same chrome version

[DannyZB]

Ok I've run a simple test :
function runxhr(url) {
var xhr = new XMLHttpRequest();
xhr.open('GET', url, true);
xhr.send();
}

runxhr('https://nl3.seedr.co.il/media/video/lq_hls/c4d55aafa6a931fe63619e48e699ee759dc0f7d4/vid060.ts');

Seems to have the slow download issue.
Is it possible the chrome implementation of XHR is somehow limited ?

The speed is very noticably slower than speeds I get from simply downloading the file

[mangui]

mmm I doubt, we are testing chrome along with hls.js for a couple of months and we didn't observe loading performance issue.
we are able to load 4k stream without a glitch, tested on Chrome Desktop and Mobile/Android.

[DannyZB]

Tried restarting my PC, didn't solve anything.
How long does it take you to download segments of the sample stream i provided ? ( in incognito - to avoid caching )

This doesn't look to have anything to do with the stream bitrate as it's nowhere near the max connection throughput.

I also get 30KB/sec download speeds on your default stream.

p.s. : found the cause for redundant reloads :
buffer controller: fragLoadTimeOut while loading frag,switch to IDLE state ...
level-controller.js:109 switching to level 0
buffer-controller.js:261 Loading 91 of [0 ,212],level 0, currentTime:920.924273,bufferEnd:920.924

switching between a level to itself -- that stream only loads one level

[mangui]

you can check my timings here, using Chrome Incognito

http://dailymotion.github.io/hls.js/demo/metrics.html?data=dXJsfGh0dHBzOi8vbmwzLnNlZWRyLmNvLmlsL21lZGlhL3ZpZGVvL2xxX2hscy9jNGQ1NWFhZmE2YTkzMWZlNjM2MTllNDhlNjk5ZWU3NTlkYzBmN2Q0L3ZpZC5tM3U4fHQwfGxvYWR8dHlwZXxtYW5pZmVzdHxuYW1lfHN0YXJ0fGVuZHx0aW1lfGxhdGVuY3l8ZHVyYXRpb258bGV2ZWx8aWR8ZnJhZ21lbnR8aWQyfGRlbXV4fGJ1ZmZlcnxid3xzaXplfHBvc3x2aWRlb3xNU0UrYXR0YWNoZWR8aW5pdCtzZWdtZW50fGR1cmF0aW9uY2hhbmdlfHJlc2l6ZXw1NjYvMzIwfGxvYWRlZG1ldGFkYXRhfHNlZWtpbmd8c2Vla2VkfGZyYWcrY2hhbmdlZHwwK0ArMHxsb2FkZWRkYXRhfHBsYXl8cGxheWluZ3xmcmFnK2NoYW5nZWR8MStAKzB8ZnJhZytjaGFuZ2VkfDIrQCswfGZyYWcrY2hhbmdlZHwzK0ArMHxmcmFnK2NoYW5nZWR8NCtAKzB8ZnJhZytjaGFuZ2VkfDUrQCswfGJpdHJhdGV8aXNMaXZlXklGWk5YMVM2fDB8MXxBfDFWfDB8MHwwfDB8NVd8MkZ8SXwwfDB8MHwwfDM3fFh8Mzl8MUR8RXw1MHwxOVRCfFNNVDR8MHwxfDk5fEp8M3xFfDN8S3wyVzNIfDc4OE98MHwyfEFFfEp8S3xJfEN8MUV8MlNPTnxISEEwfDB8M3wxQkl8WXwySXxKfDR8MzV8MTUxRXxHM08wfDB8NHw5RTh8VnwySnw5fDJ8MlV8MURTRHxITVNHfDB8NXxHMUt8V3w3THxNfDR8OEJ8TTUwfE1aRkt8MHw2fFNWTHxXfDRCfDh8Mnw0THxDMUh8NldDR3wwfDd8VllPfFp8MVV8OXwxfDI0fDEzOVZ8QUQzS3wwfDh8MTNXOHxVfDE0fDV8MXwxQXxKU1l8MzVWR3wwfDB8MHxDMXxKMTJ8MTZ8RVN8TlRDfDNQfDFGRnxNU0t8MTRHfDFJOXxVUkF8MTcxfDlIMXxNUzl8OTYyfDlKVHxUREF8OThOfEc5WXxNTkZ8RllJfEdDUXxaNVN8RzFRfFNWTHxNTVl8U0tLfFROQXxQMzR8VENBfFZZUHxNUlh8Vk5JfFdBV3xVR1l8VlpSfDEzVzh8TVZIfDEzTDh8MTNaMHxUUFJ8MTNOVHwxNjZBfFJJRnwxNVY0fDFOfDhFfDhSfDE5UDNGfDhSfDhSfDB8OUF8MTZ8MTV8QUZ8MTZ8QUh8QUl8MTZ8QUl8MTZ8QUl8MTZ8REIxfEpGN3xQME18V0FVfDEyWUJ8MkN8MHw5NXwxOVRCfDB8QUN8MlczSHwwfENEfDJTT058MHwxRkx8MTUxRXwwfDlIWHwxRFNEfDB8R0FSfE01MHwwfFQxMnxDMUh8MHxXMVN8MTM5VnwwfDEzWUN8SlNZfDBeMTYuNzA5NDY2NjY2NjY2NjY4fDcuNzkxNjc3Nzc3Nzc3Nzc4fDYuMjMwMTc3Nzc3Nzc3Nzc5fDEwLjMzMzM0NDQ0NDQ0NDQ0Mnw4LjU0MTY3Nzc3Nzc3Nzc3OHwxNi4yNjA4MTExMTExMTExMXw0LjA4MzgzMzMzMzMzMzMzMXwxMC4zMzMzNDQ0NDQ0NDQ0MzV8OC44ODkxNTU1NTU1NTU1NDdeJDB8MXwyfDFCfDN8QCQ0fDV8NnwtNHw3fDFDfDh8MUR8OXwxRXxBfDFGfDN8MUd8QnwxSF18JDR8Q3xEfDFJfDd8MUp8OHwxS3w5fDFMfEF8MU18M3wxTnxCfDFPXXwkNHxFfER8MVB8RnwxUXw5fDFSfEF8MVN8M3wxVHxHfDFVfEh8MVZ8QnwxV3xJfDFYfEp8MVldfCQ0fEV8RHwxWnxGfDIwfDl8MjF8QXwyMnwzfDIzfEd8MjR8SHwyNXxCfDI2fEl8Mjd8SnwyOF18JDR8RXxEfDI5fEZ8MkF8OXwyQnxBfDJDfDN8MkR8R3wyRXxIfDJGfEJ8Mkd8SXwySHxKfDJJXXwkNHxFfER8Mkp8RnwyS3w5fDJMfEF8Mk18M3wyTnxHfDJPfEh8MlB8QnwyUXxJfDJSfEp8MlNdfCQ0fEV8RHwyVHxGfDJVfDl8MlZ8QXwyV3wzfDJYfEd8Mll8SHwyWnxCfDMwfEl8MzF8SnwzMl18JDR8RXxEfDMzfEZ8MzR8OXwzNXxBfDM2fDN8Mzd8R3wzOHxIfDM5fEJ8M0F8SXwzQnxKfDNDXXwkNHxFfER8M0R8RnwzRXw5fDNGfEF8M0d8M3wzSHxHfDNJfEh8M0p8QnwzS3xJfDNMfEp8M01dfCQ0fEV8RHwzTnxGfDNPfDl8M1B8QXwzUXwzfDNSfEd8M1N8SHwzVHxCfDNVfEl8M1Z8SnwzV118JDR8RXxEfDNYfEZ8M1l8OXwzWnxBfDQwfDN8NDF8R3w0MnxIfDQzfEJ8NDR8SXw0NXxKfDQ2XV18SHxAJDl8NDd8SHw0OHxLfDQ5XXwkOXw0QXxIfDRCfEt8NENdfCQ5fDREfEh8NEV8S3w0Rl18JDl8NEd8SHw0SHxLfDRJXXwkOXw0SnxIfDRLfEt8NExdfCQ5fDRNfEh8NE58S3w0T118JDl8NFB8SHw0UXxLfDRSXXwkOXw0U3xIfDRUfEt8NFVdfCQ5fDRWfEh8NFd8S3w0WF18JDl8NFl8SHw0WnxLfDUwXXwkOXw1MXxIfDUyfEt8NTNdfCQ5fDU0fEh8NTV8S3w1Nl18JDl8NTd8SHw1OHxLfDU5XXwkOXw1QXxIfDVCfEt8NUNdfCQ5fDVEfEh8NUV8S3w1Rl18JDl8NUd8SHw1SHxLfDVJXV18THxAJDl8NUp8NHxNXXwkOXw1S3w0fE5dfCQ5fDVMfDR8T3w2fDVNXXwkOXw1Tnw0fFB8NnxRXXwkOXw1T3w0fFJ8Nnw1UF18JDl8NVF8NHxTfDZ8NVJ8Qnw1U118JDl8NVR8NHxUfDZ8NVVdfCQ5fDVWfDR8VXw2fFZdfCQ5fDVXfDR8V3w2fDVYXXwkOXw1WXw0fFh8Nnw1Wl18JDl8NjB8NHxZfDZ8NjFdfCQ5fDYyfDR8Wnw2fDEwXXwkOXw2M3w0fDExfDZ8MTJdfCQ5fDY0fDR8MTN8NnwxNF18JDl8NjV8NHwxNXw2fDE2XXwkOXw2Nnw0fDE3fDZ8MThdXXxDfEAkOXw2N3xEfDY4fDE5fC0zXV18MTl8QCQ5fDY5fDE5fDZBfEJ8NzB8Q3w2Ql18JDl8NkN8MTl8NkR8Qnw3MXxDfDZFXXwkOXw2RnwxOXw2R3xCfDcyfEN8NkhdfCQ5fDZJfDE5fDZKfEJ8NzN8Q3w2S118JDl8Nkx8MTl8Nk18Qnw3NHxDfDZOXXwkOXw2T3wxOXw2UHxCfDc1fEN8NlFdfCQ5fDZSfDE5fDZTfEJ8NzZ8Q3w2VF18JDl8NlV8MTl8NlZ8Qnw3N3xDfDZXXXwkOXw2WHwxOXw2WXxCfDc4fEN8NlpdXXwxQXwtMl0=

[DannyZB]

Interesting ...
Maybe chrome is very sensitive to some system conditions.
For some reasons it's not as bad for me at the moment, still at 760kbit/sec though

openlayers/openlayers#797

Maybe related ?
I'm a bit baffled at why I would have high connection speeds / download speeds from the same servers , yet slow XHR.
What can affect XHR speed ?

It looks to me like chrome finishes downloading in 2-3 seconds, yet the segment isn't reported as downloaded for another 15 for some reason

[mangui]

then u can monitor xhr.onprogress to check your assumption

[DannyZB]

Yes , will do
Just tested on chrome canary and it's not affected , neither is firefox.
A specific scenario is causing this .

function runxhr(url) {
    var xhr  = new XMLHttpRequest();

    var t = performance.now();
    var last_loaded = 0;
    xhr.onprogress = function(e) {
        if (e.lengthComputable) {
            console.log((e.loaded / e.total *100).toFixed(2) + '% loaded');
            console.log( ((e.loaded-last_loaded) / ( performance.now()-t ) * 1000/1024).toFixed(2) + 'kb/sec');
        } else {
            console.log('size unknown');
        }

        last_loaded = e.loaded;
        t = performance.now();
    }

    xhr.open('GET', url, true);
    xhr.send();
}

runxhr('https://nl3.seedr.co.il/media/video/lq_hls/c4d55aafa6a931fe63619e48e699ee759dc0f7d4/vid035.ts');

The results :
3.91% loaded
VM332:11 23.17kb/sec
VM332:10 7.82% loaded
VM332:11 32.51kb/sec
VM332:10 11.73% loaded
VM332:11 31.18kb/sec
VM332:10 15.64% loaded
VM332:11 30.96kb/sec
VM332:10 19.54% loaded
VM332:11 31.07kb/sec
VM332:10 23.45% loaded
VM332:11 31.04kb/sec
VM332:10 27.36% loaded
VM332:11 31.07kb/sec
VM332:10 31.27% loaded
VM332:11 30.96kb/sec

[tjenkinson]

I'm pretty sure you'll have checked this but for what it's worth you've definitely got bandwidth throttling turned off in the dev tools?

On 20 Oct 2015, at 19:24, Daniel Batkilin [email protected] wrote:

2.7723536239927715% loaded
VM305:11 23.71916508538901kb/sec
VM305:10 5.544707247985543% loaded
VM305:11 32.48120911300931kb/sec
VM305:10 8.317060871978315% loaded
VM305:11 31.11130555677099kb/sec
VM305:10 11.089414495971086% loaded
VM305:11 31.107222708272666kb/sec
VM305:10 13.861768119963857% loaded
VM305:11 31.00189402196291kb/sec
VM305:10 16.63412174395663% loaded
VM305:11 30.98838419786093kb/sec
VM305:10 19.4064753679494% loaded
VM305:11 31.056352722525986kb/sec
VM305:10 22.178828991942172% loaded
VM305:11 31.055900621118187kb/sec
VM305:10 24.95118261593494% loaded
VM305:11 32.42739304027078kb/sec
VM305:10 27.723536239927714% loaded
VM305:11 31.127193494416534kb/sec
VM305:10 30.495889863920482% loaded
VM305:11 31.031055298310086kb/sec
VM305:10 33.26824348791326% loaded
VM305:11 31.052886948083454kb/sec
VM305:10 36.040597111906024% loaded
VM305:11 30.886391166492118kb/sec
VM305:10 38.8129507358988% loaded
VM305:11 31.172980818875054kb/sec
VM305:10 41.585304359891566% loaded
VM305:11 32.4032585526882kb/sec
VM305:10 44.357657983884344% loaded
VM305:11 31.107071512241067kb/sec
VM305:10 47.130011607877115% loaded
VM305:11 31.009104079150685kb/sec
VM305:10 49.90236523186988% loaded
VM305:11 31.05921633714777kb/sec
VM305:10 52.67471885586266% loaded
VM305:11 31.06992188827457kb/sec
VM305:10 55.44707247985543% loaded
VM305:11 30.937752275616727kb/sec
VM305:10 58.21942610384819% loaded
VM305:11 31.111154321047678kb/sec
VM305:10 60.991779727840964% loaded
VM305:11 32.51503820516977kb/sec
VM305:10 63.76413335183374% loaded
VM305:11 30.92116070306991kb/sec
VM305:10 66.53648697582652% loaded

That's the result I got from the test
Hovering around 30kb/sec always , even after computer restart

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

[DannyZB]

Checked that , it's turned off.

Makes perfect sense, though - if chrome has some messed up config that's throttling without reason it would cause this issue without ability to replicate.

In any case , I can't make this happen anywhere else , probably not worth the effort at this point.

[mangui]

@DannyZB I am closing the ticket as it really looks like you have an environment issue.
feel free to reopen it if you have more clues and suspect a Chrome generic isssue.

[DannyZB]

Ok sure..
The issue in firefox is separate btw, it was related to an unstable network when it was trying to switch streams when no other streams existed - there was only one quality level.
I'll do some testing and open a separate ticket for it.

Are you consdering merging this with the native Apple HLS implementation and your own FlashLS Chromeless ?

Those three can be a basis for a true cross-platform HLS player , I would be interested in participating in such a project.