PlayReady Object with invalid length encountered.

[stuartflanagan]

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

What version of Shaka Player are you using?
3.0.7

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

Can you reproduce the issue with the latest code from master?
I have not tried with master.

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

If custom app, can you reproduce the issue using our demo app?
I have not tried with the demo app.

What browser and OS are you using?
webOS5

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?

I will email manifest and LA URLs

What did you do?

We have a multi DRM stream set up for PlayReady and Widevine. The webOS5 TV states it supports both and shaka tends to choose PlayReady when we provide both types to the configuration.
I am suspecting an issue with our manifest but cannot quite find the issue as playback with Playready is successful on other devices. webOS4 and Tizen 4/5

What did you expect to happen?
Multi DRM stream to playback with best possible DRM type.

What actually happened?

We provide LA URLs for both Widevine and Playready shaka chooses Playready and then a warning is logged: PlayReady Object with invalid length encountered.
Then an error 6006 is thrown with severity 2

[stuartflanagan]

The Playready streams from the demo work fine both single and MultiDRM.

[stuartflanagan]

Please let me know if you require more information to investigate this issue.

[stuartflanagan]

Is there anyway to know which DRM types are supported from the Shaka API so we can make a decision if we have a preference. As it seems that Playready error is always thrown but if we just only add widevine then there is no issue. We cannot just add widevine though as some devices do not support widevine.

[TheModMaker]

This error comes from here. This means the PRO found in the manifest isn't valid since the first four bytes should be the length. I'm not that familiar with with the PRO format, so I don't know how correct it is. It does look similar to a PRO so it isn't a PSSH instead.

You can configure priority by setting the order of the ContentProtection elements in the manifest. If you can't control the manifest, you can follow #3002 where we'll add a configuration option for this.

[avelad]

PlayReady info: https://docs.microsoft.com/en-us/playready/specifications/mpeg-dash-playready#scheme

[stuartflanagan]

Thank you.

I provided the manifest for this particular scenario to the support email address.

It is a bit hard to tell at present if this is a device issue or a manifest issue. The manifest does play and decode well on some devices that support playready. Atpresent the issues are experienced on newer webOS and Tizen devices. WebOS5 and Tizen 5 with CENC manifests.

[TheModMaker]

The <mspr:pro> element in your manifest is invalid. It should contain a PRO binary object but instead contains the PlayReady Header XML data.

[stuartflanagan]

Thank you! I will confirm with our packaging team if we can get this updated. I am pretty sure we are using 8Byte IV could this be a factor?

[joeyparrish]

I don't think the IV is the issue. It's placing a PlayReady XML object into <mspr:pro> instead of a PRO object.

[stuartflanagan]

Thank you @joeyparrish I just decoded the mspr:pro content from here: https://docs.microsoft.com/en-us/playready/specifications/mpeg-dash-playready#32-including-a-playready-object-pro-in-the-mpd
And the format seems to be the same as our manifest. The PlayReady XML.

<WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.0.0.0"><DATA><PROTECTINFO><KEYLEN>16</KEYLEN><ALGID>AESCTR</ALGID></PROTECTINFO><KID>RAhjCxfLakmXADcC4dI+4g==</KID><CHECKSUM>qhKWHJaL01I=</CHECKSUM><LA_URL>http://playready.dyndns.org/contososspr/rightsmanager.asmx</LA_URL><DS_ID>iKGlWG4DXUq4wbWgRNLRJg==</DS_ID></DATA></WRMHEADER>

[stuartflanagan]

Actually I do see 4 invisible characters at the beginning of that header. Is that the part we are missing?

[TheModMaker]

It should be a PRO object, not the XML. The XML will be in the PRO object somewhere, but you need to wrap it in a valid PRO object. Check out https://docs.microsoft.com/en-us/playready/specifications/playready-header-specification#2-playready-object-pro for the format. One of the entries in the PRO object will be the PlayReady Header (PRH, the XML you posted).

[stuartflanagan]

Thank you I will investigate with our encoding team further.
Can you confirm that Base64 decoding the mspr:pro from the above example does display the XML content from the above Microsoft example?
https://docs.microsoft.com/en-us/playready/specifications/mpeg-dash-playready#32-including-a-playready-object-pro-in-the-mpd

Example:

