HTML Media Task Force Teleconference -- 02 Oct 2012

<trackbot> Date: 02 October 2012

<johnsim-msft> 2. Previous meeting minutes on Sep 18 http://www.w3.org/2012/09/18-html-media-minutes.html

<scribe> ScribeNick: joesteele

Review action items

<johnsim-msft> https://www.w3.org/html/wg/media/track/

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

johnsim-msft: propose a solution to the clear key bug, did add a comment a few minutes ago bug#17682
... some others we could discuss as well

<johnsim-msft> http://tinyurl.com/7tfambo

johnsim-msft: no analysis yet on closing these bugs

Title: HTML-Media

<scribe> Meeting: HTML Media Extensions

<johnsim-msft> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673 container guidelines https://www.w3.org/Bugs/Public/show_bug.cgi?id=17682 clear key https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208 keymessage event not needed https://www.w3.org/Bugs/Public/show_bug.cgi?id=19156 switching decoders

johnsim: container guidelines bug
... I had an action item on this.
... new bug coming on ISO based media file formats should have stronger guidelines when a CDM has a key in it storage

ddorwin: no preference on order

johnsim: starting with container guidelines bug

… exchanged some email on this and added to the bug

<scribe> … new bug is 19208

johnsim: this is specific to the COmmon Encryption Format specification
... please read the bug online
... this is the proposed language for the ISOBMFF guidelines

… captures enough of how to detect encryption and extract the metadata needed from those files

… does raise some issues about initialization and events

… there are cases where the CDM does not need to issue a key message event

… any comments or concerns, David?

ddorwin: no comments

johnsim: next bug is bug#17682 (clear key bug)

… documents how keys and key ids are associated

<BobLund> mute

… added a brief comment to the end of the spec

<BobLund> mute me

johnsim: how clear key works should be the same as the CDM
... should be defined by the W3C since this is strictly a W3C concept

… data blob specific to CDM is in the spec, in the case of clear key just a key

… need to define how clearKey is initialized or any media format is supported

… propose some draft language based on some email traffic to be sent to general rflector

johnsim: need to add language for other formats

ddorwin: for ClearKey specific stuff, and ISO, nothing to define just a keyid

… for other containers need to define

… this is part#1 of the bug, part#2 is the license

… this is the harder part, need to define key/keyid pairing

johnsim: there have been some proposals out there
... do you mean a defined data structure like a license being passed down?

ddorwin: yes

… in the old version for WebM has a simple definition but this has been removed

… need a license to provide more than one key

markw: need to say how do we support more than one key at a time?

ddorwin: want clearKey to be as capable as other CDMs to use for prototyping

… maybe use JSON or something

johnsim: we are talking about the analog to a license for clearKey, requirement is that is be capable of communicating more than one key/keyID pair

… I am a little hazy on that

… init data would have to report more than one

ddorwin: nothing that says you can't have more than one keyid

johnsim: keyed is really a meta-key which tells the server to deliver more than one key at once

ddorwin: might need to be base64-encoded JSON but moves a little away from original spirit

johnsim: some work on this in the webCrypto group

<ddorwin> where the spirit was to be able to easily specify a key in JS

markw: you mean how keys are encoded? we just specify an arrayBuffer of the raw bytes at this point

johnsim: so this action item is still open. Need to propose license structure for clearKey
... should we move on?
... jumping to switching decoders bug #19156

… has been some discussion but no replies yet

ddorwin: unlike clearKey some CDMs will include decoders and/or rendering pipelines

… this means you may be picking a decoder by picking a CDM

… this may cause a switch in the decoder being used

… what should we do in that case?

… should we spec it away?

aaron: should not spec it away at this point

… could be implementation

johnsim: could have portions encrypted and some not

aaron: thinking of the case where content comes from multiple files

johnsim: the metadata would be from different files in this case?

aaron: starting with unencrypted file and moving to encrypted file, should not cause decoding to stop

