EME robustness warning is unnecessary and confusing |
||||
Issue descriptionChrome Version: 58.0.3029.96 (Official Build) (64-bit) OS: Goobuntu What steps will reproduce the problem? (1) Open Shaka Player demo: https://shaka-player-demo.appspot.com/demo/ (2) Open JS console (3) Observe the Chrome-generated warning message: "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior, potentially including failure to play." The EME spec states of robustness: "The empty string indicates that any ability to decrypt and decode the content type is acceptable." I believe Chrome should not warn when the empty string is given by the application. The empty string is explicitly allowed by the spec and given a meaningful definition. The warning, as it stands today, is unhelpful and confusing. I believe "including failure to play" is particularly ominous and unwarranted. If the spec states that "any ability to decrypt and decode is acceptable", then I do not see how "failure to play" is an acceptable outcome based purely on unspecified robustness. The "failure to play" part also does not appear to be true, as I have never seen a blank robustness string cause failure to play in Chrome. Instead, failures caused by other issues are mistakenly attributed to robustness because of the warning. Examples of confusion/concern over this warning: https://github.com/google/shaka-player/issues/786#issuecomment-299562819 https://github.com/google/shaka-player/issues/470#issuecomment-236302614 https://github.com/google/shaka-player/issues/518 https://github.com/google/shaka-player/issues/518#issuecomment-272348966 https://github.com/google/shaka-player/issues/578#issue-188132301 https://github.com/google/shaka-player/issues/656#issuecomment-273385693 Since this warning is misleading and unhelpful, I propose that it should be removed.
,
Aug 11 2017
Any reason we shouldn't go ahead and remove it? I continue to see it cited in bug reports. When people see that, they tend to stop looking for real clues. Removal should be straightforward, right?
,
Aug 11 2017
,
Aug 29 2017
As discussed offline, the warning is still necessary and we do want to keep it to encourage best practices. We can remove the "failure to play" part to make the warning less misleading though. The new text would be: "It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior." Please let me know what you think. If there's no objections I'll implement this soon (before the M62 branch cut).
,
Aug 29 2017
Sounds like an improvement to me. Thank you! If we continue to see confusion from developers, we can re-examine later.
,
Sep 1 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f44ad44a93ee4079f1fa110d15d686c5cd51c1eb commit f44ad44a93ee4079f1fa110d15d686c5cd51c1eb Author: Xiaohan Wang <xhwang@chromium.org> Date: Fri Sep 01 23:45:20 2017 media: Update warning message on empty robustness string As discussed offline, removing the "potentially including failure to play" part to avoid confusion. We should write and publish a doc explaining the details around this and provide the link to the doc in the warning message, which is covered by a TODO. BUG= 720013 TEST=String change only. No tests required. Change-Id: Ia99654405fe8a7c32e19b44678fcc8508e6dc60c Reviewed-on: https://chromium-review.googlesource.com/648429 Reviewed-by: David Dorwin <ddorwin@chromium.org> Commit-Queue: Xiaohan Wang <xhwang@chromium.org> Cr-Commit-Position: refs/heads/master@{#499341} [modify] https://crrev.com/f44ad44a93ee4079f1fa110d15d686c5cd51c1eb/third_party/WebKit/Source/modules/encryptedmedia/NavigatorRequestMediaKeySystemAccess.cpp
,
Nov 8 2017
Just saw the compromise text in Chrome 63 beta. Would it make sense to go ahead and close the issue?
,
Nov 8 2017
Sure. If you have more suggestions please let me know!
,
Nov 8 2017
Will do. Thanks for your help! |
||||
►
Sign in to add a comment |
||||
Comment 1 by yini...@chromium.org
, May 10 2017Owner: xhw...@chromium.org
Status: Assigned (was: Untriaged)