- From: <bugzilla@jessica.w3.org>
- Date: Tue, 16 Jul 2013 15:58:08 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21869 Mark Watson <watsonm@netflix.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |watsonm@netflix.com --- Comment #9 from Mark Watson <watsonm@netflix.com> --- (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > (In reply to comment #2) > > > > Retaining some keys allow for better performance and usability. Every key > > > > acquisition has a cost, both to the user (representing either user time > > > > spent or delay to first playback) > > > > > > Isn't this best solved by letting the video start with a few seconds of > > > unencrypted content even though the keys are declared up front so that > > > playback can start during the key acquisition. > > > > [steele] This would be a good solution for the initial startup delay. > > However this is not in compliance with long term business agreements some > > content publishers have for how their content is protected for distribution. > > In practice I have found most publishers cannot use this technique > > currently. > > It's pretty sad that content licensors are *so* user-hostile. As if it > mattered if opening credits have DRM or not of the rest of the title does. > :-( It's probably not so much that the licensors are user-hostile but that this use-case was not considered when contracts were written and happens to be prohibited by the contracts. Re-writing contracts is difficult because there are so many of them, they are very long and complex and every time you re-open them people bring in other new issues. So, whilst this technique might be applicable in some cases the specification design shouldn't rely on it being universally available. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 16 July 2013 15:58:10 UTC