ddorwin: need to specify the decoder up front

… how does media source handle this?

… currently only one key system allowed per media element

markw: currently decoder is not allowed to change
... prefer not to prevent it for now if possible
... will comment on the bug

s: /markw: will comment/aaron: will comment/

aaron: as long as you are only switching during media segment boundaries, should avoid this problem

Aaron_Colwell: could have the CDM disable encryption when clear frames comes through

markw: you need the CDM to be able to handle this already

this is an issue for ad-insertion

<markw> my point was just that (i) the CDM should be able to cope with unencrypted samples and (ii) the first encrypted sample and all subsequent samples must not depend on any samples before the first encrypted sample

johnsim: so we will add comments to the thread on this?

ddorwin: will reply with what I heard

johnsim: moving to bug#19208

… based on the container guideline bug

… came across a case where the keyMessage event might not be needed

… David pointed out this contradicts the spec

… bug is -- if a session is created which activates a CDM, and key storage already has a key, no need for a keyMessage event

… David, what do you think?

ddorwin: does not violate the spirit of the spec

… but we might need to change the text of the algorithm (BMFF text)

johnsim: you don't disagree then

ddorwin: don't have any objections, but would like feedback and thought
... calling createSession would not cause a message to the app, which is a little strange

johnsim: had discussions about the event corresponding to a key successfully being extracted

… is the a need for that event (e.g. a null-key messages)

ddorwin: we have KEYERROR we could add a ALREADY_HAVE_A_LICENSE_ERROR

… createSession could return a reference to an existing session - need to think about that more

… would not matter so much whether you got another message then

johnsim: any other thoughts on this issue?
... going back to the list of open bugs

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

johnsim: renaming addKey

<ddorwin> http://lists.w3.org/Archives/Public/public-html-media/2012Sep/0045.html

markw: there was a couple of suggestions -- update() was the only one commented on
... would suggest we go with that

I like update()

ddorwin: only concern is that in the general case we are adding a license

johnsim: you are really adding things -- more than an update

markw: update() means providing more information

<ddorwin> http://dictionary.reference.com/browse/update

johnsim; connotation of providing entirely different information and adding values

<ddorwin> http://mw1.merriam-webster.com/dictionary/update

johnsim: there are quite a few open bugs

<ddorwin> transitive verb: to bring up to date

johnsim: what is the status for the open bugs?

<johnsim-msft> http://tinyurl.com/7tfambo

I did not get to the example I was to do.

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

johnsim: are folks attending the TPAC meeting?

ddorwin: yes I will be

I am not going at this point

johnsim: encourage everyone on the call with open bugs to resolve or start a thread on these bugs ASAP

… want to reach closure at TPAC or before if possible

ddorwin: many are editorial

johnsim: would be great to pull out the substantial bugs

… design questions, etc

… any that sit at the top of the list as needs resolving?

ddorwin: the clearKey bug must be resolved

<adrianba> we don't have to close every bug - we need to ensure the document covers the desired scope before we ask for FPWD

ddorwin: needKey is another one

johnsim: which is the needKey?

ddorwin: will try to get the other bug I need to file out

… and send an email

ddorwin: no major changes to the spec in these bugs

johnsim: concern about the specs fitting together?

ddorwin: MSE is another source for the URL should work together, might need to discuss advanced use cases

<scribe> … new segments from other key systems, etc.

markw: will scribe for next meeting

ddorwin: TPAC is on the 29th

johnsim: next EME call will be the last one before the TPAC
... would like to discuss how we can use the TPAC to advance the spec on the next call
... would like to resolve as many bugs as possible before than as well
... David the issues you raised we should really resolve
... raises our chances of coming out with a good draft
... pretty much done

bye all

- DRAFT -

HTML Media Task Force Teleconference

02 Oct 2012

Attendees

Contents

Review action items

Summary of Action Items

Scribe.perl diagnostic output