@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 different dvb:priority values? If so then:

1. I wonder if that's what's happening here, because BaseURL elements that don't specify dvb:priority presumably all get assigned the same default priority value.
2. I think this would probably be incorrect behavior unless the DASH manifest specifies that it's authored according to a urn:dvb:dash:profile:dvb-dash profile and/or includes explicit dvb:priority attributes. 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!

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 baseURL inherit all properties from the parent baseURL. So any attribute declared on a relative baseURL is ignored.

For a manifest with the snippet above both of these attributes above would inherit the values and have the same serviceLocation and priority and weight and hence if one of it is selected and then fails, the other would be excluded as well (either because of identical serviceLocation or priority).

It's also true that the current implementation does this even if no dvb namespace 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 (like https). This would result in the parser using the baseURL itself as the serviceLocation. You would then also need to declare a dvb:priority to the absolute baseURL that is different then the priority of the parent baseURL that is 1.

Proposed change of implementation
I think we should change the implementation in a way that we discriminate between manifests that have the dvb namespace 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 to baseURLs (the DASH spec allows the client to implement any 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.

Thanks for the details!

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 (like https). This would result in the parser using the baseURL itself as the serviceLocation. You would then also need to declare a dvb:priority to the absolute baseURL that is different then the priority of the parent baseURL that is 1.

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.