- From: Joe Steele <steele@adobe.com>
- Date: Tue, 18 Sep 2012 09:39:14 -0700
- To: "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <89A16DFF-A94C-4910-BE9F-6771017495D7@adobe.com>
The minutes from today's teleconference are available in HTML here:
http://www.w3.org/2012/09/18-html-media-minutes.html
or in plain text below:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
HTML Media Task Force Teleconference
18 Sep 2012
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0015.html
See also: [3]IRC log
[3] http://www.w3.org/2012/09/18-html-media-irc
Attendees
Present
markw, Matt, Clarke, ddorwin, paulc, adrianba,
[Microsoft], +1.408.536.aaaa, joesteele, johnsim, pal,
+1.858.677.aabb
Regrets
Chair
SV_MEETING_CHAIR
Scribe
joesteele
Contents
* [4]Topics
1. [5]Agenda
2. [6]Minutes from Sept 4
3. [7]Review Action Items
4. [8]Baseline docs and Bugzilla info
5. [9]Actions from previous meeting
6. [10]Unresolved Bugs
7. [11]Other Bugs
* [12]Summary of Action Items
__________________________________________________________
<trackbot> Date: 18 September 2012
<whadar> hi
<adrianba> ScribeNick: joesteele
Agenda
Minutes from Sept 4
paulc: make sure we get the attendees correct
Review Action Items
paulc: on the agenda
Baseline docs and Bugzilla info
<paulc>
[13]http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med
ia/encrypted-media.html
[13] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
paulc: did click on the link -- did not look like it has been
worked on
ddorwin: added some update last night
paulc: encrypted media bugs have more open now
... regressed a bit?
joesteele: I reopened a few
<paulc> [14]http://tinyurl.com/7tfambo
[14] http://tinyurl.com/7tfambo
paulc: added those bugs to the agenda
Actions from previous meeting
paulc: any progress?
... Action 2?
<paulc> ACTION-2?
<trackbot> ACTION-2 -- Mark Watson to propose a resolution to
bug 17673 -- due 2012-08-17 -- CLOSED
<trackbot> [15]http://www.w3.org/html/wg/media/track/actions/2
[15] http://www.w3.org/html/wg/media/track/actions/2
johnsim: not at this time now
paulc: ETA?
johnsim: should have something this week
... spent some time on the common key question
<paulc>
[16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673 is
assigned to John Simmons. No progress at this time
[16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
<adrianba> ACTION-3?
<trackbot> ACTION-3 -- John Simmons to propose resolution to
bug 17682 -- due 2012-09-11 -- OPEN
<trackbot> [17]http://www.w3.org/html/wg/media/track/actions/3
[17] http://www.w3.org/html/wg/media/track/actions/3
paulc: last time we changed the due date for this to Sept 11
... john you mentioned you did some work
<paulc>
[18]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682
[18] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682
johnsim: did some research, adrian and I discussed this
yesterday
… there is some lack of clarity on how the key is used
… up till now discussed as a key acquiisition proposal
johnsim: but how do you use that key?
… assumption is by examination of the media
… ISO based format, Common Encryption Format, etc.
… would know intrinsically how to handle it
… problem with this approach is that if goal is to produce
interoperable solution between browsers
… common encryption modality without reference to DRM
… how do you assure that all the browsers understand the
different media types?
johnsim: need to understand the intent behind clearkey
… we can consider it good if it only handles key acquisition
scribe: but if goal is to create an interoperable solution, we
need to be normative about the encryption
… modes algorithms etc.
ddorwin: intent was the latter
... at the encryption level as well
… could call AddKey multiple times
… AES-128 CTR seems to be common, if there are containers that
do not specify that we need to deal with that
… WebM does not need to specify that? (please correct if I
mistated)
johnsim: if you don't know that it is encrypted it will just be
unrecognizable
ddorwin: container format specifies how it is encrypted
johnsim: container level encryption is not covered by this spec
then?
… i.e. HLS
… so the media stack can always determine the type of
encryption to be used
ddorwin: that was the intent -- have not thought deeply
adrianba: think this is slightly different than what john
summarized
… clearkey should work the same way for content encrypted at
the container format
… if possible for other DRMs
<adrianba> clear key should be as usable with media files as
with a DRM system
<adrianba> if the media format supports envelope encryption
(e.g. HLS) then this would also work with Clear Key
johnsim: if it is container level encryption - the CDM will not
be able to examine the container to determine how the
encryption was performed
... you could set up a mime-handler that knows how to handle it
... does not seem like this was envisioned to support container
level encryption
... does not seem practical to implement clearkey for container
level encryption
adrianba: I think as interoperable code you have to understand
how the format works in either case
… this is related to a later agenda item
… being able to start the key request without knowing the
content/media type
… think we need to understand the media type to be able to fire
up the approp. CDM
… need indicator of what is encrypted and how
… this will need to be defined normatively somewhere
paulc: high level comment -- sounds like this should be written
down in an email thread
… need a wider group to review it
ddorwin: it was intended to be clear that the container
specifies this stuff
... what john was talking about should be separate from
clearkey -- e.g. needKey event is independent fro a key system
… for any of these events we want to be commonly supported need
specification
<adrianba> ACTION-3 due in 1 week
<trackbot> ACTION-3 Propose resolution to bug 17682 due date
now in 1 week
paulc: moving on. need to extend ACTION-3
... ACITON-4
<adrianba> ACTION-4?
<trackbot> ACTION-4 -- David Dorwin to propose a solution for
bug 17672 -- due 2012-09-18 -- CLOSED
<trackbot> [19]http://www.w3.org/html/wg/media/track/actions/4
[19] http://www.w3.org/html/wg/media/track/actions/4
ddorwin: added a new section 7.1
… rest of the document is container independent
<paulc>
[20]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17672
[20] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17672
… defines how WebM is encrypted
<adrianba>
[21]http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med
ia/encrypted-media.html#webm
[21] http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#webm
paulc: is this what is needed?
ddorwin: yes, content is correct
paulc: marked as RESOLVED, FIXED
ACTION-5?
<trackbot> ACTION-5 -- Mark Watson to follow-up on Key Release
mail thread now that the OO changes have been made - discuss on
next call -- due 2012-08-28 -- CLOSED
<trackbot> [22]http://www.w3.org/html/wg/media/track/actions/5
[22] http://www.w3.org/html/wg/media/track/actions/5
paulc: have not checked whether this is done -- no record of
emails on it
... not sure what the status is -- was assigned to Mark?
... Mark can you update us?
markw: no followup yet, have some notes in the bug itself I
think
<ddorwin>
[23]http://lists.w3.org/Archives/Public/public-html-media/2012S
ep/0004.html
[23] http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0004.html
paulc: don't see an associated bug
markw: there is a bug for key release
<adrianba>
[24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
[24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
ddorwin: posted a link with a proposed solution, next step is
for Mark to add to the spec
<ddorwin>
[25]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
[25] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
paulc: Mark should either respond to the proposal or update the
spec
Unresolved Bugs
paulc: reopened bugs by Joe
<ddorwin> previous topic: last email on action 5:
[26]http://lists.w3.org/Archives/Public/public-html-media/2012S
ep/0012.html
[26] http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0012.html
<adrianba>
[27]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17470
[27] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17470
<paulc> "Provide specific guidance on when generateKeyRequest
should be called "
<adrianba> joesteele: the use case i'm thinking of is for the
access DRM there are certain keys i can preload ahead of time
<adrianba> ... there might be a substantial cost in requesting
the keys that would affect the user experience
<adrianba> ... i don't know what the media format is going to
be yet
<adrianba> ... i can make some guesses
<adrianba> ... in most cases i probably would know the media
type but in the general case i don't know the type
<adrianba> ... but i do know that a particular set of domain
keys will be needed
<adrianba> ... so i want to be able to do a key request without
having seen any media yet
<adrianba> ddorwin: i think you can create a MediaKeys object
without a media type
<adrianba> joesteele: it's not clear where the errors go
<adrianba> ddorwin: you can create a MediaKeys object and then
createSession to get a MediaKeySession object and events get
fired here
<adrianba> adrianba: is it not true that you need the media
file format to know the format of the initdata
<adrianba> ... for example in ISO BMFF we've assumed that
initdata is a concatenated list of pssh boxes
<adrianba> ddorwin: i don't think there is initdata in this
situation
<adrianba> joesteele: that brings up one of the issues, if you
create a session without initdata then an error is thrown
<adrianba> ... i'm okay if you have to say there is initdata we
can fake it up
<adrianba> ddorwin: the spec says you must have initdata and
mime type or neither?
<ddorwin> createSession() may be called with no parameters
<johnsim> +q
<adrianba> ddorwin: the algorithm says that if the type is null
and initdata is NOT null then it's an error - anything else is
allowed
joesteele: I would like to see an example in the spec of how to
initialize
paulc: can you provide the example for us?
joesteele: ye s-- I will do that
johnsim: the wording is ambiguous for step 1 of createSession
steps
paulc: maybe put (or an empty string) in parens
... suggest to joe to provide the sample
... editors can then decide how to handle
<adrianba>
[28]https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660
[28] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660
<adrianba> joesteele: this is a related issue
<adrianba> ... when i asked about authentication at the F2F
<adrianba> ... i was told it would done at the app level not in
the CDM
<adrianba> ... but in the Access case, authentication is bound
into th ekey request channel
<adrianba> ... and we have a lot of customers that use this
channel
<adrianba> ... we think it is more secure than TLS auth
<adrianba> ... but i don't see another way to pass additional
parameters down
<adrianba> ... without having to parse the key data coming back
<adrianba> ... which we want to avoid
<adrianba> ... in Access, you would understand that you need to
do a key request
<johnsim> +q
<adrianba> ... and you would get a flag from the DRM system
saying you need to get auth information
<adrianba> ... and you might prompt for username password and
then pass it down into the DRM system
<adrianba> ... and there doesn't seem to be a mechanism to pass
that in
<adrianba> joesteele: this is user authentication
<adrianba> johnsim: so user credentials associated with the
event
<adrianba> joesteele: example: i log in to a web site where my
queue of videos is but when i play a particular video it has
credentials from a different service and so now i have to
provide those to authenticate for it
paulc: start an email thread pointing back to this comment
… add more details to the question in the comment
paulc: discussing 17682
... this was discussed above under ACTION-3
Other Bugs
paulc: have a large number of bugs with no progress on them yet
-- work going on in the background?
... would like to know which items we can get done in next two
weeks
... if so -- can editors propose which ones
adrianba: a lot of them are related to error which is being
discussed
paulc: what about items we discussed today -- david any others?
ddorwin: some pending bugs to file ;-)
<whadar> Considering Media Source Extensions, I would like to
feedback as a user of the API. There are great benefits of
having a low-level API that can append bytes. But, the
implementation underneath should help the developer and even
defend the developer when setting up a stream and appending
bytes. Specifically 1) the browser level should help
understanding the type of CODEC and not require it on init. 2)
Appending should not necessarily begin at the beginning
paulc: will watch for those then
ddorwin: focusing on the implementation bugs
paulc: mark -- any to queue up?
markw: should be able to make progress on all of them in the
next two weeks
... assigned to 4
paulc: we might be stable in two weeks then, with David and
Mark's work
... nothing else on the agenda
... Oct 2 is next meeting
... should be able to do the next meeting
... any other comments?
... ready to adjourn
Summary of Action Items
[End of minutes]
Joe Steele
steele@adobe.com<mailto:steele@adobe.com>
Received on Tuesday, 18 September 2012 16:39:46 UTC