W3C

- DRAFT -

HTML Media Task Force Teleconference

20 Jan 2015

Agenda

See also: IRC log

Attendees

Present
Regrets
Chair
paulc
Scribe
paulc, joesteele

Contents


<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

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/

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015-01-20 16:57:07 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/keystatuschange/keystatuseschange/
Succeeded: s/or keystatusisChanged//
Succeeded: s/concenr/concern/
Succeeded: s/weke/week/
Succeeded: s/wiatingFor/waitingFor/
Succeeded: s/primise/promise/
Succeeded: s/heartbeta/heartbeat/
Succeeded: s/ for the next two weeks//
Succeeded: s/Bug 25892/Bug 25092/
Succeeded: s/fnialize/finalize/
Succeeded: s/Bug 27283/Bug 27283 - InvalidAccessError usage is questionable; use TypeError instead?/
FAILED: s/concenr/concern/
Succeeded: s/disucssion/discussion/
Succeeded: s/pubs/publications/
Succeeded: s/Bug 25092/Bug 25092 - Need a way to inform script that resolution restrictions are applied/
Succeeded: s/Bug 27124/Bug 27124 - Add "individualizationrequest" to the MediaKeyMessageType enum/
Succeeded: s/Issue 14: Consider/ISSUE-14 Consider/
Succeeded: s/usuaulyll/usually/
Succeeded: s/realized whether this was application visible/realized whether this was application visible is an issue/
Succeeded: s/just how I implemented it/just how I implemented it originally/
Succeeded: s/David logic/David's logic/
Found Scribe: paulc
Inferring ScribeNick: paulc
Found Scribe: joesteele
Found Scribe: paulc
Found Scribe: joesteele
Scribes: paulc, joesteele

WARNING: No "Present: ... " found!
Possibly Present: BobLund David Jerry Microsoft P2 Paul aaaa aabb adrianba davide ddorwin html-media https jdsmith joesteele joesteele_ joined markw paulc proposal trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0036.html
Found Date: 20 Jan 2015
Guessing minutes URL: http://www.w3.org/2015/01/20-html-media-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]