14:59:59 RRSAgent has joined #html-media
14:59:59 logging to http://www.w3.org/2014/06/17-html-media-irc
15:00:01 RRSAgent, make logs public
15:00:01 Zakim has joined #html-media
15:00:03 Zakim, this will be 63342
15:00:03 ok, trackbot; I see HTML_WG()11:00AM scheduled to start now
15:00:04 Meeting: HTML Media Task Force Teleconference
15:00:04 Date: 17 June 2014
15:00:11 glenn has joined #html-media
15:00:14 markw has joined #html-media
15:00:24 HTML_WG()11:00AM has now started
15:00:31 +Niels_Thorwirth
15:00:48 joesteele has joined #html-media
15:01:16 ddorwin has joined #html-media
15:01:22 davide has joined #html-media
15:01:34 calling again
15:01:38 + +1.425.936.aaaa
15:01:40 +glenn
15:01:41 +leandro
15:01:41 +MarkW
15:01:45 zakim, aaaa is me
15:01:45 +ddorwin; got it
15:01:55 +[Microsoft]
15:01:56 +[IPcaller]
15:01:56 Zakim, who is here?
15:01:56 On the phone I see Niels_Thorwirth, ddorwin, glenn, MarkW, leandro, [Microsoft], [IPcaller] (muted)
15:01:58 Zakim, MarkW is me
15:01:59 On IRC I see davide, ddorwin, joesteele, markw, glenn, Zakim, RRSAgent, niels_t, paulc, trackbot, wseltzer
15:01:59 +markw; got it
15:02:03 zakim, [Microsoft] is me
15:02:03 +paulc; got it
15:02:07 annevk has joined #html-media
15:02:14 Zakim, who is here?
15:02:14 On the phone I see Niels_Thorwirth, ddorwin, glenn, markw, leandro, paulc, [IPcaller]
15:02:17 On IRC I see annevk, davide, ddorwin, joesteele, markw, glenn, Zakim, RRSAgent, niels_t, paulc, trackbot, wseltzer
15:02:18 adrianba has joined #html-media
15:02:19 Chair: paulc
15:02:22 Zakim: [IPCaller] is likely me
15:02:37 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jun/0044.html
15:02:46 Scribe: joesteele
15:02:50 +davide
15:02:56 pal has joined #html-media
15:03:32 +pal
15:03:50 zakim, who is on the phone?
15:03:51 On the phone I see Niels_Thorwirth, ddorwin, glenn, markw, leandro, paulc, [IPcaller], davide, pal
15:03:54 adrianba has joined #html-media
15:04:36 +[Microsoft]
15:04:51 zakim, [Microsoft] is me
15:04:51 +adrianba; got it
15:05:18 Topic: Bug 25594 - The read-only attribute usableKeyIds cannot be variable length
15:05:34 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25594
15:05:48 Zakim, [IPcaller is me
15:05:48 +annevk; got it
15:05:53 paulc: I sent out the list of bugs which needed comments
15:06:08 ... followed up when I got back from China but some did not have comments as yet
15:06:19 ... for each one we will just look at the bug
15:07:10 ddorwin: I looked at the replies. This was one of the two proposals I had
15:07:13 ... I am fine with that
15:07:31 paulc: Anna's comment is here
15:07:34 See Anne's comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=25594#c6
15:07:51 joesteele: +1
15:08:09 s/Anna/Anne/
15:08:13 paulc: any comments -- or will be assigned as described
15:08:50 BobLund has joined #html-media
15:09:15 jdsmith has joined #html-media
15:09:19 paulc: believe we can assign to the editors -- David
15:09:20 +[Microsoft]
15:09:43 Topic: Bug 25966 - Use ArrayBufferView and ArrayBuffer instead of Uint8Array in APIs
15:09:46 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25966
15:09:49 + +1.303.661.aabb
15:10:03 zakim, aabb is me
15:10:03 +BobLund; got it
15:10:14 paulc: one response from Jerry saying he sugesting we switch to ArrayBuffer
15:10:34 q+
15:10:37 jdsmith: tlking to other on Playready team -- they convert to byte format -- haven't closed on this yet
15:10:44 The general problem here is https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369
15:10:59 IDL needs a common thing for APIs accepting bytes
15:11:03 ... in other implementations that type is converted to byte -- this might cause a compatbility issue
15:11:25 ddorwin: I thought you could format this however you want even with ArrayBuffer
15:11:35 q?
15:11:35 ... then it inly matters how you get it out in the browser
15:11:49 paulc: Anna pointed at the general bug
15:12:12 annevk: we want all the APIs to take a sequence of bytes to accept the same types of objects
15:12:17 ... we have had inconsistencies
15:12:29 ... EME only accepts uint8?
15:12:49 paulc: does this WebIDL bug have a recommendation?
15:13:07 annevk: still under discussion - no person driving IDL forward, or at least not enough time
15:13:15 s/Anna/Anne/
15:13:17 ack adrian
15:13:46 adrianba: we tried in some other APIs absent of a single way of accepting a sequence of bytes, is to allow ArrayBuffer or ArrayBufferView to be provided
15:14:00 ... then the browser just grabs the underlying seuqence of bytes -- the backing store
15:14:19 adrianba: you might want to comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369
15:14:46 ... in Trident you can pass either one and either should work. Might not make sense to put an array of doubles in the structure, but in the ened you will still get back what is stored
15:15:00 ... I propose we accept both
15:15:29 ... if you have an ArrayBuffer creating the ArrayBufferView is a pain
15:15:37 paulc: how to do this in the spec?
15:15:52 adrianba: as an overloaded method?
15:16:11 paulc: you are saying there is advantage to doing both
15:16:14 adrianba: yes
15:16:15 q+
15:16:20 ack dd
15:16:27 ddorwin: what about the needkey and initData?
15:16:35 adrianba: I think that should be an ArrayBuffer
15:17:11 ... advatnage for a method accepting data in is that you can create whatever view you want of it, you can pass it around
15:17:28 ddorwin: I have enough for the bug -- assigning to Jerry
15:17:38 paulc: solution then
15:17:59 jdsmith: there are several arrays where these are used, should I convert them all?
15:18:27 ddorwin: I wrote down that methods should be both and event attributes should be ArrayBuffer
15:18:34 ... probably includes Promises
15:18:58 Topic: Bug 25923 - isTypeSupported should be asynchronous
15:19:00 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25923
15:19:31 paulc: no comments since June 1st
15:19:45 ... originally Anne's comment
15:19:57 q+
15:20:09 ... no progress since last meeting
15:20:27 ddorwin: some developers said it was inconvenenit but could adapt
15:20:38 ... Jerry updated the other isTypeSupported bug -- I have not responded yet
15:20:58 ... if we were to expose more capabilities as he mentions we would need it to be asynchronous
15:21:20 other isTypeSupported bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873
15:21:32 annevk: this would let the EME subsystem be disconnected
15:22:08 ddorwin: this has been implemented might want to break that one out
15:22:17 Specifically, what is proposed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873#c14
15:22:23 paulc: suspect it would be good to handle today
15:22:51 paulc: summary - making this async makes sense for the reasons given
15:23:08 ddorwin: there are also some implementation difficulties -- have to see how that goes
15:23:26 paulc: any other comments?
15:23:55 .... sounds like we have a proposal.
15:24:04 ... Who is this assigned to?
15:24:25 ddorwin: not sure we want to make this until the other change is made (24873)
15:24:35 paulc: so make dependent?
15:24:51 ... do you want to discuss the other right now then?
15:24:54 ddorwin: yes
15:25:22 Topic: Bug 24873 - Current isTypeSupported() definition does not provide sufficient information to applications
15:25:36 bug - https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873
15:25:53 ^ Specifically: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873#c14
15:26:31 jdsmith: the part of the comment we have been working on is structuring the DOMString as a dictionary
15:26:46 ... looked a bit into privacy -- might need a user prompt to retrieve some of this info
15:27:02 ... there is 4K content that will require specific capabilities in the device to stresam
15:27:18 ... could try and fail, but would prefer to check up front prior to playback
15:27:30 ... tried to list the ones I thought were needed
15:27:56 ... 2nd thing I put was that the downside is that the dictionary could be closed and specific, e.g. might need specific HDCP type
15:28:15 ... another idea came up for submitting the license to the CDM and see if playable
15:28:16 +q
15:28:23 ack dd
15:28:48 ddorwin: I did not reply because I had not thought through all the way yet
15:28:59 ... think we should close this one and open a new capability detection bug
15:29:03 ack joe
15:30:15 joesteele: I would be in favor of a solution that submits the license to the CDM for validation -- we have a similar mechanism today
15:30:29 ... not clear whether this is a license from a server or embedded in the initData
15:30:50 jdsmith: there is a need for determining quickly whether the criteria for playback are met
15:31:01 ... think they should be discussed on the same bug
15:31:17 paulc: thikn you should bring the comment from the older bug and add to the new bug
15:31:22 ... then comment on it yourself
15:32:01 .... David is we mark this bug as resolved fixed - should we make the previous bug dependent on this new bug?
15:32:05 ddorwin: yes
15:32:23 paulc: then Jerry can you make sure 25923 is depend on this new bug?
15:32:37 s/sure 25923/bug 25923/
15:32:44 annevk, i added my comment to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369#c16
15:33:17 ... ok then we will create a new bug and add the dependencies as described and close bug 24873
15:33:34 Topic: Bug 25866 - needkey event name is misleading
15:33:37 https://www.w3.org/Bugs/Public/show_bug.cgi?id=25866
15:33:48 adrianba, thanks!
15:34:00 paulc: mark responded last Thursday -- David what is the status?
15:34:16 ddorwin: Mark has a proposal, was not wild about it, still looking for better names
15:34:49 paulc: encrytped and encryptedInitData, encryptedMedia are all possibles
15:34:56 Alternatives include: "encrypted" and "encryptedinitdata" or "encryptedmedia"
15:35:01 s/encrytped/encrypted/
15:35:08 Other suggestions welcome!
15:35:11 --- crickets ---
15:35:23 paulc: any suggestions? distaste?
15:36:15 joesteele: I like "encryptedMedia"
15:36:35 paulc: shall we leave it open for now then?
15:36:48 ... ok leave this for now
15:37:04 ... if "needkey" is misleading -- we do not have a strong contender to replace as yet
15:37:17 Topic: Bug 18515 - --- Provide more details on behavior of the media element when the key for an encrypted block is not available
15:37:20 https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
15:37:36 ddorwin: Jerry implemented, I had some questions on corner cases
15:37:53 ... thought we could use a Promise, proposed in comment #31
15:37:54 See proposl in https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c31
15:38:13 ... thought we could address this by ordering the Promises, but not happy with that either
15:38:36 ... thinkg there are problems with the event version and the Promise version, need something better
15:38:42 ... please read the comment and respond
15:38:55 paulc: does the bug enumerate what you think the problems are?
15:39:28 ddorwin: Jerry implemented a solution in comment 27
15:39:36 ... I reviewed and replied in comment 28
15:39:57 ... Dominic updated the Promises guide and in comment 29 I suggested we use what he added
15:40:37 ... in comment 31 I provide a proposal for how we could use the Promies as described
15:41:04 ... in comment 31 the real problem comes down to resetting the Promise you want it to be resolved as it is checked
15:41:17 .. then you want to return a new one. The application should know when to grab the new one
15:41:32 ... the timing is confusing. How to you tell the application when to grab the new one?
15:41:49 ... if it does not get it, it will always just be waiting for a new event/promise
15:42:08 ... comment 32 was a proposed solution to the problem of resetting the Prmoise
15:42:44 paulc: Jerry/Adrian -- since David is questioning this implementation -- do you ahve solutions?
15:43:08 jdsmith: my ready of commet 28 is that there are more ramifications to waitinfforkey
15:43:29 ... when we started the waiting event was very straighfirward -- a little more complicate when we extend it
15:43:42 q+
15:43:48 ... my bias is to resolve the complexity and make it work, was hoping for a less entangled solution
15:43:49 q+
15:44:01 ack mark
15:44:21 markw: I think I feel the same as Jerry, seems like the existing waiting event expressed the high level intention
15:44:28 Why does setMediaKeys() not return an array of promises?
15:44:36 One for each key?
15:44:47 ... going to be the same whether waiting for media or waiting for a key at the high level
15:45:01 (Or have a method that simply looks up one and returns a single promise.)
15:45:02 ... the Promises stuff might overcomplicate this -- not clear how to marry together
15:45:12 ack dd
15:45:37 ddorwin: about Promises being one-off - the link described using for state transition -- just more complicated
15:46:05 ... the event solution is not perfectly straightforward either, with auto-resume and the key even t stuff
15:46:13 ... interacts with 5.1
15:46:21 q+ to ask if there's an overview of the requirements here
15:46:23 ... recommend reading that
15:46:45 s/5.1/section 5.1/
15:47:05 ack annevk
15:47:05 annevk, you wanted to ask if there's an overview of the requirements here
15:47:20 annevk: might be good to email public-script-coords with the requirements
15:47:30 ... see what you get back in terms of API advice
15:47:44 ... or copy the relevant people (from that group) on the bug
15:47:49 See http://lists.w3.org/Archives/Public/public-script-coord/
15:47:50 ... I could help with that
15:48:02 s/public-script-coords/public-script-coord/
15:48:06 s/public-script-coords/public-script-coord/
15:48:18 paulc: any other comments?
15:48:40 ... ok -- as David said. Need folks to look at the text for the event proposal and the various comments
15:49:07 Topic: EME Use cases Wiki
15:49:20 Topic: EME Use Cases WIki
15:49:30 See http://lists.w3.org/Archives/Public/public-html-media/2014May/0029.html
15:49:39 paulc: this was talked about in the F2F -- Joe has some changes to make
15:49:45 ... what is the status there?
15:50:28 Joe: I did some cleanup.
15:50:52 ... I tried to reorganize the material based on David using a sub-page.
15:51:22 ... I kept the EME uses separate from the question on how to load the CDM.
15:52:08 ... I want to add an additional section beyond the five applications models which I think are currently supported.
15:53:14 ... On the EME use cases pages there are three main bullets now and I will add a fourth for future application use models.
15:53:15 -annevk
15:53:36 See https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases
15:54:33 ... Asking others to look at the five applications models he re-structured and get others input.
15:54:53 ... Look at the Status and the Required fields and provide input on whether you agree.
15:55:14 q+
15:55:15 ... I want to work on the multiple licenses section. Expect changes to number 5.
15:55:23 q+
15:55:31 Ack bob
15:55:49 BobLund: Model #3 says status Supported, required is not
15:57:05 joesteele: yes -- some CDMs may not support this model
15:57:28 #3 refers to https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases#3._Limited_Concurrent_Streams
15:57:47 BobLund: can other implementors comment?
15:58:11 ack dd
15:58:12 paulc: can folks add their comments to the wiki?
15:58:46 ddorwin: the bugs link - should we remove if there are not any?
15:58:59 joesteele: these should be information bugs -- not the ones that are outstanding
15:59:04 ... still need work there
16:00:12 joesteele: I am happy to put the Adobe support for each of these models in the wiki, but did not want to call out any specific CDMs as being less compliant
16:00:33 paulc: Thanks for all the suggestions and work this week David!
16:00:33 -glenn
16:00:43