Waitingforkey event erroneously prevents content from playing
Reported by
daniel.s...@fokus.fraunhofer.de,
Feb 9 2017
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Implement a small MSE/EME player as done in the two attached files. 2. Try to play Widevine DRM protected content with the persistent state attribute set to "required". 3. Chrome will make two license requests to the Widevine proxy, the first one will only have a 2byte payload. 4. Chrome will throw two waitingforkey events and the playback will not start even if the user presses the play button multiple times. However, our tests showed that the playback does start if the user manually seeks forward. What is the expected behavior? We would expect the content to be played after a valid license has been received. What went wrong? - Chrome will throw two waitingforkey events and the playback will not start even if the user presses the play button multiple times. However, our tests showed that the playback does start if the user manually seeks forward. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 The same test page + Widevine proxy + content works fine in Firefox.
,
Feb 10 2017
Please provide the attachment.
,
Feb 13 2017
Sorry somehow the attachment got lost in the initial post.
,
Feb 20 2017
Able to reproduce this issue on Win 10, ubuntu 14.04 and Mac 10.12.3 using chrome stable #56.0.2924.87 and Canary #58.0.3018.0. Issue is broken in M52. Bisect Info: =========== Good build : 52.0.2735.0, Revision Range - 393409 Bad build : 52.0.2737.0, Revision Range - 393757 After executing the old bisect script , i got the following CL's between good and bad build versions =========================================== https://chromium.googlesource.com/chromium/src/+log/4f172e11f23ed76695160b8d7ce74bea487918d5..ac9ef746e4c0c207d7b02ddd9db894ae21044636 Unable to find the culprit CL which caused this issue, requesting dev team to look into it and assign it to the concern owner. Thank You...
,
Nov 7 2017
Hi All, I'm having the same issue, isn't there a solution when persistenState = "required" is set? Thanks to all and best regards.
,
Nov 8 2017
Hi, I've the same issue when I set the persistentState to required. Did you have any idea how to resolve it? Thanks in advance, Regards, Claudio |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ligim...@chromium.org
, Feb 10 2017