W3C home > Mailing lists > Public > public-html-media@w3.org > May 2014

{minutes} HTML WG media telecon 2014-05-13 - EME status and bug discussion

From: Joe Steele <steele@adobe.com>
Date: Tue, 13 May 2014 16:22:34 +0000
To: Paul Cotton <Paul.Cotton@microsoft.com>, "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <1DE28D50-9D9B-43AF-A139-1F2FD8D59092@adobe.com>
http://www.w3.org/2014/05/13-html-media-minutes.html

Joe Steele



HTML Media Task Force Teleconference

13 May 2014

Agenda

See also: IRC log

Attendees

Present
Niels_Thorwirth, paulc, pladd, markw, davide, +1.425.936.aaaa, ddorwin, pal, BobLund, +1.781.221.aabb, joesteele, [Microsoft]
Regrets
Chair
paulc
Scribe
joesteele
Contents

Topics
EME status and bugs
NEW EME bugs since the last meeting
New Bugs
bug 25594
bug 25269
Cluster of bugs - bug 17673, bug 17682, bug 24419, bug 24427
isTypeSupported Bugs
bug 25092, bug 25218, bug 24874, bug 24873
bug 25119, bug 21798, bug 24771
Use Cases/Application Models
Bug 25595
Other business
Summary of Action Items
<trackbot> Date: 13 May 2014
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014May/0025.html
EME status and bugs

http://tinyurl.com/7tfambo 21 bugs open
NEW EME bugs since the last meeting

Bug 25580 - Add Informative Reference to Byte Stream Format Registry in MSE editors draft.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25580
Bug 25581 - Establish a update process & home for byte stream format registry and byte stream specs.
This is a MSE bug
Both 25581 and 25580 are MSE bugs. sorry
<joesteele> scribe: joesteele
New Bugs

<paulc> Bug 25594 - The read-only attribute usableKeyIds cannot be variable length
bug 25594

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25594
ddorwin: re-read the IDL spec and it says this cannot be fixed length
... so we have two options I thought of
<ddorwin> Array<Uint8Array> getUsableKeyIds();
ddorwin: 1) define as a get method
... 2) define as a Promise satisfied with the array
<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=25594#c1
ddorwin: first one CDMs must provide even when apps don't want it, other would be asynchornous to go get them
... CDM will be doing something when the keys change
paulc: any comments?
... any preference?
ddorwin: CDM is already telling the UA about these events, looking for feedback on this
markw: run into race conditions with the promise?
ddorwin: promise would be the most up to date value
... could just ask again
... could also have a race condition with the event model
markw: wondering if it is guaranteed that the events will arrive at the app in the same order as the requests?
ddorwin: no even for the event
markw: not sure if they will be processed in the same order
paulc: do you have a preference Mark?
markw: not yet
bug 25269

<paulc> Bug 25269 - Add a container-independent initialization data type for providing a list of key IDs to createSession()
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269
paulc: got at least one response in the bug
ddorwin: discussion between joe and I was more related to why than how
<paulc> Three options identified by David: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25269#c15
paulc: this is the message with the 3 options
... asked folks to look at this -- anyone not prepared to discuss?
ddorwin: either 2 or 3
<paulc> #2 #2 Use a JSON definition and serialize it into a Uint8Array
<paulc> #3: Use a binary format
+q
ddorwin: think it matters more to the developers not the UA folks
joesteele: not convinced that this cannot be done on the sevrer side
... if we do this -- I would prefer #2
markw: why is option #1 not preferred?
<paulc> #1: Allow createSession() to accept a JavaScript object in addition to the Uint8Array option.
ddorwin: ideal from a developer perspective but would need to overload createSession
... this is extra implementation without the same flow as proprietary CDMs -- could do number #1 but seems unnecessary
markw: ok then I would prefer #2 as well
paulc: is that enough input to move forward?
ddorwin: yes
... editors will move forward
Cluster of bugs - bug 17673, bug 17682, bug 24419, bug 24427

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
<paulc> Review by Mark and Jerry: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c53
paulc: editors were going to review these bugs
... status?
jdsmith: circulated the doc -- accurate as far as it goes but might go further
... some language that could be added but has not been yet
... some discussion of key rotation
<paulc> Bug 17673 - Define Initialization Data for implementations that choose to support the ISO Base Media File Format
jdsmith: we added comments about PSSH in respond to the bug, these are related but clarifiying
ddorwin: any clarifications we should just make
... the leaf node, embedded node stuff we should discuss more
jdsmith: will probably make a couple of mods for the PSSH location
markw: comment in the bug
paulc: Jerry owns this bug, editors know what they want
... this ref'd bug 17682, bug 24419, bug 24427
<ddorwin> The first two will be JSON passed to/from the APIs via the Encoding API.
paulc: these are all pending actions by the editors -- that will close 4 more bugs
ddorwin: the 3rd one Mark has an action to formalize the proposal I think
<markw> I haven't done that yet
paulc: your notes said you will formalize -- have not done yet
isTypeSupported Bugs

