HTML Media Task Force Teleconference -- 11 Dec 2012

<trackbot> Date: 11 December 2012

<adrianba> scribe: johnsim

previous meeting minutes

<adrianba> http://www.w3.org/2012/11/01-html-wg-minutes.html#item05 -> Lyon F2F

<adrianba> http://lists.w3.org/Archives/Public/public-html-media/2012Nov/0013.html -> Nov 27

<adrianba> http://lists.w3.org/Archives/Public/public-html-media/2012Nov/att-0006/EME_open_bugs_2012-11-1.html -> Lyon bug list

adrianba: bug list is earlier version we discussed in lyon - this is the list of bugs we actually went through
... any comments on minutes?
... hearing none - move on

Review Action Items

<adrianba> ACTION-7?

<trackbot> ACTION-7 -- Joe Steele to provide a well-defined description of the uses cases along with some diagrams showing the various parties. -- due 2012-12-11 -- OPEN

<trackbot> http://www.w3.org/html/wg/media/track/actions/7

Joe: a little discussion on use cases i sent out, just reading through them now. Is David on the call?

<ddorwin> yes

Adrianba: worth spending a few minutes on this now

joesteele: use cases all boil down to the same problem - content URI of some kind - playlist or embedded downloadable content...
... don't have the context - the license server has enough information to provide that back, but no mechanism to provide that back

<adrianba> http://lists.w3.org/Archives/Public/public-html-media/2012Dec/0008.html -> Action-7 use cases

joesteele: no way say "authentication failed and here is what I want you to do"
... one way to solve, key message with URL and some parameters, but not sure what best way to solve this problem would be, just that the problem exists
... two ways - in the key request enough info to tell the CDM how to authenticate
... in the more general case, i believe we need to standardize how they communicate, like a URL redirect for the appropriate authentication server
... was everyone able to see diagrams i put up? Not sure if they were published correctly.

ddorwin: i was able to see them

adrianba: david, want to respond?

ddorwin: continue on the mailing list and then pick it up next time, to give others a chance to review

<adrianba> close action-7

<trackbot> ACTION-7 Provide a well-defined description of the uses cases along with some diagrams showing the various parties. closed

adrianba: close that action as being done - discussion on the list - and continue as david said and continue on next EME call

ddorwin: one thing, i asked what specifically what to change, not decided, so we have examples but we need - what type of thing and where; e.g. something on keymsg

mark watson: what to include in the First working draft

regarding secure key release

mark: was removed when we went to the object oriented model

adrianba: i think if we - just jump ahead to that for a second - the first public working draft - as we discussed on last week call for MSE
... paul wanted us to spend time thinking about what bugs must be fixed before calling for consensus to go to FPWD
... complete in terms of scope it covered and reasonable to review and not likely to change substantially again
... my view is we need to make a decision if secure key is in the spec - i think we need to make progress on that before FPWD

mark watson: agree. concern in Lyon - were implementation concerns - would those requirements be relaxed so people are comfortable going to FPWD

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

<adrianba> https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=assigned_to%2Ctarget_milestone%2Cpriority%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate&component=Encrypted%20Media%20Extensions&product=HTML%20WG&query_format=advanced&order=target_milestone%20DESC%2Cpriority%2Cbug_id&list_id=3120 -> Bugs with milestone

adrianba: David made a start at marking bugs he thought we needed to fix (this link, above)
... i think we should add 17199

ddorwin: i will do that right now
... one other quick item related to this, asked off line, optional feature, should we cover it in its own section, in this stage, or add the text in each section.
... opinions on that?

mark watson: preference to keep in one section - mild preference

adrianba: do you have an opinion, david

ddorwin: no - gets messy referencing the main media spec, when we try to integrate with 5.1, it is a mild concern - probably we will discuss this more and decide based upon that

adrianba: back to the agenda - we should spend some time working through the actions from the Lyon face-to-face, to make sure we are on the same page as we did last week for MSE

<ddorwin> above was using EME spec referencing the main spec as an example. We can look at Mark's proposed text and the number of references and decide from there.

Actions from Face to Face meeting

<adrianba> http://www.w3.org/2012/11/01-html-wg-minutes.html#item05 -> Minutes

<adrianba> http://lists.w3.org/Archives/Public/public-html-media/2012Nov/att-0006/EME_open_bugs_2012-11-1.html -> List of bugs

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

adrianba: bug 20335

joesteele: is the implication - the application would have to have a list of media keys and call them in turn?

adrianba: always our expectation that apps would need to query for the specific formats that were supported by this spec

ddorwin: do we need mediakeys object for each system - the answer is no because it is a static function - takes same parameters as canplaytype() - no change in functionality

joesteele: how would the static be used without knowing ahead of time

ddorwin: you would say mediakeys.istypesupported(xxx) with codec if you want - so you don't need to have created mediakeys to support this

joesteele: got it

adrianba: other change, since a boolean, will not return probably or maybe, which does clean some stuff up,

<adrianba> johnsim: why isn't the same ambiguity of canPlayType needed for isTypeSupported?

ddorwin: saying "maybe, probably are "True" and "False" is there is no shot at it - confusion of maybe and probably - mediasource has the same issue, mimetype and optional codec
... with mediasource can query canplaytype() - with EME the codec may be implemented by the key system -

aaron: idea of the boolean is to represent maybe and probably because no difference in whether you will try to play it or not, istypesupported is asking does the CDM support that mimetype

ddorwin: there are some differences there - mediasource more important mimetype is supported, where the codecs might matter a bunch on EME

