- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 24 Feb 2012 02:06:45 +0900
- To: public-web-and-tv@w3.org
available at:
http://www.w3.org/2012/02/23-webtv-minutes.html
also as text below.
Thanks a lot for taking these minutes, Joe!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Media Pipeline Task Force Teleconference
23 Feb 2012
[2]Agenda
[2]
http://www.w3.org/2011/webtv/wiki/MPTF/Agenda_Telco_23rd_February_2012
See also: [3]IRC log
[3] http://www.w3.org/2012/02/23-webtv-irc
Attendees
Present
Kaz_Ashimura, Clarke_Stevens, Joe_Steele, Bob_Lund,
Jason_Lewis, Kilroy_Hughes, Adrian_Bateman, Mark_Vickers,
Glenn_Adams, Russell_Berkoff, Philipp_Hoschka, Duncan_Rowden,
Mark_Watson, Paul_Gausman, Jan_Lindquist, John_Simmons_(IRC)
Regrets
Chair
Clarke
Scribe
joesteele
Contents
* [4]Topics
1. [5]discussion of new Content Protection Proposal (Netflix,
Google, Microsoft)
* [6]Summary of Action Items
_________________________________________________________
discussion of new Content Protection Proposal (Netflix, Google,
Microsoft)
discussing the proposal from Microsoft, Google and Netflix
Mark: please walk us through the proposal
-- wait until I am in front of my computer
clark: Adrian -- how about you
having some feedback
clark: have been anticipating this proposal -- submitted to HTML
group and our group for our perspective
... any comments on this proposal?
ph: since this was submitted to HTML group -- this is intended for
HTML5
kilroy: yes to make it available to HTML -- but not part of the
monolithic document
... could be a parallel document
MarkW: could be published as a separate spec -- kind of an extension
... what do we do with features that don't make the HTML5 cut?
... not resolved where this would go yet
<Clarke> Actual proposal:
[7]http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/enc
rypted-media.html
[7]
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
ph: not clear when HTML5 would repsond -- just wanted to double
check on the planning
<inserted> (HTML issue-179)
MarkW: this was meant to respond to this issue: (what issue#?)
<ph> markw: was submitted on this specific issue since content
protection was mentioned in this issue - but expect longer
discussion, not
glenn: this is an orthogonal proposal not related to 179 except for
parameter expression
MarkW: should I give an overview?
<mark>
[8]http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/enc
rypted-media.html
[8]
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
based in part on the Netflix proposal -- incorporates work others
were also doing -- not complete
hopefully there will be some discussion
-- giving an overview of the doc now
MarkW: application is in charge of passing the authentication to the
backend
... user agent is just passing the data through
... clearKey is basic encryption
... not part of the proposal how the CDM gets embedded or whether it
is software or hardware
... could also include coding and/or rendering of the media
... represents the secure media pipeline on the device
MarkW: not returning the decrypted frame to the browser
... the rest is the details of key exchange
-- discussion of the key exchange
MarkW: the keymessage is sent to the license server and received
back to hand to the CDM
... may be multiple key exchanges
... also an extension to the canPlayType()
clarke: concern I have seen raised -- belief that the frames would
be available unencrypted
MarkW: the diagram is a little misleading here -- looks like it
comes back to the browser but is dependent on the CDM
... you can imagine a system where it would come back but the frames
would not be well protected then
... a CDM like that would be useful for some content -- not all
... some content would not fall into this category - where decoder
is tied closer to the CDM
... decrypted frames do not come back to the user agent there
... that is an unsolved problem right now
... if decrypted frames are not coming back -- overlay would be the
simplest implementation
... would prefer if frames could be properly composited
... would need for user agent to be able to talk to the graphics
hardware to do the compositing properly
... can imagine this never happening for strongly protected content
Jason: is this akin to the hardware accellerated video tag?
mav: some questions about comparisons with the previous proposal
... previous proposal has been removed -- that is not good
... would like to see it put back
MarkW: should be able to see it in the history
mav: should have a label to make it more accessible
... the keys did not pass thru JS in the old proposal, now they do?
MarkW: in both proposals the messages pass through JS
... perhaps the name is wrong - is not necessarily a "key"
... for clearKey the message is actually a key
mav: would suggest that this should be further clarified
<adrianba> here is the old proposal:
[9]http://www.w3.org/2011/webtv/wiki/index.php?title=MPTF/Netflix_Co
ntent_Protection&oldid=1870
[9]
http://www.w3.org/2011/webtv/wiki/index.php?title=MPTF/Netflix_Content_Protection&oldid=1870
mav: description of the hardware support is brought in would be good
with diagrams
joesteele says +1
jasonlewis: is the clearkey meant to be like HLS?
MarkW: is it akin to that in that the message is just the key
... how key is applied depends on the container format
... different from HLS in that the user agent is sending the request
in HLS - with clearKey it is the JS application sending the request
joesteele: sending control messages to the CDM?
MarkW: not in this proposal except for key release in section 4
... the main reason for not having generic messages, it does not
describe how the system works
... should be possible to have a JS app which just knows the message
passing bit
... some preference has been expressed for exposing more features
... key release facilitates managing the key life cycle
... you may need to know how may keys are extant, or charge for the
content on a rental basis
... could be managed from the JS app layer, but could be gamed by
modifying the JS
... key release mechanism allows for a secure mechanism for managing
the keys
... this is outside the purview of the HTML media element
joesteele: what about birth of life?
MarkW: could call the generateKeyReq early on to help this
... it is assumed that the CDM needs some data about the media to be
initialized
... possible you could do this
joesteele: will send these notes to the HTML list
Clarke: procedural note -- how should we best handle comments like
this?
MarkW: since it was proposed to that group -- send comments to that
group
Clarke: : maybe we could come to agreement in this group and submit
one set of comments
MarkW: this should get included in the formal system
Clarke: encourage people to participate in the HTML WG as well on
this
glenn: note that the proposal was in response to ISSUE-179 -- not
clear that it is proposed as an extension to HTML5
... not clear we are chartered to propose specs yet
... how is this work being done?
MarkW: proposal is submitted to the HTML WG
Clarke: we are chartered to provide comments
<adrianba> the html wg made a call for html.next proposals - this
was discussed at TPAC too
<adrianba> right now we've simply submitted an informal proposal
document for discussion
glenn: not following procedure currently - who did this come from?
<adrianba> i hope that this will be adopted as an editor's draft in
the group
MarkW: came in as a proposal from Google
glenn: not clear as a reader of the proposal
MarkW: some behind the scenes coordination going on
glenn: does this IG need to bless this proposal or provide input?
mav: do not need to bless but should provide input
+1
kaz: thought we had our own ISSUE-40 for this?
... should this IG continue discussion on ISSUE-40 and bring the
conclusion to HTML WG?
... or should we discuss ISSUE-179 and bring that discussion to HTML
WG?
Clarke: should address, likely to be other issues we do not directly
raise with HTML WG
... we have an opportunity to provide feedback
kaz: clarifying our scope would be fine
glenn: I am possibly ok with that -- a little concerned still with
connection between ISSUE-179 and this proposal
... some confusion in the WG still
... led people to believe that 179 is concerned with content
protection and it is not
kaz: if you have a concern with 179 it should be raised in the HTML
WG -- we should focus on 40
-- agreement
glenn: expected actions from us on this proposal?
Clarke: we hope so - asked Mark to present to this group
thanks
<adrianba> HTML WG chairs review of ISSUE-179 is here:
[10]http://lists.w3.org/Archives/Public/public-html/2012Feb/0298.htm
l
[10] http://lists.w3.org/Archives/Public/public-html/2012Feb/0298.html
jasonlewis: re: the issue in the draft spec -- how do we add our own
issues to this draft?
clarke: raise issues on the wiki - which may not match those in the
proposal
... if authors then want to bring back to the proposal -- that would
be great
s/athos/authors/
clarke: any other comments?
... closing the call
... add any issues to the wiki
... thanks everyone
<kaz_> [adjourned]
Summary of Action Items
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [11]scribe.perl version 1.136
([12]CVS log)
$Date: 2012/02/23 17:04:00 $
[11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[12] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 23 February 2012 17:07:49 UTC