W3C home > Mailing lists > Public > public-html-media@w3.org > January 2015

{minutes} HTML WG media telecon 2015-01-20 - EME status and bugs

From: Joe Steele <steele@adobe.com>
Date: Tue, 20 Jan 2015 17:01:45 +0000
To: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <5F12197A-8D9C-4E84-9DB9-16E1704E91E8@adobe.com>
http://www.w3.org/2015/01/20-html-media-minutes.html <http://www.w3.org/2015/01/20-html-media-minutes.html>

Joe Steele


 <http://www.w3.org/>
- DRAFT -

HTML Media Task Force Teleconference

20 Jan 2015

Agenda <http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0036.html>
See also: IRC log <http://www.w3.org/2015/01/20-html-media-irc>
Attendees <>
Present
paulc, joesteele, markw, ddorwin, jdsmith, BobLund
Regrets
Chair
paulc
Scribe
paulc, joesteele
Contents

Topics <http://www.w3.org/2015/01/20-html-media-minutes.html#agenda>
Bug 27738 - Need to change name of 'message' event to avoid confusion <http://www.w3.org/2015/01/20-html-media-minutes.html#item01>
Bug 27739 - Change event name 'keyschange' to 'keychange' <http://www.w3.org/2015/01/20-html-media-minutes.html#item02>
ISSUE-14 Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations <http://www.w3.org/2015/01/20-html-media-minutes.html#item04>
ISSUE-7 EME should not fire waiting or canplay events - use a separate mechanism <http://www.w3.org/2015/01/20-html-media-minutes.html#item05>
ISSUE-8 Define behavior for implementations that delay playback until setMediaKeys() is called <http://www.w3.org/2015/01/20-html-media-minutes.html#item06>
EME/MSE heartbeat publications <http://www.w3.org/2015/01/20-html-media-minutes.html#item07>
plans for next meeting <http://www.w3.org/2015/01/20-html-media-minutes.html#item08>
Naming Bugs <http://www.w3.org/2015/01/20-html-media-minutes.html#item09>
Bug 25092 - Need a way to inform script that resolution restrictions are applied <http://www.w3.org/2015/01/20-html-media-minutes.html#item10>
Bug 27124 - Add "individualizationrequest" to the MediaKeyMessageType enum <http://www.w3.org/2015/01/20-html-media-minutes.html#item11>
Bug 27283 - InvalidAccessError usage is questionable; use TypeError instead? <http://www.w3.org/2015/01/20-html-media-minutes.html#item12>
Summary of Action Items <http://www.w3.org/2015/01/20-html-media-minutes.html#ActionSummary>
<trackbot> Date: 20 January 2015
<paulc> waiting for quorum
<paulc> waiting for quorum
<paulc> scribe: paulc
Bug 27738 - Need to change name of 'message' event to avoid confusion

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738>
David: Anne's latest message says the name change is not needed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738#c5 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738#c5>
<markw> +1 to leaving the name as it is
Paul: Proposal on the table is to NOT change the name
... So far David and Mark support not changing the name
<joesteele> +1 to not changing
Jerry: I agree with no change
Paul: Any objections to closing bug 27738 was WONTFIX?
... No objections
<scribe> scribe: joesteele
Bug 27739 - Change event name 'keyschange' to 'keychange'

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738>
<scribe> Scribe: paulc
<joesteele_> scribe: joesteele
<joesteele_> ddorwin: that was the original proposal -- did some research on HTML5 media elements
<joesteele_> ... usually when we have change events it the attribute name
<joesteele_> ... example volume and queue
David: In general, the pattern appears to be "<attribute-name>change"
<joesteele_> ... given we have keystatuses -- keystatuseschange would be apporpriate
<ddorwin> keystatuseschange
<markw> are we going to change the attribute to KeyStatus, though ?
<joesteele_> ddorwin: no -- that was resolved in bug 27740
<markw> in another bug
<ddorwin> The pattern of "<attribute-name>change" would imply "keystatuseschange"
Bugzilla 27740: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27740 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27740>
<markw> ok, makes sense
<joesteele_> ok
<joesteele_> paulc: what is the change we will make?
<ddorwin> proposal: Change keyschange to keystatuseschange
<joesteele_> +1 to proposal
<ddorwin> (per comment 2 in the bug)
<joesteele_> paulc: seems to meet Glenns original concern
<joesteele_> ... anyone objecting?
<joesteele_> RESOLVED to fix as per the proposal
ISSUE-14 Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations

https://github.com/w3c/encrypted-media/issues/14 <https://github.com/w3c/encrypted-media/issues/14>
<joesteele_> ddorwin: bug was originally about having the async CDM algorithms firing events directly
Original bugs is: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27138 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27138>
<joesteele_> ... after thinking more, realized whether this was application visible is an issue
<joesteele_> ... when application is calling generateRequest it is not clear that the promise will be resolved before the message is received
<joesteele_> ... this might be problematic
<joesteele_> ... is there any guarantee to ordering?
<joesteele_> ... if not we have this problem that reslolving the promise at the end does not help at all except knowing you did not fail
<joesteele_> ... can we resolve this another way? or should we instruct apps to rely on the message?
<joesteele_> ddorwin: I meant resolve the problem
<joesteele_> ... one way is that the promise has the message
<joesteele_> ... not great implementation-wise
<joesteele_> ... might need to do something to make things better for apps here
<joesteele_> paulc: mark commented recently
joesteele: Any change will impact us and we are discussing it. Need more time.
... Chris is not on the call and it would be good to get his input.
... We are resolving the promise after receiving messages and I don't know if this is required or if it is just how I implemented it originally
<joesteele_> joesteele_: still waiting for input internally
<joesteele_> ddorwin: I wrote this the way they are assuming that the promises would be resolved first
<joesteele_> ... goal was that the promise would be resolve before the message is received
<joesteele_> ... but not sure whether we can easily guarantee either
<joesteele_> ... but important thing to do is make this reasonable for the apps
<joesteele_> first thing to guarantee is that the promise is resolved before the message handler
<joesteele_> ddorwin: joe please ping Mozilla folks
<joesteele_> paulc: no other comments, let's move on
ISSUE-7 EME should not fire waiting or canplay events - use a separate mechanism

<joesteele_> issue-7?
<trackbot> Sorry, but issue-7 does not exist.
https://github.com/w3c/encrypted-media/issues/7 <https://github.com/w3c/encrypted-media/issues/7>
<joesteele_> https://github.com/w3c/encrypted-media/issues/7 <https://github.com/w3c/encrypted-media/issues/7>
<joesteele_> paulc: this one is to finalize the agreement
<joesteele_> jdsmith: the bug proposed stripping out the attribute for waitingFor and canPlay waiting mechanisms
See Jerry's comment: https://github.com/w3c/encrypted-media/issues/7#issuecomment-70595972 <https://github.com/w3c/encrypted-media/issues/7#issuecomment-70595972>
<joesteele_> ... last week we agreed it was acceptable
<joesteele_> ... we use it in one algorithm
<joesteele_> ... don't think that is enough to keep it in the spec
Joe agreed with Jerry's proposal https://github.com/w3c/encrypted-media/issues/7#issuecomment-70663182 <https://github.com/w3c/encrypted-media/issues/7#issuecomment-70663182>
<joesteele_> ... CDM can determine without the attribute
<joesteele_> ... this was just our attempt to keep attribute
<joesteele_> paulc: so agreement from last week there is no objection to?
<joesteele_> jdsmith: correct
No objection to the proposal from last week https://github.com/w3c/encrypted-media/issues/7#issuecomment-70168165 <https://github.com/w3c/encrypted-media/issues/7#issuecomment-70168165>
last week's discussion: http://www.w3.org/2015/01/13-html-media-minutes.html#item11 <http://www.w3.org/2015/01/13-html-media-minutes.html#item11>
<joesteele_> paulc: any more discussion? david you know what to do?
<joesteele_> RESOVLED to fix as per discussion last week
ISSUE-8 Define behavior for implementations that delay playback until setMediaKeys() is called

