Chromecast Receiver CAF, infinite loading of MPEG-DASH stream, ShakaPlayer access

问题

I've got a problem with Chromecast playing MPEG-DASH livestream. The infinite loading occurs because of the lack of UTCTiming tag in manifest. The problem is known to occur with ShakaPlayer. It's the first problem in FAQ: https://github.com/google/shaka-player/blob/master/docs/tutorials/faq.md

On chromecast however, i can't access the ShakaPlayer directly (or maybe there is a way that i'm not familiar with). There are 2 solutions to the problem that i can think of:

Modify manifest dynamically.

 this.playbackConfig.manifestHandler = (manifest) => {
    //adding UTCTiming to the manifest with attributes like this:
    customUTC.setAttribute("schemeIdUri", "urn:mpeg:dash:utc:http-head:2014");
    customUTC.setAttribute("value", this.manifestUrl); }

This however doesn't change the behaviour of the chromecast player, the infinite loading still occurs, am I doing something wrong here?

Using the older player (Media Player Library) via setting useLegacyDashSupport makes chromecast play stream normally, but breaks UI a little.Can I switch to the legacy player dynamically only when it's needed? Based on a manifest for example, or during loadRequest from sender app.

回答1:

The UTCTiming element is required since Shaka Player needs to know what time is on the server so it can play at the right time. If the client and the server have different clock times, the video will likely fail to play. It isn't really a requirement of Shaka Player, more of a requirement of DASH in general.

But if you can't set the element in the manifest, you can use the manifest.dash.clockSyncUri (see docs) configuration parameter to set a clock sync URL to use. For example:

player.configure({manifest: {dash: {clockSyncUri: 'https://example.com/clock'}}});

Note that the URL used for clock sync needs to have a correct Date header on the response (be careful of caching) and if the request is cross-origin, you'll need to expose the header or there will be CORS errors.

Also, shaka-player#999 is a feature request to help with drift. After that feature lands, the Player will use the segments in the manifest to guess the live edge instead of using the clock time. This means you won't have to set up clock sync.

回答2:

I agree with you. This is very annoying behavior that shaka forces to use UTCTiming.

If you have an option to modify shaka-player codes in your fork, I would suggest that you should call the setClockOffset method after manifest initialized (check here). Manifest has presentationTimeline which has the setClockOffset method. Otherwise, you can reach the manifest from here. The setClockOffset method is triggered for UTCTiming. If you cannot set up UTCTiming for your manifest, setting offset manually might be the best option for your case.

A sample code case would be =>

player.load(manifestUri)
  .then(() => {
    const manifest = player.getManifest();
    const presentationTimeline = manifest.presentationTimeline;
    presentationTimeline.setClockOffset(10/* find a suitable offset */);
  });

Good luck!

来源：https://stackoverflow.com/questions/50680877/chromecast-receiver-caf-infinite-loading-of-mpeg-dash-stream-shakaplayer-acces

标签

chromecast

google-cast

mpeg-dash

shaka