Repository navigation
BaseURL failover not working with relative network-path URLs (?) #9856
Description
Hi folks,
I've recently checked on baseURL failover for DASH manifests that was added with ExoPlayer version 2.15.0 and found an asset not working as expected.
I cannot share the content url however it should be easily reproducible with the following snippet:
<Period>
<BaseURL>//anotherhost.com/some/url/1</BaseURL>
<BaseURL>//anotherhost.com/some/url/2</BaseURL>
...
</Period>I'm not sure if those relative network-path are considered to be valid and/or supported, so thought I'll bring this to your attention.
From what I can tell from my observation is, that in such a case the serviceLocation is mapped to the manifests base Url, and down the line being added to the exclusion list (after the first BaseUrl failed), thus excluding all base urls with the same serviceLocation.
Happy to hear your thoughts.
Activity
ojw28 commentedon Jan 12, 2022
@marcbaechinger - I seem to remember that we implemented BaseURL exclusion according to the DASH DVB spec, which also groups BaseURL elements by
dvb:priority. In the current implementation, do all BaseURL elements get excluded together unless they specify differentdvb:priorityvalues? If so then:dvb:prioritypresumably all get assigned the same default priority value.urn:dvb:dash:profile:dvb-dashprofile and/or includes explicitdvb:priorityattributes. If it does neither, the author of the manifest would not expect the fallback behavior to be as defined in the DASH DVB spec, and we should probably only group by service location.Note: My theory is different to the author's theory above. Either could be true!
marcbaechinger commentedon Jan 12, 2022
I think both theories are correct and both are a result of the implementation following the DVB spec (
ETSI TS 103 285 V1.2.1 (2018-03)) - 10.8.2.1. The DASH spec itself does not define a specific handling what to use or how to exclude: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.. Excluding both if one of it fails does still not look right in the sense of the DASH spec I'd say.Our implementation following the DVB spec, makes a relative
baseURLinherit all properties from the parentbaseURL. So any attribute declared on a relativebaseURLis ignored.For a manifest with the snippet above both of these attributes above would inherit the values and have the same
serviceLocationandpriorityandweightand hence if one of it is selected and then fails, the other would be excluded as well (either because of identicalserviceLocationorpriority).It's also true that the current implementation does this even if no
dvbnamespace is declared in the manifest.Possible workaround with the current implementation
@jarhoax If you want to make this work with the current implementation you would have to make one or both of these
baseURLs absolute by adding a scheme (likehttps). This would result in the parser using thebaseURLitself as theserviceLocation. You would then also need to declare advb:priorityto the absolutebaseURLthat is different then the priority of the parentbaseURLthat is 1.Proposed change of implementation
I think we should change the implementation in a way that we discriminate between manifests that have the
dvbnamespace declared and such that don't. Former is the current implementation, but latter should probably not inherit values from the parent base URL. We then should also either assign different priorities tobaseURLs (the DASH spec allows the client to implementany suitable algorithm) or ignore priorities completely when excluding base URLs.Not sure whether this is a bug or an enhancement. :) Marking as a bug as the author of the above manifest does not expect that both base URls are excluded.
jarhoax commentedon Jan 12, 2022
Thanks for the details!
Thanks! I played around while investigating and ended up applying exactly what you just suggested as a workaround to make this particular stream working. Nonetheless I wanted to let you know that the original manifest wasn't working as expected. :) And reading your proposed change seems like my assumption was correct.
Inherit parent properties for manifests with dvb profile only
Inherit parent properties for manifests with dvb profile only