Small segments cause erroneous bandwidth computation

[ghost]

pandaiolo commented on May 5, 2017, 12:26 AM UTC:

Description

I observe a problem in bandwidth computation on small segments, which leads to poor quality playlist selection.

Small segments reported bandwidth is very low due to a very small amount of data downloaded (<10k usually) resulting in xhr request overhead (ping and system) largely ecceeding the actual data download time in the request.roundTrip. It seem to the script that a relatively lot of time was required for that very small amount of data.

I have fixed this in my app by not updating the hls.bandwidth property when request.byteReceived is smaller than 30kb.

I could send a PR with that modification, or with an optional setting that would allow developers to activate it and choose the threshold.

Let me know what you think

Sources

Example video is accessible here : https://24hstory.com/post/-KUE3kOWxxjmeu73cMi0

Master playlist : https://firebasestorage.googleapis.com/v0/b/hstory-prod.appspot.com/o/posts%2FvXqwNla9erNMov9GZkuccKm6dix2%2F-KUE3kOWxxjmeu73cMi0%2Fmaster.m3u8?alt=media

(can't add a jsbin on this one because my CORS headers are not open to any domain, but not sure if it's needed when the issue is obvious and identified : bandwith computation on very small requests)

Steps to reproduce

Explain in detail the exact steps necessary to reproduce the issue.

1. Use the above playlist with last version of videojs-contrib-hls

Results

The reported bandwidth is very low around the end of the video, which is shown using poor quality 200kbps segments.

Expected

The estimated bandwidth should be close to actual bandwidth, and hence on a good connection, download only 800kbps segments.

Error output

No output

Additional Information

videojs-contrib-hls version

videojs-contrib-hls 5.4.0

videojs version

video.js 5.19.1

Browsers

Any non native HLS playing browser. Tested with Chrome 58.0.3029.96 (64-bit) and latest Firefox

Platforms

Mac OS Sierra

Other Plugins

None (no flash)

Other JavaScript

React, redux, and many other things, which sould not interact with the basic XHR behaviour described above

This issue was moved by forbesjo from videojs/videojs-contrib-hls#1102.

[ghost]

gesinger commented on May 18, 2017, 11:43 AM UTC:

Thanks for reporting pandaiolo . This is an interesting case, and as we're looking into improving our ABR, we should investigate this more.

[ghost]

pandaiolo commented on May 19, 2017, 1:46 PM UTC:

I realized later that this is a broader problem. Bandwidth is computed only using the last download, AFAIK. It is normal for an "adaptive" player to adapt to the latest network conditions, but on small segments, a small variation in last segment download can be a "false negative" and cause a useless drop in quality. The same video on safari with native HLS always keep the highest quality settings, not with videojs on Chrome. I don't know how the bandwidth measurement is done in a native client but I am free to help in any direction you feel appropriate, so let me know if you have any plans on this.

[ghost]

gesinger commented on May 22, 2017, 11:23 PM UTC:

Good points pandaiolo . And these issues are definitely on our minds as well. A PR was just submitted for a moving-average playlist selector: #1125 which is another approach (instead of us simply using the last bandwidth to determine what playlist to select). This is towards a goal of experimenting with different ABR algorithms, and determining the best default, as well as giving people more choices for their specific players. The PR is one such example, but we have more in the works. In addition, we have other approaches being considered for the larger ABR "epic" #1114

[adnan-razzaq]

any progress on this issue?

[gkatsev]

Not sure if this specifically fixes the issue, but we just got a new experimental ABR algorithm out. This uses the moving average bandwidth adaptation algorithm and also does buffer length checks to know whether we should upswitch or downswitch. So, could be an improvement.