UTCTiming (http-head) is treated as relative to page (instead of MPD)

Created by: sandersaares

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://reference.dashif.org/dash.js/ and not just on my page

• Link to playable MPD file: https://live.axtest.net/Channels/Test1/Manifest.mpd

• Dash.js version: nightly

• Browser name/version: Chrome 62

• OS name/version: Windows 10 v1709

Steps to reproduce

1. Start playback.
2. Observe network traffic.
3. Compare against Shaka player to verify deviation.

Observed behaviour

dash.js sample player fails to resolve time according to the UTCTiming element and instead uses Akamai server for time sync.

The apparent cause is that the UTCTiming element specifies a relative URL. dash.js appears to treat it as relative to the website the player is hosted in. Relative to the page, this is a 404, so presumably dash.js falls back to Akamai.

I would expect it to instead treat the UTCTiming URL as relative to the MPD (or its BaseURL, if any, which in this case is none).

It is true that DASH does not actually specify anything about relative URLs here but Shaka player treats it this way and it seems to make logical sense, so seems like the most interoperable behavior.