CACHE_LOAD_THRESHOLD_LATENCY is too high (ThroughputRule.js)
Created by: twdkeule
Environment
-
The MPD passes the DASH-IF Conformance Tool on http://dashif.org/conformance.html -
The stream has correct Access-Control-Allow-Origin headers (CORS) -
There are no network errors such as 404s in the browser console when trying to play the stream -
The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ -
The issue occurs in the latest reference client on http://dashif.org/reference/players/javascript/ and not just on my page
- Link to playable MPD file: any file
- Dash.js version: development branch
- Browser name/version: any browser
- OS name/version: any OS
Steps to reproduce
- Start the player with a low latency connection between server and client while disabling the cache (for Chrome:
--disk-cache-dir=/dev/null)
Problem
When the latency between client and server is low a lot of segments will be classified as coming from the cache, when in fact they are not. In my case when streaming over localhost, the reported latency is mostly around 20ms but sometimes above 50ms. Only these last segments are counted in the ThroughputRule thus severely limiting its capabilities. I am aware streaming over localhost is not a realistic case, but it seems latency is not a very good metric to determine whether or not the segment was cached. Latency to youtube.com for example is only 10ms, while over local wired networks it can be below 1ms.
I propose to no longer use only use CACHE_LOAD_THRESHOLD_LATENCY and only use CACHE_LOAD_THRESHOLD_VIDEO and CACHE_LOAD_THRESHOLD_AUDIO as these are based on the measured throughput. These measurement are less likely to be ambiguous as real segments are unlikely to reach the throughput achieved by the cache (unless over localhost, but this can be easily managed by limiting the throughput of localhost with tc).