aaron: MSE can do a check, never report TRUE when canplaytype is not returning probably or maybe, but if it returns true, doesn't guarentee playable

ddorwin: maybe we should think more about this and not be strictly playable with MSE

aaron: why is key system and codec different
... key system and codec together, isn't that sufficient

ddorwin: may be profiles you cannot for sure play

aaron: MSE willing to accept these things, do you need something as a stronger true/false determination?

ddorwin: possible codec can be played unencrypted but cannot be played encrypted
... if you have diff decoders, main line and baseline, cdm can only do baseline, then saying i can play that codec is not necessarily true

adrianba: i think the goal here is to provide - if the user agent can play a particular type but EME doesn't support that at all, this is the mechanism to understand that
... maybe from canplaytype() for the media IN GENERAL from the user agent, isn't it likely you would get the same maybe from EME?
... only way to know for certain something will play is try to play it.
... so example, user agent supports without EME, but not with EME

aaron: canplaytype() would say MAYBE, EME would say False
... slightly different than MSE, true or maybe is mainly about the codecs and formats
... that relationship may be reversed, with extra information from keysystem, can't play this

adrianba: why is that different, aaron said you may end up with EME iwith type supported more often returned FALSE, but that could happen with MSE if support was only for one format over a lot of different formats
... the question is whether the combination is supported at all, trying to play media and discovering you couldn't - want to find out as soon as you can

aaron: adding an extra constraint, EME you are not -

ddorwin: the codecs are in the CDM so they are not the same as the ones in the media stack - end up with false positive "TRUES" -

<joesteele> +q

ddorwin: media source container concern, ignores codec, EME needs to care about container and codec

<joesteele> -q

aaron: i think if the string looks like it is valid from EME, with static information, it is okay to return true, but canplaytype() should say MAYBE

ddorwin: canplaytype is not useful for EME

boblund: you are saying UA could support codec X that doesn't support EME content, and canplaytype would return probably, but CDM would not support encrypted content?

ddorwin: correct

boblund: then EME breaks canplaytype()

aaron: still don't understand why this is diff
... would check profile in mimetype and validate if keysystem supports that - need strict mimetype checking

<joesteele> I have to drop off -- good discussion though -- looking forward to the notes

ddorwin: only imlementation i know is chromes, avc.anything, says probably, avc.foo would say "sure"

adrianba: i think we need to move on - is type supported, do we need to return similar information as canplaytype() and continue discussion offline

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

adrianba: next is bug 17673
... bug needs to be reassigned to one of the editors to be implemented

ddorwin: some discussion about generalizing it to all MP4 - David Singer - johnsim and david to talk

<adrianba> ACTION: johnsim to discuss 17673 with dsinger [recorded in http://www.w3.org/2012/12/11-html-media-minutes.html#action01]

<trackbot> Sorry, couldn't find johnsim. You can review and register nicknames at <http://www.w3.org/html/wg/media/track/users>.

<adrianba> ACTION: jsimmons to discuss 17673 with dsinger [recorded in http://www.w3.org/2012/12/11-html-media-minutes.html#action02]

<trackbot> Created ACTION-8 - Discuss 17673 with dsinger [on John Simmons - due 2012-12-18].

adrianba: add the text and then tweak it so we can make some forward process

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

adrianba: next one is 17682

ddorwin: may be documented in minutes change to IETF required to us JSON solution

adrianba: mark suggested we follow reference to this and paul's reply was if this didn't get --- wasn't progress externally we could include an appendix with the details that we could then remove - if we created an appendix for details, and finalized in IETF, we could remove from our appendix
... i think the action is we need a concrete proposal for text, we have the one from john, we need the text for JSON, the question is go with the text we have?

<adrianba> ACTION: jsimmons to discuss 17682 with markw and propose text for JSON solution [recorded in http://www.w3.org/2012/12/11-html-media-minutes.html#action03]

<trackbot> Created ACTION-9 - Discuss 17682 with markw and propose text for JSON solution [on John Simmons - due 2012-12-18].

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

adrianba: then, can we quickly discuss 17470, which we resolved - no comments on that, so next one is 17660 - that is the action we discussed at beginning of the call

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

adrianba: 17203 - and we concluded that mandatory - easy to do and needed for key release - keeping session id was dependent on whether we supported secure key release - which mark identified as a consideration for first public working draft

ddorwin: make this mandatory for supporting secure key release and optional otherwise?

adrianba: i think what we would said was we wouldn't decide until we decide what to do with secure key release.

ddorwin: not sure how deciding how we implement secure key release impacts that
... i also mentioned that you might use it as a custom attribute, media key session, so we might not need it necessarily

adrianba: if generated by the CDM need to be in a predictable place

ddorwin: right
... paul questioned if consistency was enough to make it required
... so question stands regardless of determination of secure key release

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

adrianba: 18531

naming for addkey() and were there any further questions on changing it to "update

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

adrianba: 17199 which is the key release issue which we know we need to cover

<adrianba> MediaKeys attachment is a method instead of property

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

adrianba: so okay - we are out of time - last thing we had was progression to FPWD which we discussed earlier - target milestone - identify the bugs that need to be fixed to get to FPWD, folks have others they think need to be fixed do so on the reflector so we can settle on the list before the next meeting
... any final comments?
... not hearing any, adjourned.

thanks

- DRAFT -

HTML Media Task Force Teleconference

11 Dec 2012

Attendees

Contents

previous meeting minutes

Review Action Items

regarding secure key release

Actions from Face to Face meeting

Summary of Action Items

Scribe.perl diagnostic output