paulc: something to discuss here?
bug 25092, bug 25218, bug 24874, bug 24873

paulc: another batch
<paulc> 25218 was Withdrawn and replaced by 25595
paulc: worth attacking today?
ddorwin: not at this time -- Jerry is looking at using capabilities
jdsmith: had a discussion and are converging on a proposal around contratins and isTypeSupported
... that is the direction we are heading
paulc: does that attack the broad set of bugs?
jdsmith: I believe so
... have to look at each one -- this is specifically about understanding capabilities
... more than the specific media types -- handles constraints of the device
paulc: when can you respond? next week?
jdsmith: expect a proposal by end of the week
paulc: if you can make it clear which are pertinent that would help
bug 25119, bug 21798, bug 24771

paulc: 24771 is pending implementation
<paulc> Bug 21798 - Revisit MediaKeyError codes
paulc: we have a long outstanding 21798 revisit error codes
ddorwin: have not looked at these in a while
... error codes are affected by other changes -- will put off for now
paulc: did I have 24771 right?
ddorwin: yes -- agreement on what it should be just need to describe
paulc: Jerry might want to think about impact on this bug for capabilities stuff
Use Cases/Application Models

Bug 25595

<paulc> Bug 25595 - Better definitions needed for session, keys and license
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25595
joesteele: this bug is to capture comments made in various other bugs about the lack of clarity of what is in a sessoin
... what is a license and what are keys
markw: think I agree with what Joe is saying -- we could more careful with our definitions
... session is a context for key exchange and we don't say anything else
... some DRMs call them licenses, some call then something else, don't need to define further
... don't think we need more semantics
ddorwin: thanks for providing the specific recommenedations
... the probblem may be with the aplication and the usage models
... Jerry mentioned leaf keys for example
... changing the spec text to allow undocumented behavior may lead to problems
+q
scribe: to help encourage interop we should define how these things work
... e.g. we can agree on how leaf nodes work
... in bug 20944 (text)
... this is the interop bug
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20944
<paulc> Wiki kmentioned by Joe: https://www.w3.org/wiki/HTML/Media_Task_Force
joesteele: my issue is really that some CDMs (like mine) bring these issues in for even the simplest case
... so I am not opposed to discussing the key hierarchy and other session-related issues but I don't think it is needed to get the simple use case supported
paulc: we still have 20 bugs -- eventually we will have to come to grips with this issue about future use cases versus todays use cases
... it seems like this is a tension that exists whether we will get interop between applications that do not know which CDM they are using
... we have to handle that at some point
... getting some discussion going in the wiki on the use cases -- that would be a step forward
... that was the new bug
... several other bugs in this cluster -- should we discuss bug 24082 or bug 25034
... last one looks like it was re-opened
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25434
ddorwin: we previously discussed out-of-band comm being out of scope for EME
... was re-opened as unacceptable
<Niels_verimatrix_> +q
ddorwin: no new info in the bug
niels: discussion was more about why it would not be allowed and why it was closed
... originally was that you do not need EME for out-of-band comm
... but you do need EME to signal that you want this comm
ddorwin: are you saying that you want isTypeSupported?
niels: yes -- CDM can signal that so it does not have to do key exchanges via the application
ddorwin: think it is ruled out by the spec, but you could do it. Would not be interoperable
niels: not something we need to address, change the abstract only
... as long as the key messages are optional
... then CDM can signal when it is ready to decrypt
ddorwin: I will post my use case description and that would explain how things would work in this case
... it would be usefull to know what your application would look like
niels: don't see things that would prevent this from executing
ddorwin: once we have the use cases we can have discussions about the model and about where we are restrictive
paulc: this is the tension I was mentioning
... maybe this will draw people to make comments in the wiki -- David and Niels maybe
... will be on the agenda for next week
Other business

paulc: This covered half of the bugs
... no other business to handle -- will pick this up next week
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-05-13 16:18:30 $



Received on Tuesday, 13 May 2014 16:23:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:03 UTC