<mspr:pro>6gIAAAEAAQDgAjwAVwBSAE0ASABFAEEARABFAFIAIAB4AG0AbABuAHMAPQAiAGgAdAB0AHAAOgAvAC8AcwBjAGgAZQBtAGEAcwAuAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0ALwBEAFIATQAvADIAMAAwADcALwAwADMALwBQAGwAYQB5AFIAZQBhAGQAeQBIAGUAYQBkAGUAcgAiACAAdgBlAHIAcwBpAG8AbgA9ACIANAAuADAALgAwAC4AMAAiAD4APABEAEEAVABBAD4APABQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsARQBZAEwARQBOAD4AMQA2ADwALwBLAEUAWQBMAEUATgA+ADwAQQBMAEcASQBEAD4AQQBFAFMAQwBUAFIAPAAvAEEATABHAEkARAA+ADwALwBQAFIATwBUAEUAQwBUAEkATgBGAE8APgA8AEsASQBEAD4AUgBBAGgAagBDAHgAZgBMAGEAawBtAFgAQQBEAGMAQwA0AGQASQArADQAZwA9AD0APAAvAEsASQBEAD4APABDAEgARQBDAEsAUwBVAE0APgBxAGgASwBXAEgASgBhAEwAMAAxAEkAPQA8AC8AQwBIAEUAQwBLAFMAVQBNAD4APABMAEEAXwBVAFIATAA+AGgAdAB0AHAAOgAvAC8AcABsAGEAeQByAGUAYQBkAHkALgBkAHkAbgBkAG4AcwAuAG8AcgBnAC8AYwBvAG4AdABvAHMAbwBzAHMAcAByAC8AcgBpAGcAaAB0AHMAbQBhAG4AYQBnAGUAcgAuAGEAcwBtAHgAPAAvAEwAQQBfAFUAUgBMAD4APABEAFMAXwBJAEQAPgBpAEsARwBsAFcARwA0AEQAWABVAHEANAB3AGIAVwBnAFIATgBMAFIASgBnAD0APQA8AC8ARABTAF8ASQBEAD4APAAvAEQAQQBUAEEAPgA8AC8AVwBSAE0ASABFAEEARABFAFIAPgA=</mspr:pro>

Decoded:

����<WRMHEADER xmlns="http://schemas.microsoft.com/DRM/2007/03/PlayReadyHeader" version="4.0.0.0"><DATA><PROTECTINFO><KEYLEN>16</KEYLEN><ALGID>AESCTR</ALGID></PROTECTINFO><KID>RAhjCxfLakmXADcC4dI+4g==</KID><CHECKSUM>qhKWHJaL01I=</CHECKSUM><LA_URL>http://playready.dyndns.org/contososspr/rightsmanager.asmx</LA_URL><DS_ID>iKGlWG4DXUq4wbWgRNLRJg==</DS_ID></DATA></WRMHEADER>

[stuartflanagan]

So sort of assuming the first 4 binary chars are the PRO object and the rest is the PRH.

Record Type | WORD | 16 | Specifies the type of data stored in the Record Value.
0x0001 | Indicates that the record contains a PlayReady Header (PRH).

We are using Bento to package the manifests.

[joeyparrish]

Here's a table of the PRO format from the doc that @TheModMaker linked to (https://docs.microsoft.com/en-us/playready/specifications/playready-header-specification#2-playready-object-pro):

Field name	Field type	Size (bits)	Description
Length	DWORD	32	The length of the PlayReady Object in bytes. This value should not exceed 15 kilobytes (KB).
PlayReady Object Record Count	WORD	16	Specifies the number of PlayReady Object Records in the PlayReady Object.
PlayReady Object Records	BYTE array	Varies	Contains a variable number of records that contain information related to licenses and license acquisition.

Here's a table for those PRO records that go inside the third field of the PRO (what you quoted above):

Field name	Field type	Size (bits)	Description
Record Type	WORD	16	Specifies the type of data stored in the Record Value.
Record Length	WORD	16	Specifies the size in bytes of the Record Value.
Record Value	BYTE array	Varies	The content of the object depends on the value of Record Type.

[joeyparrish]

If the output of Bento doesn't follow this spec, then it's a Bento bug and you should follow up with them. Thanks!

[stuartflanagan]

Thanks @joeyparrish Yes I think it is a bug in the packager that created the content. It seems quite a few other PlayReady players IE oipf A/V and Tizen player are tolerant of this issue so it slipped by.

Thank you for your help in tracking down the issue. Now to repackage:)