HTML Media Task Force Teleconference -- 17 Jun 2014

<trackbot> Date: 17 June 2014

<paulc> calling again

<annevk> Zakim: [IPCaller] is likely me

<scribe> Scribe: joesteele

Bug 25594 - The read-only attribute usableKeyIds cannot be variable length

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25594

paulc: I sent out the list of bugs which needed comments
... followed up when I got back from China but some did not have comments as yet
... for each one we will just look at the bug

ddorwin: I looked at the replies. This was one of the two proposals I had
... I am fine with that

paulc: Anne's comment is here

<paulc> See Anne's comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=25594#c6

joesteele: +1

paulc: any comments -- or will be assigned as described
... believe we can assign to the editors -- David

Bug 25966 - Use ArrayBufferView and ArrayBuffer instead of Uint8Array in APIs

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25966

paulc: one response from Jerry saying he sugesting we switch to ArrayBuffer

jdsmith: talking to other on Playready team -- they convert to byte format -- haven't closed on this yet

<annevk> The general problem here is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

<annevk> IDL needs a common thing for APIs accepting bytes

jdsmith: in other implementations that type is converted to byte -- this might cause a compatibility issue

ddorwin: I thought you could format this however you want even with ArrayBuffer
... then it only matters how you get it out in the browser

paulc: Anne pointed at the general bug

annevk: we want all the APIs to take a sequence of bytes to accept the same types of objects
... we have had inconsistencies
... EME only accepts uint8?

paulc: does this WebIDL bug have a recommendation?

annevk: still under discussion - no person driving IDL forward, or at least not enough time

adrianba: we tried in some other APIs absent of a single way of accepting a sequence of bytes, is to allow ArrayBuffer or ArrayBufferView to be provided
... then the browser just grabs the underlying sequence of bytes -- the backing store

<annevk> adrianba: you might want to comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

adrianba: in Trident you can pass either one and either should work. Might not make sense to put an array of doubles in the structure, but in the ened you will still get back what is stored
... I propose we accept both
... if you have an ArrayBuffer creating the ArrayBufferView is a pain

paulc: how to do this in the spec?

adrianba: as an overloaded method?

paulc: you are saying there is advantage to doing both

adrianba: yes

ddorwin: what about the needkey and initData?

adrianba: I think that should be an ArrayBuffer
... advatnage for a method accepting data in is that you can create whatever view you want of it, you can pass it around

ddorwin: I have enough for the bug -- assigning to Jerry

paulc: solution then

jdsmith: there are several arrays where these are used, should I convert them all?

ddorwin: I wrote down that methods should be both and event attributes should be ArrayBuffer
... probably includes Promises

Bug 25923 - isTypeSupported should be asynchronous

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923

paulc: no comments since June 1st
... originally Anne's comment

<scribe> ... no progress since last meeting

ddorwin: some developers said it was inconvenient but could adapt
... Jerry updated the other isTypeSupported bug -- I have not responded yet
... if we were to expose more capabilities as he mentions we would need it to be asynchronous

<ddorwin> other isTypeSupported bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873

annevk: this would let the EME subsystem be disconnected

ddorwin: this has been implemented might want to break that one out

<ddorwin> Specifically, what is proposed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873#c14

paulc: suspect it would be good to handle today
... summary - making this async makes sense for the reasons given

ddorwin: there are also some implementation difficulties -- have to see how that goes

paulc: any other comments?
... sounds like we have a proposal.
... Who is this assigned to?

ddorwin: not sure we want to make this until the other change is made (24873)

paulc: so make dependent?
... do you want to discuss the other right now then?

ddorwin: yes

Bug 24873 - Current isTypeSupported() definition does not provide sufficient information to applications

bug - https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873

<ddorwin> ^ Specifically: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873#c14

jdsmith: the part of the comment we have been working on is structuring the DOMString as a dictionary
... looked a bit into privacy -- might need a user prompt to retrieve some of this info
... there is 4K content that will require specific capabilities in the device to stream
... could try and fail, but would prefer to check up front prior to playback
... tried to list the ones I thought were needed
... 2nd thing I put was that the downside is that the dictionary could be closed and specific, e.g. might need specific HDCP type
... another idea came up for submitting the license to the CDM and see if playable

ddorwin: I did not reply because I had not thought through all the way yet
... think we should close this one and open a new capability detection bug

joesteele: I would be in favor of a solution that submits the license to the CDM for validation -- we have a similar mechanism today
... not clear whether this is a license from a server or embedded in the initData

jdsmith: there is a need for determining quickly whether the criteria for playback are met
... think they should be discussed on the same bug

paulc: thikn you should bring the comment from the older bug and add to the new bug
... then comment on it yourself
... David is we mark this bug as resolved fixed - should we make the previous bug dependent on this new bug?

ddorwin: yes

paulc: then Jerry can you make bug 25923 is depend on this new bug?

