HTML Media Task Force Teleconference -- 20 Jan 2015

<trackbot> Date: 20 January 2015

<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

David: Anne's latest message says the name change is not needed: 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

<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"

<joesteele_> Zaki, aabb is me

Bugzilla 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

Consider changing how the MediaKeySession method algorithms run other algorithms to more accurately reflect implementations

<joesteele_> https://github.com/w3c/encrypted-media/issues/14

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

<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

<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

<joesteele_> 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

<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

<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

last week's discussion: 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

<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

EME/MSE heartbeat publications

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

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

<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

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

<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

<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

<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

<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

<joesteele_> ... back on Feb 10th to discuss

<joesteele_> s/concenr/concern/

- DRAFT -

HTML Media Task Force Teleconference

20 Jan 2015

Attendees

Contents