Changing manifest URI when initializating cast app

[ScripterYoda]

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

What version of Shaka Player are you using?
3.1.0

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

Can you reproduce the issue with the latest code from master?
Yes

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

What did you do?
I want to have possibility to change manifest URI inside receiver app (our manifest have one codec assets so I want to VP9 manifest if possible and H264 manifest otherwise). Now, there is a contentIdCallback that I can pass while initializating CastReceiver.

What did you expect to happen?
I would expect that the contentIdCallback would always properly change url.

What actually happened?
contentIdCallback is only called with LOAD generic message but not with INIT shaka message or ASYNC CALL iwth load shaka message. Therefore, I have now no way to change my manifest URI.

[theodab]

If we did add something like this, contentIdCallback would not be the right place to put it. That is meant to turn contentId values into URIs, not URIs into other URIs. Changing it might break other peoples apps.
We could add a separate callback for this, I suppose?

In the meantime, though... you might be able to solve this problem with a custom network scheme plugin. Like, you could call player.load with a synthetic URI that contains the real URI, then have a custom scheme plugin redirect the request to the correct URI.
So the scheme plugin would look something like:

shaka.net.NetworkingEngine.registerScheme('fake', (uri, request, requestType, progressUpdated, headersReceived) => {
  const realUri = uri.split('fake:')[1];
  const finalUri = realUri; // TODO: Determine which codec asset URI to load.
  // I don't remember offhand if Chromecasts support the Fetch API, so use XHR to be safe.
  return shaka.net.HttpXHRPlugin.parse(finalUri, request, requestType, progressUpdated, headersReceived);
});

Then you'd just append fake: to the start of the URI you want to load, and let this scheme plugin determine the actual asset to load.

[joeyparrish]

If you are happy manipulating the URI in a scheme plugin, I would make one tweak to @theodab's recommendation. Instead of calling directly into shaka.net.HttpXHRPlugin, I would recommend modifying the request object's uris field and then calling NetworkingEngine.request(). That way, you are not hard-coding the name of a plugin that may someday be deprecated.

If this solution doesn't work for you or it is too cumbersome, we could offer a new callback.

[ProtoScott]

Hey @joeyparrish we would be really interested in getting a callback prior to the initialisation of the shaka player.

Our desire would be to modify the config object to include a max resolution for certain chromecasts which we would do on initialisation. Or other things like changing the DRM url.

[joeyparrish]

We already set the max resolution to 1080p or 4k based on the device and display capabilities on ChromeCast. This is done in CastReceiver by calling Player.setMaxHardwareResolution. You can this yourself at any time after the CastReceiver constructor to change the maximum. You can also use a request filter on the receiver-side Player to change the manifest or DRM URLs.

[ProtoScott]

We already set the max resolution to 1080p or 4k based on the device and display capabilities on ChromeCast. This is done in CastReceiver by calling Player.setMaxHardwareResolution. You can this yourself at any time after the CastReceiver constructor to change the maximum. You can also use a request filter on the receiver-side Player to change the manifest or DRM URLs.

So setting the max hardware resolution / setting up a request filter would be fine, but it's unclear (or possibly not possible) to send custom data as part of the chromecast setup where we can make a decision to set these?

The use case here is that some old chromecasts say they support 4K but their performance causes visual artifacts, for this we want to override the default behaviour and limit to 1080p but only for people that choose the option because they are experiencing a problem.

[avelad]

@joeyparrish I'm not sure we want to support this, since we want to do #4214 in the future

[joeyparrish]

Yes, obsolete now. Thanks!