HTML Media Task Force Teleconference -- 12 Aug 2014

<trackbot> Date: 12 August 2014

<joesteele> Scribe: joesteele

<scribe> Chair: markw

<scribe> Chair: adrianba

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 12 August 2014

<scribe> Chair: paulc

traffic

paulc: bad today

<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0005.html

EME status and bugs

EME bugs with proposal

Bug 25866 - "needkey" event name is misleading

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25866#c4

<heff_> hey, 714 is me. Steve from Brightcove/Video.js

paulc: here is the proposal

ddorwin: was talking to some team members to this -- anything really accurate is too long and wordy. This seems short and reasonable

<adrianba> +1

paulc: any objections?
... make it so David

ddorwin: ok

Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available

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

paulc: Jerry expressed some concern that the solution in the bug had not resovled some race conditions

<paulc> Race conditions concerns: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c31

jdsmith: was not a concern -- just was raised

paulc: are there outstanding issues to resolve?

<paulc> Comments since last meeting: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c40

paulc: some comments since last mtg

ddorwin: that is my comment to Jerry -- if he agrees lets move forward

jdsmith: have not looked yet
... leave for editors and assume will be resolved

Bug 20336 - Revert addition of keySystem attribute to HTMLSourceElement

<joesteele_> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20336#c8

<joesteele_> Scribe: joesteele_

paulc: any resolution needed by task force?

<paulc> David's proposal: I plan to submit a changeset that removes HTMLSourceElement (rather than spending time converting it).

paulc: proposing remove rather than convert correct?

<adrianba> +1

ddorwin: Jerry and I discussed, p3828 if no objection will make removal permanent
... don't think can support with the way isTypeSupported is today

jdsmith: I agree

s/toda /today/

paulc: any objections?
... presume resolved

Bug 26372

paulc: skipped last week because David was not here

<paulc> See David's previous changes: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c2

paulc: you provided a changeset with this comment

ddorwin: I closed the old bug and opened this one

<paulc> See Joe's feedback: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c3

ddorwin: listed some of the scenarios that are not covered by Promises
... still a question about how to return them -- error attribute does not seem to make sense
... looking for input from the group, both on errors and how to report

<paulc> See Joe's question: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26372#c4

paulc: do you have an answer to comment#4?

ddorwin: loading would be a Promise rejected with DOMException - general problem of how to report system codes in this case

paulc: is there a separate bug for this?

ddorwin: no we closed the earlier bug, Jerry is going to think about how to do system codes

<paulc> Previous bug was https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798 related to this.

paulc: old bug was 21798

jdsmith: we still have interest in a system code, but still looking for a way to add back into the spec
... in the discussion I mentioned putting systemCode as an attribute on the exception but that was viewed as unacceptable

<ddorwin> subclassing DOMException bug where systemCode was discussed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896

jdsmith: do others have opinions?
... we think they are useful for debugging errors in actual use -- need to retain somehow

paul: any alternatives?

<markw> My comment is just that it is essential for us to expose the system code in failure cases

jdsmith: only one I floated was attaching the value to the MediaKeySession - but only captures last error encountered

paulc: was that discussed?

jdsmith: we had a derivative that returned as a sub-class of DOMException but that is gone now
... DOMException has no provision for this -- only named values
... I will open a new bug and make a proposal

EME bugs awaiting input from Task Force or actions

Bug 25268 - Reduce the burden on applications to deduplicate initData from many needkey events

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268#c6

paulc: David has a proposal in comment #6 reverted earlier change and has been that way since July 11th

ddorwin: waiting for a bright idea here -- has been no good proposal yet

paulc: can someone volunteer to take a look
... propose a new solution?

glenn: this is on dedup of initData?
... is this considered an optimization? would it impact functionality if not addressed?

ddorwin: correct -- its an optimization

glenn: this could be delayed to a later version if needed

ddorwin: correct - does not block the standards progress

paulc: wish there was a status for this
... leave this on the list for now
... Glenn please add your comment to the bug

[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)

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

paulc: seemed to be a consensus at last meeting to use RFC SHOULD

<paulc> At the Jul 22 meeting we agreed that recommending that HTTPS SHOULD be used was a possible consensus position. Jerry offered to add a comment to the bug.

paulc: not a requirement
... since you were not there -- put back on the queue

markw: ... don't recall that concensus, don't think this is specific to EME, this is general to all web apps
... should not be just for our spec

jdsmith: don't know about concensus, but we did make that statement
... not sure we've all agreed that's appropriate

