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

http://www.w3.org/2014/09/09-html-media-minutes.html

Joe Steele





HTML Media Task Force Teleconference

09 Sep 2014

Agenda

See also: IRC log

Attendees

Present
markw, jdsmith, ddorwin, davide, paulc, BobLund, joesteele
Regrets
Chair
paulc
Scribe
joesteele
Contents

Topics
EME bugs resolved since last meeting
Bug 26738 - "ISO Common Encryption EME Stream Format and Initialization Data" should be extended for MPEG-2 TS CENC
Bug 26758 - Need a more robust way of preventing multiple MediaKeySession objects for persisted session data
EME bugs related to handling of URLs
Bug 25092 - Need a way to inform script that resolution restrictions are applied
Bug 26372 - Revisit the need for EME-specific DOMException names and the "error" attribute and event
Bug 26600 - Text is confused between persistent session vs persistent licenses
Bug 25923 - isTypeSupported should be asynchronous
Summary of Action Items
<trackbot> Date: 09 September 2014
trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 09 September 2014
trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 09 September 2014
<scribe> ScribeNick: paulc
EME bugs resolved since last meeting

Bug 26575 - Separate creation of the MediaKeySession from "message" event generation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26575
Bug 24322 - Reorganize spec by object
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24322
paulc: how many changes for 24322.
David: no content changes and conversion to Respec is next on list.
paulc: See 25506 for conversion to Respec
Bug 26678 - MediaKeySession.generateRequest() should not fail if callable is false
<ddorwin> Just a typo
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26678
That ends the three bugs that were resolved except for items noted below.
Bug 26738 - "ISO Common Encryption EME Stream Format and Initialization Data" should be extended for MPEG-2 TS CENC

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738
See lively discussion.
We need someone that has access to "ISO Common Encryption EME Stream Format and Initialization Data" [1]
<ddorwin> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738#c9
The initdata types are conflated the container parsing and we may have split those up.
David will file a separate bug for that which would change the registery.
Bob has access to the spec and will work with the Editors on getting proposed text for 26738
Bug 26758 - Need a more robust way of preventing multiple MediaKeySession objects for persisted session data

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26758
This bug has no solution yet but David proposes to move responsibility for preventing duplicate sessions to the CDM
We will leave 26758 for David to propose a concrete change and/or to make the change.
EME bugs related to handling of URLs

See Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Sep/0004.html
<joesteele> scribe: joesteele
<paulc> Cluster of related bugs: 26683, 26575, 25920, 26401
paulc: cluster of related 26683, 25920, 26401, 26575 are all related
... need some help figuring out where to attack the cluster
... David, I think you suggested 26683
<paulc> Discussion also relates the URL processing to the HTTPS bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
ddorwin: some were open for related reasons, 26401 is an effect
... would like to close the old bugs and file a new bug if we can
paulc: I am not the subject matter expert here, but I would like to resolve. This is also related to 26332 as part of the rationale
... David you said two things. You wanted to open a new bug and you wanted to close all except 26683.
ddorwin: if folks are not happy with that, then would rather have a new bug that states exactly what we want
paulc: you have a concrete proposal
<paulc> Core issue is one of two things a) we have a concept of CRM specific meta-data OR b) need for routing information like a URL
<paulc> Joe: I and Jerry are arguing for a) but David is arguing against that
markw: I agree with Joe - we could move this under one bug. The argument is about this routing information - should be enum or routing field
... there is a design for free-form information and folks will just prepend to the other information if we do not provide it
... think that there was confusion about where this information was extracted from - didn't realize we were removing the possibility to populate destinationURL
<ddorwin> If the federated case is the only use case, we should either think through how that works or add support when necessary.
s/realizerealize/
ddorwin: I think the federated use case will come with some metadata as well - don't want to add something that may never be used
paulc: do you think the current document handles either case today?
ddorwin: there is an assumption that this means urls in the PSSH - don't think that is desirable
... has been brought up as a reason for why to have the URL
... don't want to overallow -- be more explicit
... don't add stuff we may not need
joesteele: the PSSH solution was the compromise solution adopted by the DASH group -- before we move away should have a lot of discussion
... in my mind we are removing existing flexibility not adding a new feature if we do not support this
<ddorwin> This is a web API, so we have different constraints (and capabilities/assumptions) than DASH.
ddorwin: DASH is going after other use cases than the web so maybe this does not apply, DASH should not force us to do anything
paulc: can we ask the editors to close those bugs (possibly marking as dups of 26683)
... perhaps topic should be generalized or changed to reflect this
... David - would you mind handling that?
ddorwin: will do - will close some as they were
Bug 25092 - Need a way to inform script that resolution restrictions are applied

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092
paulc: this was an old bug with new comments just recently
... Joe - take a personal note to review
markw: I agree with David in that bug - it would be great to have a more more general solution
... someone on the browser side needs to coordinate on this for a more general solution
paulc: You are saying the CSS working group is not interested in the problem unless there is a proposed solution. Do you see this in their domain?
markw: there was not a statement of intent -- just lack of interest
paulc: can you add that message to the bug? from the CSS archive?
... browser vendors on the call should look at this as well
ddorwin: it was my proposal to make it more generic on MSE or HTML Media Element -- I was just providing feedback though
Bug 26372 - Revisit the need for EME-specific DOMException names and the "error" attribute and event

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372
<ddorwin> Current title is
<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372 - Report issues/events not related to a specific method call
paulc: looks like pretty active discussion
... Mark responded on the 26th. Mark, Joe David all active here.
... are there questions to resolve here?
joesteele: I thought there was general agreement we need to solve, I thought a specific event would be fine. Are you ok with that David?
<ddorwin> The latest discussion starts at https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c10
joesteele: I thought downscaling was an example of this message to send
ddorwin: is the key usable event already exists, seems like remaining events are tied to keys like this
... could return a list of all keys (not just usable) instead with associated statuses/codes
... please provide feedback
markw: question here was more general - we have exceptions that can be returned, but no way to return the detailed system code
... that still seems like an outstanding problem
ddorwin: that was not the intent of this bug although it was discussed - Jerry was going to file a bug on that
jdsmith: I thought this bug was the system code topic, appears to have been re-titled
... possible I need to add a new bug
ddorwin: the intent here was always to handle the non-promise errors
jdsmith: I think it would make sense to add the system code issue as a specific bug
paulc: so David, bug 26372 is dealing with the proposal in comment 10. Jerry will separate out the system code issue
joesteele: I think system codes would apply to the non-promise bugs as well
Bug 26600 - Text is confused between persistent session vs persistent licenses

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26600#c2
paulc: what is the status?
... not much discussion in last few weeks
<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26600#c4
ddorwin: I was planning to implement my proposal in comment 4
paulc: bug 26600 is in the hands of the editors then
Bug 25923 - isTypeSupported should be asynchronous

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c20
<paulc> See Jerry's https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c12
<paulc> See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923#c19
paulc: maybe we can start with Jerrys comment 19
jdsmith: Anne added a comment since that, that says that the key system must be asynchronous
paulc: where do we stand then?
jdsmith: we had requested a separate bug for CDM downloads so we could have a larger discussion
... Anne is focusing on isTypeSupported for an approval process. Because this is a user-conditional format and the user needs time to respond.
joesteele: this type of conditional access will drastically reduce usage we have seen
... off topic
ddorwin: have to figure out how to support this for browsers that choose to do it
jdsmith: I would still like to look at another way to get user authorization, might have to look at other use cases
... this is why we suggested a separate bug
ddorwin: isTypeSupported allows the application to decide about content downloading - blocking it might slow that down
jdsmith: is plan one time per use or one-time per origin?
ddorwin: we don't know
joesteele: have to assume the worst case
ddorwin: also don't know when prompting will happen, separate from when the download happens
jdsmith: seems like there is a flow where it returns "maybe" to allow downloading until ready for use. I woul dfavor that
paulc: Jerry - any other cases we should consider?
jdsmith: would like isTypeSupported to be synchronous and split the async portion into separate bug
ddorwin: other specs have places where they say -- is you are going to handle permissions - do it here. Maybe we should have that as well
paulc: is Anne the right Mozilla representative for this and the person to inform when the bug is created?
ddorwin: Boris has commented as well
paulc: we are out of time
rrsagent: generate minutes
paulc: the editors should continue to update us on changes and agenda items for next week
Summary of Action Items

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