{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/encrypted-media/issues/339","repository_url":"https://api.github.com/repos/w3c/encrypted-media","labels_url":"https://api.github.com/repos/w3c/encrypted-media/issues/339/labels{/name}","comments_url":"https://api.github.com/repos/w3c/encrypted-media/issues/339/comments","events_url":"https://api.github.com/repos/w3c/encrypted-media/issues/339/events","html_url":"https://github.com/w3c/encrypted-media/issues/339","id":183539732,"number":339,"title":"Should there be flexibility in when readyState is updated when waiting for a key?","user":{"login":"ddorwin","id":9738764,"avatar_url":"https://avatars.githubusercontent.com/u/9738764?v=3","gravatar_id":"","url":"https://api.github.com/users/ddorwin","html_url":"https://github.com/ddorwin","followers_url":"https://api.github.com/users/ddorwin/followers","following_url":"https://api.github.com/users/ddorwin/following{/other_user}","gists_url":"https://api.github.com/users/ddorwin/gists{/gist_id}","starred_url":"https://api.github.com/users/ddorwin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ddorwin/subscriptions","organizations_url":"https://api.github.com/users/ddorwin/orgs","repos_url":"https://api.github.com/users/ddorwin/repos","events_url":"https://api.github.com/users/ddorwin/events{/privacy}","received_events_url":"https://api.github.com/users/ddorwin/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/encrypted-media/labels/Interoperability","name":"Interoperability","color":"5319e7"},{"url":"https://api.github.com/repos/w3c/encrypted-media/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/w3c/encrypted-media/milestones/3","html_url":"https://github.com/w3c/encrypted-media/milestones/V1NonBlocking","labels_url":"https://api.github.com/repos/w3c/encrypted-media/milestones/3/labels","id":1637384,"number":3,"title":"V1NonBlocking","description":"Those issues are editorial or substantive for V1 and may get done within the V1 timeframe. All substantive issues will be moved to V.Next after June 9th.\r\n","creator":{"login":"ddorwin","id":9738764,"avatar_url":"https://avatars.githubusercontent.com/u/9738764?v=3","gravatar_id":"","url":"https://api.github.com/users/ddorwin","html_url":"https://github.com/ddorwin","followers_url":"https://api.github.com/users/ddorwin/followers","following_url":"https://api.github.com/users/ddorwin/following{/other_user}","gists_url":"https://api.github.com/users/ddorwin/gists{/gist_id}","starred_url":"https://api.github.com/users/ddorwin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ddorwin/subscriptions","organizations_url":"https://api.github.com/users/ddorwin/orgs","repos_url":"https://api.github.com/users/ddorwin/repos","events_url":"https://api.github.com/users/ddorwin/events{/privacy}","received_events_url":"https://api.github.com/users/ddorwin/received_events","type":"User","site_admin":false},"open_issues":5,"closed_issues":25,"state":"open","created_at":"2016-03-10T19:55:05Z","updated_at":"2016-10-17T22:00:17Z","due_on":"2016-06-09T04:00:00Z","closed_at":null},"comments":1,"created_at":"2016-10-17T22:00:17Z","updated_at":"2016-10-18T20:37:32Z","closed_at":null,"body":"Similar to #336, browsers may update `readyState` at different times. For example, Chrome currently waits three seconds before pausing playback due to video underflow to avoid glitching when the decoder falls slightly behind. The easiest and most consistent thing for Chrome to do would be to use the same behavior for missing key(s).\r\n\r\nHowever, the Wait for Key algorithm currently requires that the `readyState` be updated before the `waitingforkey` event is fired (because it is fired by a task).\r\n\r\nDo we want to be this prescriptive or should we provide more implementation flexibility? The suggestion in https://github.com/w3c/encrypted-media/issues/336#issuecomment-254346323 might also provide such flexibility for this case.\r\n\r\n@foolip @cpearce"},"comment":{"url":"https://api.github.com/repos/w3c/encrypted-media/issues/comments/254631937","html_url":"https://github.com/w3c/encrypted-media/issues/339#issuecomment-254631937","issue_url":"https://api.github.com/repos/w3c/encrypted-media/issues/339","id":254631937,"user":{"login":"xhwang-chromium","id":10169438,"avatar_url":"https://avatars.githubusercontent.com/u/10169438?v=3","gravatar_id":"","url":"https://api.github.com/users/xhwang-chromium","html_url":"https://github.com/xhwang-chromium","followers_url":"https://api.github.com/users/xhwang-chromium/followers","following_url":"https://api.github.com/users/xhwang-chromium/following{/other_user}","gists_url":"https://api.github.com/users/xhwang-chromium/gists{/gist_id}","starred_url":"https://api.github.com/users/xhwang-chromium/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xhwang-chromium/subscriptions","organizations_url":"https://api.github.com/users/xhwang-chromium/orgs","repos_url":"https://api.github.com/users/xhwang-chromium/repos","events_url":"https://api.github.com/users/xhwang-chromium/events{/privacy}","received_events_url":"https://api.github.com/users/xhwang-chromium/received_events","type":"User","site_admin":false},"created_at":"2016-10-18T20:37:32Z","updated_at":"2016-10-18T20:37:32Z","body":"Scope:\r\n\r\nThis is about the case where we run out of decoded video frames. It’s not related to network data. This affects all playbacks with audio AND video, for both MSE and SRC, with and without EME. This does not affect audio-only (where there’s no video) and video-only (where we don’t apply this logic) playbacks.\r\n\r\nContext:\r\n\r\nPreviously we would trigger the pipeline to underflow immediately after we run out of decoded video frames. This caused some issues because relatively small video decoding delay (e.g. JS or device becomes busy) would pause-then-resume the playback and cause an audio glitch. This is much more noticeable to users than some dropped video frames. So we added the delay to alleviate this issue and only declare underflow when we run out of video frames for a certain period of time [1].\r\n\r\nAn alternative solution is to buffer more video frames in our media pipeline, but that could mean slower start-to-play time and more memory usage.\r\n\r\nOverall, I feel this is an implementation quality issue, not a spec compliance issue. The 3-sec choice is a bit arbitrary, but the idea of having some grace period seems still valid to me.\r\n\r\nReference:\r\n[1] Original CL: https://codereview.chromium.org/470773002/"}}
{"actor":{"display_login":"xhwang-chromium"}}