Shaka-player: Parse ms:laurl and ms:pro in DASH

[boredom2]

Hi there,

I was able to use Shaka with Microsoft Azure Multi DRM Solution (Widevine and PlayReady) and its working really great - if I hardcode the License Server URLs.
I do not know the License Server URLs when starting the Media, I have to take them out of the Manifest.
There is (for example):

<ms:laurl licenseUrl="https://wamsamsclus001kd-hs.cloudapp.net/Widevine/?KID=23e6c7c5-6af1-49aa-91fd-6f8de3652cc6"/>

which I would like to parse.
Can you tell me, where the optimal point for digging into the Player in order to achieve this is?
Meaning, as soon as the Manifest is parsed, I have to get it (or parts of it), extract the details, rewrite the config in order to add the License Servers and then were done :)
How is that most most efficiently?

Thanks a lot,
Christoph

[joeyparrish]

Take a look at lib/dash/dash_parser.js and the rest of lib/dash. If you want to create a pull request for this, I'd be happy to review it.

[joeyparrish]

Oh, and I should have mentioned, the parser can put the license server URL into the manifest output directly. No need to modify the config.

[boredom2]

Thanks for your comment.
We decided to handle this on the Backendside and present the necessary Parts to the Player itself.
Nevertheless, I will take a look at the dash_parser for that. You never know, maybe we change our minds again :)

[sandersaares]

Is the meaning/format/structure of this ms:laurl documented/specified anywhere? Or is it just a random attribute Azure adds? There has been some talk in DASH-IF of unifying this aspect of metadata (license server URL) but it never got anywhere, so I am curious if there is an unofficial trend forming in some corner of the industry.

[joeyparrish]

<ms:laurl> is a Microsoft-specific extension. In general, a web-based client should know its own endpoints, but some end-to-end DASH implementations will put information like this into manifest extensions for convenience. YouTube does this, for example, but with a different extension.

As a generic client, Shaka Player does not parse any of these extensions directly. However, we do support extensions to <ContentProtection> with an application callback. So as long as the license server URL is in an extension to <ContentProtection>, applications can already parse these and provide detailed DRM information to Shaka through the callback.

[joeyparrish]

Is there general interest in us adding ms:laurl support directly in the DASH parser? Please speak up and tell us if this is important, so we can schedule it accordingly.

In terms of behavior, should ms:laurl override the player's config? Or vice-versa? My inclination is for player config to take precedence, so you can override bad content, but I could be wrong.

[sandersaares]

My inclination is for player config to take precedence, so you can override bad content, but I could be wrong.

I agree with this interpretation - anything coming from the mpd should be the default value, to be overridden by the app controlling the player if it decides to.

This comment is not intended as a signal of interest in seeing this feature implemented, though. In practice, I have never encountered a situation where the player cannot simply be told what license server to use. The less "operational" info in the manifest the better IMO.

[BucherTomas]

I also agree that player config should serve as an overriding mechanism. In descending order of precedence player config -> manifest -> init segment.

On the other hand, I do believe that the player could provide the option to parse the license server URL from the manifest.

We already expressed our interest earlier https://groups.google.com/forum/#!topic/shaka-player-users/YGLcAxXfMf4 ,however, that was regarding different approach of embedding license URL into the manifest by using another extension mspr:pro and license URL stored in binary data as part of PlayReady PSSH according to this specification http://download.microsoft.com/download/7/7/6/7762455C-D254-4C84-BE17-16B0C60E31FD/MPEG%20DASH%20PlayReady%201.2%20-%202014-10-08.pdf.

This is utilized for instance by Wowza Streaming Engine and one of Shaka's own testing assets is based on that, too - Azure Media Services/Big Buck Bunny. It is currently unnecessarily hidden from the asset list although it is working fine at this time.

This is not an intention to hijack the thread that concerns ms:laurl. It just points out that there is another method of license URL provisioning, although more complex, that some big names in industry are using and Shaka could make it viable for integrators to support both when giving the option to parse the manifest for license server URL.

[joeyparrish]

Okay. I'll update the issue title to include both ms:laurl and ms:pro. Tentatively scheduled for v2.3.0.

[chrisfillmore]

I see that our content includes mspr:pro blocks as well. However, we make no use of this information on web clients. (Other PlayReady clients, e.g. UWP, may use it.)