hls.js alternates 3 qualities on throttled connections
Environment
- [x] The stream has correct Access-Control-Allow-Origin headers (CORS)
- [x] There are no network errors such as 404s in the browser console when trying to play the stream
- [x] The issue observed is not already reported by searching on Github under https://github.com/dailymotion/hls.js/issues
- [x] The issue occurs in the latest reference client on http://dailymotion.github.io/hls.js/demo and not just on my page
- Link to playable M3U8 file: http://dailymotion.github.io/hls.js/demo/?src=http%3A%2F%2Fzdf1314-lh.akamaihd.net%2Fi%2Fde14_v1%40392878%2Fmaster.m3u8&enableStreaming=true&autoRecoverError=true&enableWorker=true&levelCapping=-1&defaultAudioCodec=undefined
- Hls.js version: 0.6.8
- Browser name/version: Chrome 54
- OS name/version: MacOS El Capitan
Steps to reproduce
- play the livestream on the demo page and investigate network tab
- throttle down to "DSL (5ms, 2.0Mb/s)"
- hls.js now loads different qualities at the same time and switches quality levels very often.
Expected behavior
do not switch quality levels this fast.
Actual behavior
quality levels are changed very often. Also, some segments are loaded in more than one quality.
this causes video and audio lags.
Console output
Network output
the second number in the filename is the quality.
axten
All 17 comments
xhr-loader.js:68 GET http://zdf1314-lh.akamaihd.net/i/de14_v1@392878/master.m3u8 403 (Forbidden)
mangui
on 7 Nov 2016
shit... our livestream is geo ip blocked, do you have a proxy to germany?
axten
on 7 Nov 2016
nope sorry
mangui
on 7 Nov 2016
ok we will work on a solution tomorrow.
axten
on 7 Nov 2016
posting a metrics permalink would help in the meantime
mangui
on 7 Nov 2016
longer periods causes Errror "Error 756 Too long request string" for perma links.
So here is the data for a longer period:
metrics.txt
axten
on 8 Nov 2016
@axten and I had could reproduce the issue also with this stream:
Can you play this one?
DracoBlue
on 8 Nov 2016
here we have a stream that should not be geo protected: http://dailymotion.github.io/hls.js/demo/?src=http%3A%2F%2Fzdf0708-lh.akamaihd.net%2Fi%2Febu07_v1%40392868%2Fmaster.m3u8&enableStreaming=true&autoRecoverError=true&enableWorker=true&levelCapping=-1&defaultAudioCodec=undefined
axten
on 9 Nov 2016
checking
mangui
on 9 Nov 2016
ok, there are 2 things:
most of your fragments do not start with a Key Frame.
=> as a consequence, when switching between renditions (to level L, SN N), hls.js needs also to load frag level L, SN N-1 to be able to decode the first frames of frag level L, SN N
as it adds extra latency, upfront buffer becomes short, and the changes i did in ABR (taking into account upfront buffer to choose rendition) triggers a switch down to avoid a rebuffering (although bw is enough)
=> you should try to have your fragment starting with KF
=> i will try to disable the upfront buffer check in ABR for live streams (it might not be appropriate)
mangui
on 9 Nov 2016
thank you for the quick support!
we will check the keyframe issue with our streaming department.
axten
on 9 Nov 2016
plz recheck against latest demo page with 2Mb/s bw throttling, it should not oscillate that much in case of frag not starting with KF
mangui
on 9 Nov 2016
looks better now, thank you very much!
axten
on 9 Nov 2016
some metrics
metric.txt
Christian-Krupa
on 9 Nov 2016
looks better
mangui
on 9 Nov 2016
most of your fragments do not start with a Key Frame.
This is due to the default mechanism used in Akamai stream packaging, which is deriving HLS from live RTMP input. The default enforces that the segments are of exactly equal length, following a strict requirement of the Apple app qualification process. I am not sure if this requirement is still valid, but it used to be for quite a while and there have been cases in which apps have been rejected because the segments did not have equal length. Forcing equal length on the packaging side in combination with the packages arriving from the encoder via RTMP can lead to fragments not starting with a Key Frame. As having a Key Frame at the beginning is not a strict requirement by Apple this makes sense as a default.
However, it is possible to change the packaging behaviour on Akamai's side to produce only segments that start with a key frame. Depending on the encoder input, this can lead to segments of slightly different length, though. To my understanding this option is currently being discussed with the client.
shruggingatlas
on 9 Nov 2016
Related issues
krsvital
路
3Comments
mmmmoj
路
3Comments
NicholasAsimov
路
3Comments
itsjamie
路
3Comments
shalommeoded
路
3Comments
Most helpful comment
ok, there are 2 things:
most of your fragments do not start with a Key Frame.
=> as a consequence, when switching between renditions (to level L, SN N), hls.js needs also to load frag level L, SN N-1 to be able to decode the first frames of frag level L, SN N
as it adds extra latency, upfront buffer becomes short, and the changes i did in ABR (taking into account upfront buffer to choose rendition) triggers a switch down to avoid a rebuffering (although bw is enough)
=> you should try to have your fragment starting with KF
=> i will try to disable the upfront buffer check in ABR for live streams (it might not be appropriate)