Hls.js: Force pre-buffering with best possible quality

[nnarhinen]

I have a HLS stream, that has a peak bitrate in the middle of the video.

On my pretty decent broadband connection using startLevel: -1 it chooses 1080p but in between does an emergency switchdown to 216p, shows that for a while and then goes back to 1080p.

What option combo could I be using to have HLS.js pre-buffering more so that it should not have to do this emergency switch down? I'm ok with delaying the initial video playback for this.

[nnarhinen]

http://dailymotion.github.io/hls.js/demo/?src=%2F%2Fdrive.flowplayer.org%2F202777%2F96286-slowmotionjumpingsplashingwavesbJIyUXwgr.m3u8&enableStreaming=true&autoRecoverError=true&enableWorker=true&levelCapping=-1&defaultAudioCodec=undefined

[mangui]

indeed, you are being switch down by the emergency switch down rules, which starts checking for potential buffer starvation after half of expected fragment duration delay.

i.e. IF your fragments last for 4s, THEN after 2s of frag loading, expected time of load completion will be monitored, and if it happens that there are risks of buffer starvation because this expected time is AFTER buffer starvation time, THEN emergency switch down will happen.

but in your case maybe you don't want ABR ? just forcing quality level to max one ?

[blacktrash]

A practical and flexible implementation would be to use startLevel: -1 and then make the detected level sticky, i.e., use the startLevel detected by the first bandwidth check, and then disable autoLevel.
Here's an attempt: http://flowplayer.blacktrash.org/fp6/home.html
On the first FRAG_CHANGED event it set hls.currentLevel = hls.currentLevel to prevent further switching.
In practice this works nicely after a reload, even in Chrome's incognito mode. However, when really thoroughly emptying caches[1], a low bit rate is selected.

Any ideas how to overcome this? Use a different event? But which one? Or is this just how browsers behave?

[1] the only method I found to overcome caching persistence is:

1. close window
2. purge caches
3. quit browser
4. load page again

[blacktrash]

Probably needs some further testing, but I think I've got it working with hls.nextLevel = hls.currentLevel in the callback of the first FRAG_CHANGED event.

[nnarhinen]

In my tests I then got the same behavior as with using a "too good" quality VOD file - video playback pauses for buffering. With HLS.js one could in theory be more in control of the buffer, even buffer the whole video before signaling the mediasource it's ready to play.

What I'm after, is a way to pre-fetch fragments for, say, 100 seconds of video in desired quality, no matter how long it takes, and then start feeding those fragments to the mediasource. The VOD equivalent version would be to fetch the whole file with ajax, then read the arraybuffer as base64 and feed the base64 representation as video source. This way I could be sure I can show the best possible quality without pausing for buffering, something desired in some situations.

[blacktrash]

ok, I misunderstood the use case.
Although I can't think of a practical use case where startup time doesn't matter - 'no matter how long it takes'.
otoh, I also could not detect stuttering with my settings - unless of course bandwidth lowers suddenly during playback. Hm. Sounds like you want to just 'download' a VOD file ;-)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[beppe9000]

stale bot is evil