HLS: Incorrect composition of full URLs to media_N.m3u8

[Lastique]

Have you read the FAQ and checked for duplicate open issues?:
Yes.

What version of Shaka Player are you using?:
Reproduces on 2.5.0-beta2 and 2.4.5.

Can you reproduce the issue with our latest release version?:
Yes.

Can you reproduce the issue with the latest code from master?:
I didn't try.

Are you using the demo app or your own custom app?:
Custom app.

If custom app, can you reproduce the issue using our demo app?:
I can't try as the stream is not accessible publicly.

What browser and OS are you using?:
Kubuntu 18.10, Chrome 70.0.3538.102, Firefox 63.0.

What are the manifest and license server URIs?:
No license server. The manifest and the test page are attached.

What did you do?
Suppose, the test page is located at https://my.server.com/dash/index-shaka.html. The page contains a relative path to the manifest "media/master.m3u8". The media manifests are also located in the "media" subdirectory, i.e. "media/media_0.m3u8", "media/media_1.m3u8", etc. master.m3u8 contains only media manifest file names with no path, i.e. media_0.m3u8, media_1.m3u8, etc.

What actually happened?
When I open the test page, Shaka-Player attempts to load media manifests at https://my.server.com/dash/media/media/media_0.m3u8. Notice the duplicate "media" in the URL. As a result, media manifests are not found, the server returns 404.

What did you expect to happen?
The player should correctly compose the absolute URLs to the media manifests. Given that the page is located at https://my.server.com/dash/index-shaka.html, the absolute URL to the master manifest would be https://my.server.com/dash/media/master.m3u8. Since media manifests are referenced relative to the master manifest, the correct absolute URLs should be https://my.server.com/dash/media/media_0.m3u8, etc.

I've attached the test page and manifests in the directory layout described above.
dash.tar.gz

[joeyparrish]

Confirmed. Thanks for the report! We're working on it.

[joeyparrish]

I have a working fix locally, but I still need to clean things up, update the tests, and write new tests.

[joeyparrish]

After a great deal of refactor and clean up (which I think we should keep), I have discovered that this bug can only be triggered if the URI loaded for the master playlist is a relative path:

player.load('media/master.m3u8');

The fix for that could be a single line in the HLS parser:

shaka.hls.HlsParser.prototype.start = function(uri, playerInterface) {
  goog.asserts.assert(this.config_, 'Must call configure() before start()!');
  this.playerInterface_ = playerInterface;
  this.manifestUri_ = uri;
  return this.requestManifest_(uri).then(function(response) {

    // vvvvv
    this.manifestUri_ = response.uri;  // ADD THIS LINE
    // ^^^^^

    return this.parseManifest_(response.data, uri).then(function() {
      this.setUpdateTimer_(this.updatePeriod_);
      return this.manifest_;
    }.bind(this));
  }.bind(this));
};

In your case, uri is a relative URI, but response.uri is absolute. The trouble comes later when we try to resolve other relative URIs against this.manifestUri_. The URI resolution code expects an absolute URI as a basis, so the results were broken and caused the duplication in your media playlist URI.

Even though I now know that we could "fix" it with that one line, there are many unclear assumptions about relative vs absolute URIs in the HLS parser, and some TODOs about how we handle redirects (poorly). So I think the larger cleanup is worthwhile.

[Lastique]

Thanks for the fix!

[joeyparrish]

Happy to help!

[joeyparrish]

Fix cherry-picked for v2.4.6.