Support for the <baseURL> tag

[wilaw]

DASH spec Section 5.6 provides for multiple levels of baseURL support i.e the ability to source a segment from an alternate locations. BaseURLs can be specified at different levels within the manifest:

• On MPD level in MPD.BaseURL element. For details refer to 5.3.1.2.
• On Period level in Period.BaseURL element. For details refer to 5.3.2.2.
• On Adaptation Set level in AdaptationSet.BaseURL element. For details refer to 5.3.3.2.
• On Representation level in Representation.BaseURL. For details refer to 5.3.5.2.

Concomitant with support for BaseURL is a requirement to define when and how to switch over to these alternate sources. Switch logic may be different for live services and VOD and may also vary between different applications.

To simplify development, it is proposed that baseURL is added in a number of phases:

1. Phase I - MPD.baseURLsupport only. This is likely to be the most common use case, as it is the means by which operators can deploy multi-CDN solutions. This can be accompanied by simple fail-over logic such as if a non-200 response is received for a segment, then immediately retry the request using the alternate source specified by baseURL. Cycle down the stack in the case of multiple baseURL entries. Propose the following API on MediaPlayer to modify that behavior:
   1. segmentRetryCountBeforeBaseURL - default value of 0. If set to n, and the manifest specifies one or more baseURL sources, then the player will retry a segment fetch at 1s internals for a maximum of n times when playing a dynamic (live service manifest) after it receives a non-200 response for a segment.
   2. forceBaseURL(string) - when called, player immediately switches to requesting segments from the first baseURL whose path includes the string argument. The player will remain sticky against this source and will not try alternate sources in the event of 404s. This allows operators to force a system wide switch to a particular CDN.
2. Phase II - MPD.baseURL and Period.baseURL support - this will allow for alternate baseURLs to be added for advertising content inserted using XLink.
3. Phase III - support baseURL at manifest, period, adaptationSet and representation levels.

[davemevans]

I'm currently out of the office for a few weeks but wanted to flag that I have been working on prototyping this.

We are interested in DVB-DASH so my work is focusing on supporting this, but has a simple fallback when DVB profile is not in use which matches the logic described in (1). See DVB DASH sections 10.8.2 and 11.9 for more information.

There's still more to do but hopefully I should have something to show in a few weeks time. Please let me know if you anyone else has picked this up so we are not duplicating effort. I plan to support all three phases in one go - I don't think it adds much complexity.

segmentRetryCountBeforeBaseURL feels like it should be a generic retry parameter, regardless of the number of BaseURLs. Is there any reason to behave differently if there are no alternative URLs to try? Perhaps the interval should be tunable too? I'd probably rather the default number of retries was higher than 0, but it's open to debate. DVB DASH gives some sensible maximums (section 10.8.6).

[richardbushell]

Is Multi-CDN BaseURL elements included now in the latest Dash.js 1.5.1? And where is the latest documentation on how it handles the switch logic defining when and how to switch over to these alternate sources?

[davemevans]

No - this feature was not implemented in 1.5.

[richardbushell]

Thanks Dave, do you (or anyone) know if Multi-CDN BaseURL is planned or provisioned for 1.6 or 2.0? Or an idea on expected timeframe for this...

[dsparacio]

I think @bbcrddave is going to take on this work for 2.1 so marking for 2.1 milestone.

[davemevans]

See #1280 for a PR implementing this functionality. It implements all phases as described in the OP. If the DVB profile is detected in MPD@profiles the selection occurs as described in DVB A168. If not, the default mode is broadly the 'simple' option above i.e. to assume that the order in the manifest is priority order. In all modes, failover occurs when a segment request fails for any reason other than cancellation.

I did not change the existing retry behaviour, so the default is still a crazy four times. I did not implement segmentRetryCountBeforeBaseURL as above. However, since this feature request was entered, a different API was added (MediaPlayer.setFragmentRetryAttempts) which I believe should have the same effect. We certainly need to sort out default retries and I will open a new issue to track that. Answering my own comment, MediaPlayer.setFragmentLoaderRetryInterval is also now available.

I did not implement forceBaseURL. This would need to be another PR. At the moment the only API for setting BaseURLs is the manifest.

[dsparacio]

@bbcrddave I added this please add comments.
#1310

I will close this issue since you implemented support. Please open a new ticket if there are parts left to track.