<paulc> Jul 22 minutes: http://www.w3.org/2014/07/22-html-media-minutes.html#item07

ddorwin: this was not last mtg

<paulc> Jul 29 minutes reference: http://www.w3.org/2014/07/29-html-media-minutes.html#item10

paulc: so Mark you are not convinced this should be a statement?

markw: yes I don't think this should be a normative statement

<paulc> See Jerry's comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c18 and Mark's reply https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c19

markw: think people were concerned about identifiers, we have some text about that already. HTTPS might be one of the mitigations but should not go so far as normative language

ddorwin: this is pretty much what we know, the difference is that this exposes a permanent or semi-permanent identifier. Will continue to be discussion in and out of bug

paulc: this is the only bug that shows up on social media streams, personal issue maybe even public policy issue
... but not sure how to resolve it
... reluctant to leave it open so we can make progress
... what will change folks opinion here?

ddorwin: this bug has only been open a month, think its fine to leave it open a while

paulc: If we can't get concensus by end of August let's revisit

glenn: Cox would like to oppose making that change. Think it's an application/policy issue

[Bug 26401] Key message destinationURL usage is not reflected in examples

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

joesteele: I have not updated the bug as yet
... will follow up on this this week

Bug 26207 - Provide a way to check system capabilities required for UHD playback

paulc: Jerry was going to provide more data

jdsmith: don't remember the extra data, but there has been a lot of discussion

<paulc> See http://www.w3.org/2014/07/29-html-media-minutes.html#item12

<paulc> From the minutes: "jdsmith: yes that is on our list, we considered testing a small piece of content. Will have more data next week"

jdsmith: think it is unnatural to require apps to remember the session

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

jdsmith: for earlier comment I had skipped ahead --
... I have added a comment and would like to resolve that bug (26207)
... concensus that addressing the broader set of capabilities is outside scope of EME
... that leaves pre-testing for certain conditions, but don't have the information yet
... should not leave bug open while we wait for results there, if something changes we can re-open

<scribe> ... closed it this morning

paulc: any objections to this?

jdmith: as RESOLVED FIXED, but no changes

paulc: WORKSFORME sounds good
... add a comment as to exactly why this is being resolved that way

Do we need LoadSession?

http://lists.w3.org/Archives/Public/public-html-media/2014Aug/0004.html

paulc: best summary statement
... Joe is asking for feedback, gave some himself
... how should we proceed?

<paulc> joesteele: Looking for Jerry's feedback and feedback from other providers

<paulc> ... Maybe I am wrong but it does not work well for my situation

<paulc> ... I feel this is overkill for the situation

jdsmith: there may be a need in this area to allow for different CDM behavior, know that is not popular
... right now loadSession is optional, might not be a value-add for Playready, trying to model this
... feel like it is more natural for persistent licenses to be re-used automatically
... that does not seem like a good fit

ddorwin: from Jerry and Joe would like the use cases or app models where persistent licenses are used
... not clear why persistent licenses are used in all cases
... would like to know the different models
... people have said they would like to re-use on createSession -- would like that to be more concrete

joesteele: will provide the links to my earlier comments on this

ddorwin: documentation would be good

EME Use cases wiki

<paulc> https://www.w3.org/wiki/HTML/Media_Task_Force/EME_Use_Cases

<paulc> - joesteele: the Key Release section will change still

joesteele: The Key Release section has not changed because it is dependant on the loadSession discussion

<paulc> - paulc: maybe send an email making the connection between the bugs and the use cases to draw interest from the group

paulc: we also discussed linking the bugs back to the use cases

joesteele: that has not been done yet either

<paulc> Notes from Joe and Paul are from Jul 29 minutes: http://www.w3.org/2014/07/29-html-media-minutes.html#item14

paulc: so those items are pending

Timing, Scribe, Chair for next meeting

paulc: two outstanding MSE bugs -- asked editors for feedback
... would like to put test suite on the next agenda
... then follow with EME status
... still waiting for information from poll on the test suite, need information for CR

ddorwin: FYI -- I will fix a few bugs we discussed today and then start the move to ReSpec
... spec may look ugly for awhile

paulc: before or after heartbeat?

ddorwin: after

paulc: sent a note that suggested we update the latest page as it is getting stale
... David will do this first. Couple of bugs pending this reorg right?

ddorwin: yes

paulc: any other business?

Adjourn

paulc: thanks!

- DRAFT -

HTML Media Task Force Teleconference

12 Aug 2014

Attendees

Contents