<adrianba> annevk, i added my comment to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369#c16

paulc: ok then we will create a new bug and add the dependencies as described and close bug 24873

Bug 25866 - needkey event name is misleading

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25866

<annevk> adrianba, thanks!

paulc: mark responded last Thursday -- David what is the status?

ddorwin: Mark has a proposal, was not wild about it, still looking for better names

paulc: encrypted and encryptedInitData, encryptedMedia are all possibles

<paulc> Alternatives include: "encrypted" and "encryptedinitdata" or "encryptedmedia"

<ddorwin> Other suggestions welcome!

--- crickets ---

paulc: any suggestions? distaste?

joesteele: I like "encryptedMedia"

paulc: shall we leave it open for now then?
... ok leave this for now
... if "needkey" is misleading -- we do not have a strong contender to replace as yet

Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515

ddorwin: Jerry implemented, I had some questions on corner cases
... thought we could use a Promise, proposed in comment #31

<paulc> See proposal in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c31

ddorwin: thought we could address this by ordering the Promises, but not happy with that either
... thinking there are problems with the event version and the Promise version, need something better
... please read the comment and respond

paulc: does the bug enumerate what you think the problems are?

ddorwin: Jerry implemented a solution in comment 27
... I reviewed and replied in comment 28
... Dominic updated the Promises guide and in comment 29 I suggested we use what he added
... in comment 31 I provide a proposal for how we could use the Promises as described
... in comment 31 the real problem comes down to resetting the Promise you want it to be resolved as it is checked
... then you want to return a new one. The application should know when to grab the new one
... the timing is confusing. How to you tell the application when to grab the new one?
... if it does not get it, it will always just be waiting for a new event/promise
... comment 32 was a proposed solution to the problem of resetting the Promise

paulc: Jerry/Adrian -- since David is questioning this implementation -- do you have solutions?

jdsmith: my take on comment 28 is that there are more ramifications to waitingForKey
... when we started the waiting event was very straightforward -- it gets a little more complicated when we extend it
... my bias is to resolve the complexity and make it work, was hoping for a less entangled solution

markw: I think I feel the same as Jerry, seems like the existing waiting event expressed the high level intention

<annevk> Why does setMediaKeys() not return an array of promises?

<annevk> One for each key?

markw: going to be the same whether waiting for media or waiting for a key at the high level

<annevk> (Or have a method that simply looks up one and returns a single promise.)

markw: the Promises stuff might overcomplicate this -- not clear how to marry together

ddorwin: about Promises being one-off - the link described using for state transition -- just more complicated
... the event solution is not perfectly straightforward either, with auto-resume and the key event stuff
... interacts with section 5.1
... recommend reading that

<Zakim> annevk, you wanted to ask if there's an overview of the requirements here

annevk: might be good to email public-script-coord with the requirements
... see what you get back in terms of API advice
... or copy the relevant people (from that group) on the bug

<paulc> See http://lists.w3.org/Archives/Public/public-script-coord/

annevk: I could help with that

<paulc> s/public-script-coords/public-script-coord/

paulc: any other comments?
... ok -- as David said. Need folks to look at the text for the event proposal and the various comments

EME Use cases Wiki

<paulc> See http://lists.w3.org/Archives/Public/public-html-media/2014May/0029.html

paulc: this was talked about in the F2F -- Joe has some changes to make
... what is the status there?

<paulc> Joe: I did some cleanup.

<paulc> ... I tried to reorganize the material based on David using a sub-page.

<paulc> ... I kept the EME uses separate from the question on how to load the CDM.

<paulc> ... I want to add an additional section beyond the five applications models which I think are currently supported.

<paulc> ... On the EME use cases pages there are three main bullets now and I will add a fourth for future application use models.

<paulc> See https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases

<paulc> ... Asking others to look at the five applications models he re-structured and get others input.

<paulc> ... Look at the Status and the Required fields and provide input on whether you agree.

<paulc> ... I want to work on the multiple licenses section. Expect changes to number 5.

BobLund: Model #3 says status Supported, required is not

joesteele: yes -- some CDMs may not support this model

<paulc> #3 refers to https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#3._Limited_Concurrent_Streams

BobLund: can other implementors comment?

paulc: can folks add their comments to the wiki?

ddorwin: the bugs link - should we remove if there are not any?

joesteele: these should be information bugs -- not the ones that are outstanding
... still need work there
... I am happy to put the Adobe support for each of these models in the wiki, but did not want to call out any specific CDMs as being less compliant

paulc: Thanks for all the suggestions and work this week David!

ddorwin: will not be here next week

paulc: OK -- maybe MSE will be back on the agenda next week then
... will send out to Aaron as well to make sure he is aware
... bye all!

- DRAFT -

HTML Media Task Force Teleconference

17 Jun 2014

Attendees

Contents