- From: Mark Watson <watsonm@netflix.com>
- Date: Tue, 16 Apr 2013 08:40:26 -0700
- To: Florian Bösch <pyalot@gmail.com>
- Cc: Paul Cotton <Paul.Cotton@microsoft.com>, "Mays, David" <David_Mays@comcast.com>, David Dorwin <ddorwin@google.com>, "<public-html-media@w3.org>" <public-html-media@w3.org>, "Philippe Le Hegaret (plh@w3.org)" <plh@w3.org>, "Michael(tm) Smith (mike@w3.org)" <mike@w3.org>
- Message-ID: <CAEnTvdBgW36DnzaL=S-7O5yf_462SVH4bKHSTpw9E9iWHt5FKw@mail.gmail.com>
On Tue, Apr 16, 2013 at 8:28 AM, Florian Bösch <pyalot@gmail.com> wrote: > It is necessary to implement Widevine if one wants to deliver content > DRMed to Chromebooks. > The server side yes, but the server side is not the subject of this specification. It's necessary to implement a Silverlight compiler to deliver content to Silverlight, or an H.264 encoded to deliver content to a device that only supports H.264, but these things do not mean that <object> or <video> are not in scope of the HTML charter. > If any other DRM is available on chromebooks, that would be independently > implementable, please feel free to point me to a specification. > How is the current capabilities of a single device relevant to the status of the specification ? > > I do disagree that the HTML-DRM as is practised, is in the spirit of the > HTML-WG charter. Theories of its functioning may differ, the reality does > not. HTML-DRM in its entirety cannot be independently implemented by me at > this time, because no unencumbered specification for a necessary component > to use it has been produced. I have asked for this specification, to no > avail. > You are more than welcome to propose a DRM solution that is available Royalty-Free. Indeed, such a thing would be very welcome. I don't know of one. If I did I would certainly propose it. You can certainly implement EME in a fully RF Open Source way - it just might not meet the requirements of all content providers. Similarly, you can implement WebGL fully in software, but it won't meet the requirements of all content - for that you need proprietary hardware (for performance). > > That leaves me with no other conclusion that a refusal to provide the > specification in practise means the HTML-WGs charter is no longer observed. > > > On Tue, Apr 16, 2013 at 5:00 PM, Mark Watson <watsonm@netflix.com> wrote: > >> Just for the record (because, Florian, I believe you know this), it is >> not necessary to implement Widevine in order to implement the EME >> specification (any more than it is necessary to implement Silverlight in >> order to implement the <object> element in HTML or H.264 in order to >> implement <video>). >> >> We can discuss the interoperability implications of this approach (and >> indeed we are), but the approach itself has clear precedent in the web >> platform. >> >> ...Mark >> >> >> >> >> >> On Tue, Apr 16, 2013 at 7:08 AM, Florian Bösch <pyalot@gmail.com> wrote: >> >>> It is noted that The HTML-WG co chair has stated that for a >>> specification published by the HTML-WG there is no path for implementation >>> neither for content authors nor for consumers of the content that complies >>> with the principles of the HTML-WG of providing unencombered access to the >>> technologies. Thank you for the clarification that the HTML-WG has given up >>> on its charter. >>> >>> >>> On Tue, Apr 16, 2013 at 3:28 PM, Paul Cotton <Paul.Cotton@microsoft.com>wrote: >>> >>>> As HTML WG co-chair I want to reinforce the point that asking for >>>> product specification documentation on a W3C email list is not >>>> appropriate. **** >>>> >>>> ** ** >>>> >>>> You have told this before, so please desist in making this kind of >>>> request.**** >>>> >>>> ** ** >>>> >>>> /paulc**** >>>> >>>> ** ** >>>> >>>> Paul Cotton, Microsoft Canada**** >>>> >>>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3**** >>>> >>>> Tel: (425) 705-9596 Fax: (425) 936-7329**** >>>> >>>> ** ** >>>> >>>> *From:* Mays, David [mailto:David_Mays@Comcast.com] >>>> *Sent:* Tuesday, April 16, 2013 9:03 AM >>>> *To:* Florian Bösch; David Dorwin; <public-html-media@w3.org> >>>> *Cc:* Paul Cotton >>>> >>>> *Subject:* Re: Chromebook DRM specification**** >>>> >>>> ** ** >>>> >>>> This is not an appropriate venue for this request.**** >>>> >>>> ** ** >>>> >>>> If you want Widevine documentation, I suggest you reach out to Widevine >>>> directly, as David Dorwin already told you, the day after you asked your >>>> question.**** >>>> >>>> ** ** >>>> >>>> The W3C does not have Widevine documentation.**** >>>> >>>> ** ** >>>> >>>> David Mays | sr. software architect | 15.217 | one comcast center | >>>> philadelphia, pa. 19103 | 215.286.3395 w | 267.307.4195 m**** >>>> >>>> >>>> _____________________________________________________________________________________________________________________________ >>>> **** >>>> >>>> ** ** >>>> >>>> *From: *Florian Bösch <pyalot@gmail.com> >>>> *Date: *Tuesday, April 16, 2013 1:01 AM >>>> *To: *David Dorwin <ddorwin@google.com>, "<public-html-media@w3.org>" < >>>> public-html-media@w3.org> >>>> *Cc: *Paul Cotton <Paul.Cotton@microsoft.com> >>>> *Subject: *Re: Chromebook DRM specification >>>> *Resent-From: *<public-html-media@w3.org> >>>> *Resent-Date: *Tuesday, April 16, 2013 1:01 AM**** >>>> >>>> ** ** >>>> >>>> It has now been a month since my request for documentation/software on >>>> how to encode video for chromebooks compatible with chromebooks DRM. None >>>> has been produced.**** >>>> >>>> ** ** >>>> >>>> On Tue, Mar 19, 2013 at 7:11 PM, Florian Bösch <pyalot@gmail.com> >>>> wrote:**** >>>> >>>> Widevines proprietary DRM solution is suggested to achieve DRMed video >>>> hosting. Widevine is not offering libraries/documentation to the public to >>>> use. This will not keep most people from using flash/silverlight to >>>> implement their own solution. I do not see any improvement by this over the >>>> status quo. EME proponents are still without an answer and a resolution to >>>> this simple question: How do I encode and host DRMed content. **** >>>> >>>> ** ** >>>> >>>> This issue is not addressed.**** >>>> >>>> ** ** >>>> >>>> On Tue, Mar 19, 2013 at 6:42 PM, David Dorwin <ddorwin@google.com> >>>> wrote:**** >>>> >>>> I addressed this issue in >>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20967#c11, which you >>>> replied to. Container and encryption details can be found at >>>> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#containers, >>>> and there are no special hosting requirements. You can try it out with the >>>> Clear Key ("webkit-org.w3.clearkey"), which is available on Chrome and >>>> Chrome OS. If you are interested in providing licenses to the Widevine CDM, >>>> I suggest contacting Widevine: http://www.widevine.com/contact.html.*** >>>> * >>>> >>>> ** ** >>>> >>>> On Mon, Mar 18, 2013 at 11:52 AM, Florian Bösch <pyalot@gmail.com> >>>> wrote:**** >>>> >>>> As a reminder, no answer has been provided how I could encode and host >>>> DRMed video for the Netflix/Google Chromebook DRM since a week now.**** >>>> >>>> ** ** >>>> >>>> On Tue, Mar 12, 2013 at 7:15 PM, Paul Cotton <Paul.Cotton@microsoft.com> >>>> wrote:**** >>>> >>>> I expect that David can answer your questions about Google’s >>>> implementation.**** >>>> >>>> **** >>>> >>>> Paul Cotton, Microsoft Canada**** >>>> >>>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3**** >>>> >>>> Tel: (425) 705-9596 Fax: (425) 936-7329**** >>>> >>>> **** >>>> >>>> *From:* Florian Bösch [mailto:pyalot@gmail.com] >>>> *Sent:* Monday, March 11, 2013 7:44 PM >>>> *To:* <public-html-media@w3.org> >>>> *Subject:* Chromebook DRM specification**** >>>> >>>> **** >>>> >>>> Apparently Google Chromebook now supports "HTML DRM" and Netflix has >>>> started serving content that way (source: >>>> http://news.slashdot.org/story/13/03/11/2155219/netflix-using-html5-video-for-arm-chromebook >>>> )**** >>>> >>>> **** >>>> >>>> Could anybody point out the specification and required libraries that'd >>>> allow me (or anybody) to encode/host their videos compatible with >>>> chromebooks html DRM implementation?**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>> >>> >> >
Received on Tuesday, 16 April 2013 15:40:55 UTC