HTML Media Task Force Teleconference -- 13 Jan 2015

<ddorwin> this is html-media

<joesteele> trackbot, start meeting

<trackbot> Date: 13 January 2015

<joesteele> scribe: joesteele

trackbot, start meeting

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 13 January 2015

Role Call

Bugs awaiting input

Bug 27268 - Add a definition of a distinctive identifier

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27268

ddorwin: no replies from henri
... implemented but no replies from henri since december

Bug 27093 - Support for proprietary/system-specific formats in initData should be discouraged/deprecated

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27093

ddorwin: saw that joe replied yesterday -- no chance to reply as yet
... any other comments?

joesteele: think I covered most of the three we discussed
... might have missed one

ddorwin: might be good to discuss next week

other bugs

Bug 27738 - Need to change name of 'message' event to avoid confusion

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27738

ddorwin: filed by Glenn last week with some others
... posted some updates about names -- is this really a problem?

does someone have comments on this one?

scribe: messages are used for APIs and they are all used for simple events, we are using for custom events
... should not do that

jdsmith: is this a big change? could accomodate

ddorwin: it is misleading as it is unlikely to relate to a key
... it just about finding another name

markw: I don't think keymessage is that bad

jdsmith: I agree - does not seem like a bad name

ddorwin: I will do some more reseach and then make the change depending on the research

Bug 27739 - Change event name 'keyschange' to 'keychange'

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27739

ddorwin: I added some comments about this could imply key rotation, again a simple change, but needs feedback
... also mentioned this depends on the next bug

scribe: any basic comments?
... any comments on what the name should be

Bug 27740 - Suggest changing interface name 'MediaKeyStatuses' to 'MediaKeyStatusMap'

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27740

ddorwin: type so does not impact compatibility
... noted that the attribute that uses this type is KeyStatuses -- do we want to change that? if so to what?

<markw> MediaKeyStatusMap and keystatuschange seems good to me

ddorwin: I guess the attribute could be keyStatusMap?

jdsmith: Glenn is objecting to the plural I think

ddorwin: my point is that is used in the attribute as well
... ok we will make changes on those two as well
... will take a shot at that

Issue #3 - Add "internal-error" to MediaKeyStatus enum

https://github.com/w3c/encrypted-media/issues/3

ddorwin: could be other reasons that the key is not usable -- rather than force implementation to pick other reasons
... many statuses existed before
... will file a bug on one today
... InternalError seems like a good name

jdsmith: like that also

<markw> +1

jdsmith: intent is that an error that cannot be typed as one of the normal statuses

ddorwin: that makes senses

Issue #1 - requestMediaKeySystemAccess()'s supportedConfigurations parameter should not be optional

https://github.com/w3c/encrypted-media/issues/1

ddorinw: currently can pass a keySystem without any config
... causes additional spec logic and complexity for implementations
... getConfiguration() can also return null
... proposal is to remove optional
... discussion of "can you pass an empty config"?

joesteele: think I agree that it should be required

ddorwin: couple votes for that now
... should we have any constraints on what the config can be?

<ddorwin> Should "[ { } ]" be a valid second parameter?

ddorwin: probably easiest to leave this, to avoid the extra logic in the spec
... need to make sure the main algorithm supports that

joesteele: were you thinking about security?

ddorwin: no this was just to avoid the complexity of the logic, but this forces the developer to think about it

Issue #7 - EME should not fire waiting or canplay events - use a separate mechanism

https://github.com/w3c/encrypted-media/issues/7

ddorwin: we added waitingFor and fired the waiting event, firing canPlay etc
... got feedback that this was not good, fired on transitions in the state machine which we agreed not to do
... also changing the value of an attribute means a possible race condition
... proposal is to simplify and revert the use of waitingFor and canPlay
... just queue a simple waitingForKey event
... simpler for implementations and applications
... not indication of resuming playback, but you should not be relying on this for your playback
... in the beginning you are already working on providing a key so it is not a problem
... proposal is to remove that logic

joesteele: will have to think about that one more

ddorwin: thought this one would have the most discussion, would like to resolve relatively soon
... would like to get feedback this week

jdsmith: have you looked through the resume logic and rationalized what will happen when we are not waitingForKeys, presumably you would get an event like that still

ddorwin: have not gone through the algorithm yet, if there is a thought that that is how this would go I can
... you would want to internally track that it is in that state, we probably already have something like that internally
... it is the public state that is spec'd and possibly wrong and hard to get right
... not the end of the world to fire twice, but possibly bad if in the wrong state

jdsmith: if we can get by with a simple evenet, would be cleaner and preferable
... have not had time to go through the spec and think about this
... I think I made some of these changes. Not opposed to simplifying if we can.
... Just need to confirm no downsides to stripping out the waitingFor information

ddorwin: so you will take a look at the bug and comment?

jdsmith: yes -- have to bail now

Issue #8 - Define behavior for implementations that delay playback until setMediaKeys() is called

https://github.com/w3c/encrypted-media/issues/8

ddorwin: Jerry might care about this one as well
... non-normative note that apps should call setMediaKeys before providing media data

<joesteele_> scribe: joesteele_

ddorwin: waiting on Issue #7 to resolve this one

Issue 9 - Remove note that MediaKeySession events may not be fired until the MediaKeys object is associated with a media element

https://github.com/w3c/encrypted-media/issues/9

ddorwin: need Jerrys input on this -- please review
... currently text that in some implementations mediakey implementations will not fire events
... breaks some use case
... probably should remove this note and discourage those implementations
... believe this came from Microsoft so need Jerrys input

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27138 -

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

<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27138

<ddorwin> In the November 11th telecon, http://www.w3.org/2014/11/11-html-media-minutes.html#item10. Feedback from others is also welcome

ddorwin: this is related to the algorithms, no one has commented, Jerry would review

<ddorwin> s/In the November 11th telecon, http://www.w3.org/2014/11/11-html-media-minutes.html#item10. Feedback from others is also welcome/In the November 11th telecon, Jerry said he would review it./

ddorwin: comments are welcome
... this affects basically every algorithm
... that is all the bugs
... any other bug comments?

other business

Issue tracking

<ddorwin> http://lists.w3.org/Archives/Public/public-html-media/2015Jan/0009.html

ddorwin: sent out the email about using github

<markw> +1 for switching to GitHub

ddorwin: we have a mix now -- would like to drive the bugzilla to zero and continue to file bugs in github
... seems to work well now

joesteele: so we will continue to resolve existing bugs in bugzilla, new bugs will go to github

<markw> when we have only a few left in bugzilla we might want to move those to GitHib

ddorwin: yes. some of the new bugs are just tracking stuff I need to do
... don't appear to be many that we need to move
... except maybe that last one
... we will still receive emails from the old Bugzilla and can ask folks to move them to github
... someone would have to find the component eventually
... and then update the status of the document that has new bugs in github
... thanks everyone! that's all for now

joesteele: MSE next week?

ddorwin: probably should email thread on that

joesteele: I will go ahead and send that out

ddorwin: need folks to respond, but can probably skip EME meeting next week

s/https:\/\/www.w3.org/Bugs/Public/show_bug.cgi?id=//

s/topic\: http.*$//

s/of can you/of whether you can/

- DRAFT -

HTML Media Task Force Teleconference

13 Jan 2015

Attendees

Contents