in-band key rotation not working with Xbox One

[caridley]

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

What version of Shaka Player are you using?
3.1.2 with customizations

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

Can you reproduce the issue with the latest code from main?
Yes tested with main branch commit 25fd4f4 from 8/9/2022

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

If custom app, can you reproduce the issue using our demo app?
I have not been able to get the demo app to run on the Xbox

What browser and OS are you using?
Xbox One

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Xbox One S - OS version 10.0.22000.4976

What are the manifest and license server URIs?
Will send via e-mail

What configuration are you using? What is the output of player.getConfiguration()?
see attached file configuration.txt

What did you do?
Playing stream with in-band key rotation signaled with a new KID in the moof/traf/sgpd box
Keys change every 10 minutes

What did you expect to happen?
Playback should continue through key changes uninterrupted, and we should see DRM license requests.

What actually happened?
When the key changes playback fails with an error like this

Shaka Error MEDIA.VIDEO_ERROR (5,8004b82b,)","code":3016,"category":3,"data":[5,"8004b82b",null]

The same stream works as expected with 2017 Samsung TV and Chrome on Mac

Debug log
RemconAvc_20220811_1130.log

Charles proxy capture of manifest, media-segment and license requests at stream start and point of failure

AvcInBandKeyRotation_20220811_1130_pruned.chls.zip

key change occurred on segment number 830119800

segment SpecNews_AVC-audio_105285_spa104800-830119799.m4s
has KID is eb36782fac245385b789bce12011a9e2

segment SpecNews_AVC-audio_105285_spa104800-830119800.m4s
has KID is 6624cf9f8a15598e91435cad17613e70

[joeyparrish]

The same stream works as expected with 2017 Samsung TV and Chrome on Mac

Chrome on Mac uses Widevine rather than PlayReady. On Samsung TV, which DRM are you using?

Looking through your log file, I see license requests sent at these times:

• 11:31:34.733
• 11:31:40.155

And the error at this time:

• 11:40:08.545

The requests that are 6 seconds apart are for two different sessions, and both are of type license-request. The error is 8.5 minutes after the license request.

What is the key rotation period?

What is the structure of the keys and tracks? (For example, one set of keys for video, one for audio, or one set for SD video, one for HD, one for UHD, etc.)

Thanks!

[caridley]

We use playready on Samsung TVs

Keys rotation occurs every 10 minutes, starting on the hour, then at 10 past etc...

Still trying to get a definitive answer on use of track specific keys

[caridley]

I'm not sure why we are getting two license requests, at startup. It looks like the same KID is used in all init and media segments fetched prior to the second key request


In the init segments default_KID in moov.trak.mdia.minf.stbl.stsd.encv.sinf.schi.tenc is eb36782fac245385b789bce12011a9e2

In the media segments KID in moof.traf.sgpd is the same value eb36782fac245385b789bce12011a9e2


[joeyparrish]

Based on the timing of the error, the key rotation period, and the fact that the license requests were grouped early in the session, I would guess that we're not fetching the next key for the next key rotation period.

This should be done through encrypted events, which are triggered whenever a media segment is appended which contains one or more pssh boxes. We only listen to the encrypted event if there is no PSSH in the manifest, or if the configuration manifest.dash.ignoreDrmInfo is set to true.

So either we're not listening to the event, or it didn't happen. I see that your config has ignoreDrmInfo set to false. If your manifest has PSSH info in the XML, please set this config to true.

If that doesn't work, please check that in your content, either:

1. there is a new init segment at key rotation period boundaries, and each init segment contains a PSSH box
2. or the media segments are self-initializing, and new PSSH boxes appear in new key rotation periods
3. or the media segments in new key rotation periods contain new PSSH boxes independent of other init segment data (not sure if this is a thing, but I think it might work with the logic of the browser's encrypted events)

Does this help?

[caridley]

The manifest does not contain PSSH

I think this approach is used -

3. or the media segments in new key rotation periods contain new PSSH boxes independent of other init segment data (not sure if this is a thing, but I think it might work with the logic of the browser's encrypted events)

Note that this stream does work as expected on 2017 Samsung TV and Chrome on Mac OS

I have attached a Charles Proxy capture containing the manifest and media segments in the vicinity of the key change at segment number 830119800

[caridley]

My guess is that the Xbox is not emitting the encrypted event in this situation. Is it feasible to detect the key change by parsing the PSSH in the media segments in shaka player?

[joeyparrish]

Yes, it's entirely possible that Xbox is not generating encrypted events. EME on Xbox seems pretty broken.

We could "polyfill" that by parsing for PSSH ourselves. We already have the parser. I would be more than willing to review a PR to add something like that.

I haven't thought through where that would best be added, but segment data doesn't pass through DrmEngine today. So it would need to touch DrmEngine as well as either StreamingEngine or MediaSourceEngine.

I think it could be made generic, with a config to decide whether to use browser encrypted events or local parsing. That config could be made to default to true for Xbox.

[joeyparrish]

@caridley, would you be willing to work on a PR for this?

[caridley]

Yes.. I should be able to start on this next week.

[joeyparrish]

Thanks!