Issue metadata
Sign in to add a comment
|
EME key session times out after 15 seconds and therefore does not decrypt media on slow license requests
Reported by
bernhard...@maxdome.de,
Jan 18 2017
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Throttle your internet connection (1 kbps) to the DRM license server http://drm-widevine-licensing.axtest.net 2. Start dash.js reference player http://dashif.org/reference/players/javascript/v2.4.0/samples/dash-if-reference-player/index.html 3. Choose encrypted content 'Axinom Test Content (v7.0; modern)' -> '1080p with Playready and Widevine DRM, single key' 4. Start the video and wait 15s 5. Finally release the throttle to the DRM license server and watch the request receiving successfully What is the expected behavior? Encrypted media should be decrypted after DRM license request finally is received What went wrong? Encrypted media is NOT decrypted after DRM license request finally is received. So screen stays black. If you wait for the DRM license call 10 instead of 15 seconds, everything is working well and video starts playing Did this work before? Yes Chrome 54, 53, 52, ... Does this work in other browsers? Yes Chrome version: 55.0.2883.95 Channel: stable OS Version: OS X 10.11.4 Flash Version: Shockwave Flash 24.0 r0 This has always worked well on all other version prior to 55
,
Jan 28 2017
Assigning to xhwang@ for triage.
,
Jan 30 2017
Sounds like idle suspend. We probably need a callback when EME makes progress, since that's not included in didLoadingProgress(). Assuming that is the issue, being able to query Blink for playback status would once again also help.
,
Feb 8 2017
,
Feb 8 2017
sandersd: Could you please help look into this and see what the proper fix should be?
,
Feb 14 2017
WMPI already has a mechanism for this, the 'preroll_attempt_pending_' flag. Right now we kick a preroll attempt each time that didLoadingProgress() returns true. We need to get a callback in WMPI whenever a stalled demuxer/decoder can make progress again; I suspect that would be a key added callback from the Decryptor in this case, but I'm not sure if that is exactly the right signal. As a short-term fix, we can disable suspending encrypted media on Desktop.
,
Feb 14 2017
+jrummell Will it work if we fix this TODO? https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?rcl=8d7a71b75fff2d64a8cc192295fcdb4eb03987f4&l=1378 Basically when a new usable key is available, we should call encrypted_client_->didResumePlaybackBlockedForKey() in WMPI. Then WMPI can resume the playback I guess. jrummell: Does it make sense to fix this TODO now? It seems reasonable to do and shouldn't be hard.
,
Feb 14 2017
Also, we should add a test for this case. Maybe have a test that add the key after some delay to simulate this issue. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by tkonch...@chromium.org
, Jan 19 2017