Delay from live default is too high under 2.3

[wilaw]

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
• [x ] The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• [ x] 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:
• Dash.js version:
• Browser name/version:
• OS name/version:

Steps to reproduce

1. Use this sample /samples/live-streaming/live-delay-comparison-custom-manifest.html
2. Start with the default setting and the default stream of http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd
3. Live delay estimate is shown as 20s behind live. This is too high. Default live delay is 4 segment durations, which should be ~8s.
4. Use setLiveDelayFragmentCount to 0 and reload stream
5. Live delay is now shown as ~14s, which is still too high.
6. Values of setLiveDelayFragmentCount to 1,2 or 3 all produce a live delay of ~15s. There should be more variation.

Observed behavior

1. The player is holding a larger default live delay than it should by ~ 12s.
2. This 12s live delay seems to be added to any holdback specified by setLiveDelayFragmentCount or setLiveDelay.
3. Use of setLiveDelayFragmentCount does not produce anticipated live delay values or variance when adjusted 0,1,2,3.

Console output

[wilaw]

Resolved. System clock on test machine was 9.6s slow compared to UTC. That sample http://dashif.org/reference/players/javascript/nightly/dash.js/samples/live-streaming/live-delay-comparison-custom-manifest.html uses system clock as the reference point, hence the stream appeared to be 9.6s further behind live than it really was. Once system clock was re-synced, live stream delay was within expected bounds.