DASH: Make use of multiple BaseURL elements, where more than one is defined.

[Bastian35022]

From what i saw, the BaseURL element in the DASH MPD is generally supported by the ExoPlayer. However, it does not seem to support multiple/alternative segment locations, as described in ISO/IEC 23009-1:2014 5.6.5. Do you plan on adding this?

[ojw28]

What would you expect the client to do with them? All the specification says is: "In the absence of other criteria, the DASH Client may use the first BaseURL element as base URI".

[Bastian35022]

It also says

5.6.5 Alternative base URLs
If alternative base URLs are provided through the BaseURL element at any level, identical Segments shall be accessible at multiple locations. In the absence of other criteria, the DASH Client may use the first BaseURL element as “base URI". The DASH Client may use base URLs provided in the BaseURL element as “base URI” and may implement any suitable algorithm to determine which URLs it uses for requests.

So if multiple alternative base URLs are indicated (as I understood, by declaring them in the same element / on the same level), the client could e.g. start with any base URL, and try another base URL if it can't get a segment from the previous one.

This is of course an effort vs. sophistication thing.

[ojw28]

It kind of depends what "other criteria" is supposed to mean. The fact that the specification doesn't define what these criteria should be kind of indicates that the criteria should be specific to the server-side streaming infrastructure (e.g. YouTube may have different criteria to an application using Akamai's CDN). Obviously we don't know the specifics, so we need to either implement something generic enough to be sensible for all infrastructures, or make it pluggable, or do nothing.

For now, I think we're fine just using the first BaseURL. Which we don't currently do, since the current code will end up picking the last one. I'll fix this.

[Bastian35022]

I totally agree about the infrastructure dependencies. And creating a small generic interface for multiple base URLs would be very nice, such as offering multiple base URLs in RangedUri or Representation instances.

[pakerfeldt]

This is on my plate as well right now. If there's any more input on this I'll gladly take it. In our case we want to be able to failover to another CDN if necessary. But I prefer to implement it such that it can go upstream rather than just fork and hack.

[abhiguru]

It picks the first one for the load and if there is a timeout it tries the other base URLs sequentially ? (ideally be based on latency imo)

[pakerfeldt]

I was thinking of having the failover logic to be an application specific implementation. Maybe with some sane default to use though. I, for instance, have a pretty specific kind of behavior I want to add but I don't necessarily want to enforce it on everyone.

[pakerfeldt]

@ojw28 Do you have any input on this? Making this pluggable is not trivial since segmentBase and initilizationUri both creates the baseUrl during mpd parsing. I'm currently experimenting with having a list of baseUrls in these to see where I get. But my approach to solve this might differ significantly depending on the likeliness of getting such change merged upstream since I want to diverge from upstream/master as little as possible.

[Bastian35022]

@pakerfeldt I also implemented a list of baseUris in the RangedUri class, and all the necessary parsing, recently. I will update this and push it to a fork, so you can have a look if you want to.

[Bastian35022]

Created a pull request for this (#1250).
@ojw28 Maybe we can find a solution to expose multiple locations in some way (either to the app or for implementing a dedicated interface), without limiting it to specific use-cases and without affecting too much of the framework? In the pull request, the locations are exposed in the RangedUri class, and I only touched DASH-related code.

I guess the ideal solution would be to modify the baseUri to be used in general, so without doing it for every single chunk. This could of course be achieved by introducing a LocationSelector class that holds the different baseUris, is referenced by the RangedUri instances, and is exposed per representation (because the set of baseUris can be different for every Representation). The problems here are:

• Changing the baseUri to be used will not affect already unsuccessfully requested chunks. For that, we'd have to integrate the LocationSelector into the DataSpec class as i see it.
• Exposing the LocationSelector instances directly to the application probably breaks with some design principles, as i see it. I think location steering should be implemented in the player after all, similarly to the FormatEvaluator implementations.