Fix #1731 - ensure BaseURLs are resolved properly for SegmentBase

[davemevans]

The manifest in #1731 showed up an issue where BaseURLs were not resolved properly for SegmentBase elements if they had a path in them because the path element appeared to be resolved twice. The reason for this was that SegmentBase and BaseURL manifest types were copying the BaseURL element to initialization, but still resolving the BaseURLs anyway, leading to the behaviour seen.

Further, once the BaseURL resolution had been performed at startup time for these manifest types it could not be redone so they would not be able to benefit from BaseURL redundancy (although this is probably less of an issue since they are for on-demand use).

I tested these specific changes using:

• http://timcin-wedding.s3-eu-west-1.amazonaws.com/videotest-album/hls/a5b3f3f0d4d711e6b653affe68f4ebc2/playlist.mpd (from Player trying to load segments from wrong directory with mp4box created manifest file #1731)
• http://dash.edgesuite.net/dash264/TestCases/1a/sony/SNE_DASH_SD_CASE1A_REVISED.mpd (BaseURL test vector)

... as well as the usual suspects from the sample list.

Also tested Webm with:

• http://downloads.webmproject.org/demos/adaptive/webm_dash_mevq-ver2-vid6-aud1.mpd
• http://yt-dash-mse-test.commondatastorage.googleapis.com/media/feelings_vp9-20130806-manifest.mpd

and these work great but we do not have enough test material for webm IMO.

[dsparacio]

LGTM. THanks for refactoring some stuff into utils. Will help with testing.

[dsparacio]

@bbcrddave Ready to merge?

[davemevans]

Thought of a couple of tests worth doing tomorrow morning.

Assuming you are ok with the changes as they are, I'll merge after that assuming all goes well and no changes needed?

[davemevans]

@AkamaiDASH This is good to go 🍾