Add option to disable EME expiration events

[hbofolts1]

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

What version of Shaka Player are you using?
2.5.0

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

Can you reproduce the issue with the latest code from master?
Yes

Are you using the demo app or your own custom app?
Both recreate the issue, yes.

If custom app, can you reproduce the issue using our demo app?
Yes

What browser and OS are you using?
EDGE 18.18362 on Windows 10 and also XBOX

What are the manifest and license server URIs?
Asset is encrypted with PlayReady.

What did you do?
Start playback of a dash manifest encrypted with playready.

What did you expect to happen?
Playback played back without interruption

What actually happened?
Video playback struggles, every few frames the video appears to get stuck and no dropped frames are reported.

I have been digging into an issue where XBOX is having an issue where it "stutters". The shaka player is being used on XBOX and the content is encrypted with PlayReady. Upon diagnosing this issue I eventually discovered there is an expirationTimer running every second. When I add a rudimentary timer around the call to session.expired I see this call taking around 1000 milliseconds consistently. This expirationTimer appears to be a no-op for dash manifests and it would be nice to have a way to disable this timer as it is impacting video playback on XBOX. This ticket may make more since as a feature request. As far as I can tell there is no way to disable the timer and the cost of checking the expiration seems expensive with the playready cdm on EDGE.

https://github.com/google/shaka-player/blob/v2.4.x/lib/media/drm_engine.js#L1708

[hbofolts1]

This was with playready 3.0 and different keys on video and audio.

[TheModMaker]

That function isn't a no-op, it is used to update the expiration of EME sessions. This is used to update metadata for offline content and to fire an event for the app when the expiration changes. Unfortunately there is no way for us to get an event when the expiration changes, so we need to poll. Expiration is important for apps so they can show UI or change streams when approaching the expiration time.

But since this is an app event, we could add a configuration value to disable this timer. This will be a low-priority enhancement, but we'd be happy to review a PR.

[joeyparrish]

I'm very surprised that it takes a full second. Can you tell us how many sessions are being updated in your case? (The length of this.activeSessions_)

If the callback through player to the DASH parser is a no-op, the only thing taking up time should be the loop over sessions and asking the browser to give us the expiration time. If the loop only has a small number of iterations, it could be that asking for the expiration time is surprisingly expensive on XBox. If we know those details, it could help us build a more efficient solution for that platform.

[hbofolts1]

If I recall correctly there were 3 sessions. The application which I use shaka for uses a separate key for audio, SD video, and HD video. I was also very surprised when I saw it taking so long. The issue was also noticeable on windows desktop with EDGE. To resolve the issue I have commented out the expirationTimer for the time being.

https://github.com/google/shaka-player/blob/master/lib/media/drm_engine.js#L109

The assets I am provided come from an external source. That source is starting to test new changes they are making to their assets and this issue was spotted. The old assets and the new assets they have provided me with both use 3 sessions. The old assets work fine and make the call in a reasonable time similar to chrome where it is around 0ms and not a noticeable synchronous interruption. With the new assets the time for that call on EDGE (or XBOX) jumped significantly.

[joeyparrish]

That is really interesting. I would be very interested to know what the expiration values are. For example, (this is pure speculation, and I know nothing about PlayReady), perhaps the old assets have a "never expire" policy of some kind, in which case expiration would be NaN. If the new assets now expire at a specific time, there may be an async call to another process to get the expiration time from the CDM, which could be very slow on XBox.

Again, pure speculation. Can you instrument the expiration times for the old and new assets to give us one more data point? I may be able to contact someone at Microsoft to chase down an answer if we have enough information.

[hbofolts1]

Collected some real data today versus the rough estimates I provided when making this ticket in haste.

The new content I referenced above has 2 active sessions and an expiration for each. The previous content had 1 active session and also an expiration. The expiration time is 5 hours for both sessions. One of the sessions is for audio and one is for video.

On both the old and new content it is taking the call to expiration 50-100ms. When there are 2 active sessions this blocking for 50-100ms gets more noticeable as it happens twice.

Another interesting tidbit is that if I continually restart playback without refreshing the overall page the call to expiration takes longer and longer. This can be recreated on the shaka demo page.

This is the timing code I quickly threw into the compiled source:

var startTime = new Date().getTime();
var b=a.oldExpiration,c=a.session.expiration;
console.log("EXPIRATION: " + c);
console.log("TOOK: " + ((new Date()).getTime() - startTime));

I pulled this data on a windows desktop with the most recent EDGE browser but similar behavior is seen on XBOX.

[joeyparrish]

#2456 has brought up another need for this option. Some policies on Tizen 5 report the wrong expiration time.

[joeyparrish]

If anyone is interested to contribute a PR for this, please let us know!