<joesteele_> https://github.com/w3c/encrypted-media/issues/8 <https://github.com/w3c/encrypted-media/issues/8>
<joesteele_> jdsmith: just looked this morning -- need another day or two to review
<joesteele_> ... think I agree with David's logic
<joesteele_> ... this applies to next one (ISSUE-9) as well
<joesteele_> paulc: Jerry has 72 hours to respond to issues 8 & 9
<joesteele_> https://github.com/w3c/encrypted-media/issues/9 <https://github.com/w3c/encrypted-media/issues/9>
EME/MSE heartbeat publications

http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0030.html <http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0030.html>
<joesteele_> paulc: believe naming items are done, job is in the editors hands
plans for next meeting

<joesteele_> paulc: we said we would give MSE a month, so EME mtg next week and week after?
<joesteele_> markw: since we have some additional time, some naming related bugs are still around. can we handle?
<joesteele_> ddorwin: I will not be available the next two Tuesdays, only available on the 10th
<joesteele_> ... available after the next two weeks
<joesteele_> ddorwin: next week all day mtg and then on vacation
<joesteele_> paulc: proposal is to meet again on Feb 10th
<joesteele_> ... any objections?
<joesteele_> ddorwin: hopefully make progress in the bugs
<joesteele_> paulc: so EME mtg on Feb 10th, Paul to decide whether we have MSE mtg on Feb 3rd
Naming Bugs

<markw> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092>
Bug 25092 - Need a way to inform script that resolution restrictions are applied

<joesteele_> markw: think we concluded in the bug
<joesteele_> ... need to finalize that
<joesteele_> ddorwin: haven't read the reply yet
<ddorwin> "downscaling" or "output-downscaled"? I prefer the latter since it's consistent with "output-not-allowed".
<joesteele_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092>
<joesteele_> markw: I am fine with that
<joesteele_> +1
<jdsmith> +1
<joesteele_> paulc: any objection to resolving with the name "output-downscaled"
<joesteele_> markw: I think it is unavoidable that the keystate changes when content is downloaded
<joesteele_> paulc: david can resolve the bug with that name
<markw> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124>
Bug 27124 - Add "individualizationrequest" to the MediaKeyMessageType enum

Henri's email appeal to fix all naming items: http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0023.html <http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0023.html>
<joesteele_> Add "individualizationrequest" to the MediaKeyMessageType enum
<joesteele_> paulc: Henri says this is blocked on a naming issue
see Mark's support for individualization-request https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124#c20 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27124#c20>
<joesteele_> paulc: marks comment points to individualization-request
<joesteele_> paulc: any additional discussion?
<joesteele_> +1
<joesteele_> jdsmith: ok
<joesteele_> RESOLVED to fix 27124 with individualization-request
Bug 27283 - InvalidAccessError usage is questionable; use TypeError instead?

<joesteele_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27283 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27283>
<joesteele_> ddorwin: don't think this is a big deal, app will get a rejected promise
<joesteele_> ... don't think the difference will be checked
Depends on WebIDL bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=27284 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=27284>
<joesteele_> paulc: continue to wait on bug 27284
<joesteele_> paulc: David to you have everything you need to do the heartbeat? 4-5 bugs to resolve
<joesteele_> ... lots of work
<joesteele_> ... think we are done
<joesteele_> ddorwin: there are probably 5 or so other bugs folks should look at in github
<joesteele_> paulc: thanks everyone!
<ddorwin> Please take a look at new bugs at https://github.com/w3c/encrypted-media/issues <https://github.com/w3c/encrypted-media/issues>
<joesteele_> ... back on Feb 10th to discuss
<joesteele_> s/concenr/concern/
Summary of Action Items <>[End of minutes]
Minutes formatted by David Booth's scribe.perl <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version 1.140 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2015-01-20 16:57:07 $


Received on Tuesday, 20 January 2015 17:02:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 January 2015 17:02:17 UTC