fix(DRM): close properly webkit media key sessions #6775
Conversation
avelad
added
type: bug
|
@shaka-bot test |
|
@avelad: Lab tests started with arguments:
|
|
Incremental code coverage: 82.76% |
On WebOS 3.0 we've noticed an issue in production, where TVs are slowly
starting to throw the following error after a user has watched at least
30+ episodes: `Code: 6006 Category: 6 Severity: 2 ["EME v0.1b key
error",{"errorCode":{"code":1,"systemCode":65535}},"0xffff"]` and can
only be resolved by clearing the app cache, or unplugging the TV.
Further investigation revealed that current workflow, where MSE is
destroyed before DRM Engine causes that old EME implementation is not
able to close session properly.
On WebOS 3.0 we've noticed an issue in production, where TVs are slowly
starting to throw the following error after a user has watched at least
30+ episodes: `Code: 6006 Category: 6 Severity: 2 ["EME v0.1b key
error",{"errorCode":{"code":1,"systemCode":65535}},"0xffff"]` and can
only be resolved by clearing the app cache, or unplugging the TV.
Further investigation revealed that current workflow, where MSE is
destroyed before DRM Engine causes that old EME implementation is not
able to close session properly.
| // EME v0.1b requires the media element to clear the MediaKeys | ||
| if (shaka.util.Platform.isMediaKeysPolyfilled('webkit') && | ||
| this.drmEngine_) { | ||
| await this.drmEngine_.destroy(); |
There was a problem hiding this comment.
Is there a downside to destroying DRM engine this early in all cases? Do we need two paths for this?
There was a problem hiding this comment.
We wanted to make this patch not invasive as much as possible. But I agree though, having diverged paths is not elegant. I can try to move drm engine teardown before the MSE one.
There was a problem hiding this comment.
@tykus160 please create a feat with the change
There was a problem hiding this comment.
Hey @joeyparrish @avelad
According to EME spec:
Support for clearing or replacing the associated
MediaKeysobject during playback is a quality of implementation issue. In many cases it will result in a bad user experience or rejected promise.
In Chrome if I move drm destroy before mse, next playbacks of protected content are starting to stall after few secs. I’m using Angel One to test, I guess first few secs are clear there... I'm not sure why it is like that, but I see that MediaKeys are attached to the video element.
Explicitly unloading video element in DRM Engine before setting MediaKeys to null seems to fix the issue mentioned above and I see no drawbacks across Chrome, Firefox & Safari in MSE mode. I need to check though how it behaves on SmartTVs.
On WebOS 3.0 we've noticed an issue in production, where TVs are slowly starting to throw the following error after a user has watched at least 30+ episodes:
Code: 6006 Category: 6 Severity: 2 ["EME v0.1b key error",{"errorCode":{"code":1,"systemCode":65535}},"0xffff"]and can only be resolved by clearing the app cache, or unplugging the TV.Further investigation revealed that current workflow, where MSE is destroyed before DRM Engine causes that old EME implementation is not able to close session properly.