Closed DannyZB closed 9 years ago
@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
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 ?
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
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
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
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
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.
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
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
https://github.com/openlayers/openlayers/issues/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
then u can monitor xhr.onprogress to check your assumption
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
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 notifications@github.com 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.
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.
@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.
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.
My chrome browser ( latest/OSX ) loads fragments at 16kb increments always regardless of the source/server throughput, which is really really slow.
Any knowledge on that issue ? looks like it's JS related
p.s. looks like a promising project !
manifest : https://nl3.seedr.co.il/media/video/lq_hls/c4d55aafa6a931fe63619e48e699ee759dc0f7d4/vid.m3u8
On firefox it fires an endless amount of requests for no apparent reason - not really sure why, and please note the server runs over nginx/HTTP/2 if it's in any way relevant. I've tried turning off http/2 but that didn't help either
The server has 200mbit/sec available and should easily push a significantly high-bandwidth stream. The one I used is very low bandwidth and that doesn't help.