HTML Media Task Force Teleconference -- 18 Sep 2012

<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> 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> 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> 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> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673 is assigned to John Simmons. No progress at this time

<adrianba> ACTION-3?

<trackbot> ACTION-3 -- John Simmons to propose resolution to bug 17682 -- due 2012-09-11 -- OPEN

<trackbot> 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> 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> 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> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17672

… defines how WebM is encrypted

<adrianba> 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> 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> 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> 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> 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: http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0012.html

<adrianba> 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> 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

- DRAFT -

HTML Media Task Force Teleconference

18 Sep 2012

Attendees

Contents