- 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