-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for redirect using <Location> is broken #1887
Comments
I'm not sure this is a bug per se. The only mention of Location in the spec is for MPD reload, which dash.js does correctly, and that is in an informative section. Clearly a solution is required for these user-agents, and it is trivially solved in the simple case using the method above, but we need to ensure sensible behaviour. What would be the expected behaviour if there are multiple Locations? How about if there is a 302 redirect and a Location and the URLs do not match (hopefully this would never happen!)? |
As far as I interpret the standard, and the DASH-IF IOP document, the MPD Location is the basis for relative URLS further down in the segment whether this is implicit or an explicit element. If there are more than one element, it is up to the player to choose one. Regarding the interpretation order, I think it is pretty clear:
The only case that remains is an absolute BaseURL at the top level. This must come before the Location according to the Schema, so the question is whether the Location should override it or not. An absolute BaseURL in one of the adaptation set should then always have priority. For what it is worth, it seems that the dhaka-player lets the Locations have the highest priorities and just keeps a list of all combinations of Locations and BaseURLs. (See its dash_parser.js file). |
This issue was discussed during the dash.js f2f on May 16, and it was decided to implement this behavior. I'll try to look into implementing this myself. |
Some service providers use HTTP 30X redirect in the Manifest response to introduce a session ID in the URL. This redirect address is recognized by the ManifestLoader and used as the basis for segment requests as well as for future manifest requests.
The actual URL is available as xhr.responseURL, but not in IE11 and Edge (before Anniversary Edition).
Thus another solution is needed for these browsers.
One possibility is to use the <Location> element in the MPD. That provides the address where the MPD is located, and should therefore result in the same behavior as an HTTP 30X redirect.
I've created a small test asset at http://vm2.dashif.org/dash/vod/Location.mpd for testing this and segments are not fetched relative to http://vm2.dashif.org/dash/vod/ as they should. However, the expected behavior is provided by both Shaka-player and Theoplayer.
The text was updated successfully, but these errors were encountered: