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

{minutes} HTML WG media telecom 2014-08-12 EME status and bugs

From: Joe Steele <steele@adobe.com>
Date: Tue, 12 Aug 2014 16:14:40 +0000
To: "<public-html-media@w3.org>" <public-html-media@w3.org>
Message-ID: <71A1642C-E8C2-4CAA-9FB9-3D987A44DAF3@adobe.com>

Joe Steele

HTML Media Task Force Teleconference

12 Aug 2014


See also: IRC log


jdsmith, markw, +1.714.928.aaaa, joesteele, davide, Niels_Thorwirth, glenn, +1.425.936.aabb, adrianba, paulc, ddorwin, [IPcaller], heff_
joesteele, joesteele_

EME status and bugs
EME bugs with proposal
Bug 25866 - "needkey" event name is misleading
Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available
Bug 20336 - Revert addition of keySystem attribute to HTMLSourceElement
Bug 26372
EME bugs awaiting input from Task Force or actions
Bug 25268 - Reduce the burden on applications to deduplicate initData from many needkey events
[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)
[Bug 26401] Key message destinationURL usage is not reflected in examples
Bug 26207 - Provide a way to check system capabilities required for UHD playback
Do we need LoadSession?
EME Use cases wiki
Timing, Scribe, Chair for next meeting
Summary of Action Items
<trackbot> Date: 12 August 2014
<joesteele> Scribe: joesteele
<scribe> Chair: markw
<scribe> Chair: adrianba
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 12 August 2014
<scribe> Chair: paulc

paulc: bad today
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0005.html
EME status and bugs

EME bugs with proposal

Bug 25866 - "needkey" event name is misleading

<heff_> hey, 714 is me. Steve from Brightcove/Video.js
paulc: here is the proposal
ddorwin: was talking to some team members to this -- anything really accurate is too long and wordy. This seems short and reasonable
<adrianba> +1
joesteele: +1
paulc: any objections?
... make it so David
ddorwin: ok
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
paulc: Jerry expressed some concern that the solution in the bug had not resovled some race conditions
<paulc> Race conditions concerns: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c31
jdsmith: was not a concern -- just was raised
paulc: are there outstanding issues to resolve?
<paulc> Comments since last meeting: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c40
paulc: some comments since last mtg
ddorwin: that is my comment to Jerry -- if he agrees lets move forward
jdsmith: have not looked yet
... leave for editors and assume will be resolved
Bug 20336 - Revert addition of keySystem attribute to HTMLSourceElement

<joesteele_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20336#c8
<joesteele_> Scribe: joesteele_
paulc: any resolution needed by task force?
<paulc> David's proposal: I plan to submit a changeset that removes HTMLSourceElement (rather than spending time converting it).
paulc: proposing remove rather than convert correct?
<adrianba> +1
<paulc> Related to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23828#c4
ddorwin: Jerry and I discussed, p3828 if no objection will make removal permanent
... don't think can support with the way isTypeSupported is today
jdsmith: I agree
paulc: any objections?
... presume resolved
Bug 26372

paulc: skipped last week because David was not here
<paulc> See David's previous changes: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c2
paulc: you provided a changeset with this comment
ddorwin: I closed the old bug and opened this one
<paulc> See Joe's feedback: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c3
ddorwin: listed some of the scenarios that are not covered by Promises
... still a question about how to return them -- error attribute does not seem to make sense
... looking for input from the group, both on errors and how to report
<paulc> See Joe's question: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c4
paulc: do you have an answer to comment#4?
ddorwin: loading would be a Promise rejected with DOMException - general problem of how to report system codes in this case
paulc: is there a separate bug for this?
ddorwin: no we closed the earlier bug, Jerry is going to think about how to do system codes
<paulc> Previous bug was https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798 related to this.
paulc: old bug was 21798
jdsmith: we still have interest in a system code, but still looking for a way to add back into the spec
... in the discussion I mentioned putting systemCode as an attribute on the exception but that was viewed as unacceptable
<ddorwin> subclassing DOMException bug where systemCode was discussed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896
jdsmith: do others have opinions?
... we think they are useful for debugging errors in actual use -- need to retain somehow
paul: any alternatives?
<markw> My comment is just that it is essential for us to expose the system code in failure cases
jdsmith: only one I floated was attaching the value to the MediaKeySession - but only captures last error encountered
paulc: was that discussed?
jdsmith: we had a derivative that returned as a sub-class of DOMException but that is gone now
... DOMException has no provision for this -- only named values
... I will open a new bug and make a proposal
EME bugs awaiting input from Task Force or actions

Bug 25268 - Reduce the burden on applications to deduplicate initData from many needkey events

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268#c6
paulc: David has a proposal in comment #6 reverted earlier change and has been that way since July 11th
ddorwin: waiting for a bright idea here -- has been no good proposal yet
paulc: can someone volunteer to take a look
... propose a new solution?
glenn: this is on dedup of initData?
... is this considered an optimization? would it impact functionality if not addressed?
ddorwin: correct -- its an optimization
glenn: this could be delayed to a later version if needed
ddorwin: correct - does not block the standards progress
paulc: wish there was a status for this
... leave this on the list for now
... Glenn please add your comment to the bug
[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332
paulc: seemed to be a consensus at last meeting to use RFC SHOULD
<paulc> At the Jul 22 meeting we agreed that recommending that HTTPS SHOULD be used was a possible consensus position. Jerry offered to add a comment to the bug.
paulc: not a requirement
... since you were not there -- put back on the queue
markw: ... don't recall that concensus, don't think this is specific to EME, this is general to all web apps
... should not be just for our spec
jdsmith: don't know about concensus, but we did make that statement
... not sure we've all agreed that's appropriate
<paulc> Jul 22 minutes: http://www.w3.org/2014/07/22-html-media-minutes.html#item07
ddorwin: this was not last mtg
<paulc> Jul 29 minutes reference: http://www.w3.org/2014/07/29-html-media-minutes.html#item10
paulc: so Mark you are not convinced this should be a statement?
markw: yes I don't think this should be a normative statement
<paulc> See Jerry's comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c18 and Mark's reply https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c19
markw: think people were concerned about identifiers, we have some text about that already. HTTPS might be one of the mitigations but should not go so far as normative language
ddorwin: this is pretty much what we know, the difference is that this exposes a permanent or semi-permanent identifier. Will continue to be discussion in and out of bug
paulc: this is the only bug that shows up on social media streams, personal issue maybe even public policy issue
... but not sure how to resolve it
... reluctant to leave it open so we can make progress
... what will change folks opinion here?
ddorwin: this bug has only been open a month, think its fine to leave it open a while
paulc: If we can't get concensus by end of August let's revisit
glenn: Cox would like to oppose making that change. Think it's an application/policy issue
[Bug 26401] Key message destinationURL usage is not reflected in examples

joesteele: I have not updated the bug as yet
... will follow up on this this week
Bug 26207 - Provide a way to check system capabilities required for UHD playback

paulc: Jerry was going to provide more data
jdsmith: don't remember the extra data, but there has been a lot of discussion
<paulc> See http://www.w3.org/2014/07/29-html-media-minutes.html#item12
<paulc> From the minutes: "jdsmith: yes that is on our list, we considered testing a small piece of content. Will have more data next week"
jdsmith: think it is unnatural to require apps to remember the session
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26207#c5
jdsmith: for earlier comment I had skipped ahead --
... I have added a comment and would like to resolve that bug (26207)
... concensus that addressing the broader set of capabilities is outside scope of EME
... that leaves pre-testing for certain conditions, but don't have the information yet
... should not leave bug open while we wait for results there, if something changes we can re-open
<scribe> ... closed it this morning
paulc: any objections to this?
jdmith: as RESOLVED FIXED, but no changes
paulc: WORKSFORME sounds good
... add a comment as to exactly why this is being resolved that way
Do we need LoadSession?

paulc: best summary statement
... Joe is asking for feedback, gave some himself
... how should we proceed?
<paulc> joesteele: Looking for Jerry's feedback and feedback from other providers
<paulc> ... Maybe I am wrong but it does not work well for my situation
<paulc> ... I feel this is overkill for the situation
jdsmith: there may be a need in this area to allow for different CDM behavior, know that is not popular
... right now loadSession is optional, might not be a value-add for Playready, trying to model this
... feel like it is more natural for persistent licenses to be re-used automatically
... that does not seem like a good fit
ddorwin: from Jerry and Joe would like the use cases or app models where persistent licenses are used
... not clear why persistent licenses are used in all cases
... would like to know the different models
... people have said they would like to re-use on createSession -- would like that to be more concrete
joesteele: will provide the links to my earlier comments on this
ddorwin: documentation would be good
EME Use cases wiki

<paulc> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases
<paulc> - joesteele: the Key Release section will change still
joesteele: The Key Release section has not changed because it is dependant on the loadSession discussion
<paulc> - paulc: maybe send an email making the connection between the bugs and the use cases to draw interest from the group
paulc: we also discussed linking the bugs back to the use cases
joesteele: that has not been done yet either
<paulc> Notes from Joe and Paul are from Jul 29 minutes: http://www.w3.org/2014/07/29-html-media-minutes.html#item14
paulc: so those items are pending
Timing, Scribe, Chair for next meeting

paulc: two outstanding MSE bugs -- asked editors for feedback
... would like to put test suite on the next agenda
... then follow with EME status
... still waiting for information from poll on the test suite, need information for CR
ddorwin: FYI -- I will fix a few bugs we discussed today and then start the move to ReSpec
... spec may look ugly for awhile
paulc: before or after heartbeat?
ddorwin: after
paulc: sent a note that suggested we update the latest page as it is getting stale
... David will do this first. Couple of bugs pending this reorg right?
ddorwin: yes

   paulc: any other business?
paulc: thanks!
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-08-12 16:10:43 $

Received on Tuesday, 12 August 2014 16:15:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:53 UTC