Playready message format UTF8 vs. UTF16

[dsilhavy]

Taken from f8c0ccc

From @markriley9999

Hi

i know that this is a very old ticket! :)
we're looking to use DASHJS on our platform, across many different devices (TVs, STBs) - the majority of devices have a PR CDM which uses the UTF16 format, however some use UTF8.

So, one solution is to maintain a list of clients which require the UTF8 format and use the the setPlayReadyMessageFormat call accordingly.
However, creating and maintaining such a list does add complexity to a large platform.

One potential approach that I am looking at is to propose to manufacturers that they ensure that they standardise on UTF16 - however, this may be a big ask, and it's possible that some manufacturers may not meet this requirement.

Or, i'm wondering as to whether DASHJS could support an option to auto-detect (infer) the format, for example:

• if odd number of bytes then format = UTF8 OR
• if any 'even offset' byte != 0 then format = UTF8 (for a sample of the buffer)
  this could be enabled by calling setPlayReadyMessageFormat("autodetect")

any opinions gratefully received! :)

[dsilhavy]

@swenkeratmicrosoft Can you maybe provide some insights here if the approach above is valid?

[swenkeratmicrosoft]

@dsilhavy

It looks like you're attempting to parse it using a DOM parser. If that's the only reason you need to parse it, couldn't you just attempt to parse it as UTF-16 and if it fails try again using UTF-8?

[markriley9999]

I'm actually intrigued as to why the response needs to be parsed at all (apologies, but i haven't studied the code sufficiently yet to answer that question for myself!) - but taken it at face-value, surely the dashjs player should be agnostic to the client / licence server messages and simply pass them through 'untouched' (as a simple byte array)?

also, @swenkeratmicrosoft - are PR CDM clients sending UTF-8 'messages' strictly speaking compliant? Does Microsoft mandate what the 'message format' should be?

[markriley9999]

I've just taken a peak at the code and it would appear that my assertion above is correct for non-Edge CDMs, eg SmartTVs - ie, thw Edge browser sends a wrapped message, which needs to be parsed/unwrapped - however, other device CDMs send the raw message which does not need to be parsed.

So, the scenario that i'm reporting is when a none Edge device, sends a raw UTF-8 message - which fails to be parsed (as it is assumed to be UTF-16), however the (failed) parse is not necessary (as the message is a raw message, ie not wrapped).

Have i understood this correctly?

[markriley9999]

Hi @swenkeratmicrosoft , @dsilhavy

fyi, to test this assertion i've modified dashjs slightly in 2 funcitons (getRequestHeadersFromMessage and getLicenseRequestFromMessage).

Here:

 function getRequestHeadersFromMessage(message) {
    var msg, xmlDoc;
    var headers = {};
    var parser = new DOMParser();
    
    // If message format configured/defaulted to utf-16 AND number of bytes is odd, assume 'unwrapped' raw CDM message.
    if (messageFormat === 'utf-16' && message.byteLength % 2 === 1) {
      headers['Content-Type'] = 'text/xml; charset=utf-8';
      return headers;
    }
   ....

and here:

  function getLicenseRequestFromMessage(message) {
    var licenseRequest = null;
    var parser = new DOMParser();

    // If message format configured/defaulted to utf-16 AND number of bytes is odd, assume 'unwrapped' raw CDM message.
    if (messageFormat === 'utf-16' && message.byteLength % 2 === 1) {
      return message;
    }
   ...

tbh, it's more of a 'pragmatic workaround', than a fix (to handle 'unwrapped' raw, utf-8 messages). however, it helped me test the theory, and i can now see that my test device (TV) now works with the test PlayReady content.

you may want a slightly more elegant solution - but it did at least test the theory! :)

test app here:
https://duk-testcontent.s3.eu-west-2.amazonaws.com/liteplayer/index.html?streamid=PR0009&verbose=1

content here:
https://refplayer-dev.cloud.digitaluk.co.uk/dynamic/ngp-ssai-sl2000.mpd

[Murmur]

Link to a ticket about the same issue. Yes it would be nice to have an automatic sense of utf16|utf8 messageFormat value.
#3899