HTML Media Task Force Teleconference -- 16 Aug 2016

<paulc> Agenda:

<jdsmith> Anyone on the call? I'm on, but don't hear anything.

<paulc> Agenda: https://lists.w3.org/Archives/Public/public-html-media/2016Aug/0047.html

<paulc> plh: should we wait for you?

<scribe> scribeNick: plh

<paulc> https://lists.w3.org/Archives/Public/public-html-media/2016Aug/0047.html

Timelines

PaulC: CfC was Aug 2, we missed it
... we did do a CfC on the features at risk
... and that passed

David: what's the absolute last date?

PaulC: if we have a PR by September 31, I think we'll be ok
... otherwise we'll have to figure what's the Director will do

MSE editorial issues

Paul: what's the next step?

Matt: #99, I have comments from Jerry
... minor comment change, should land today
... the change didn't occur in w3c/html
... so we're taking a fallback solution
... monkeypatching :(

Paul: I pinged Travis yesterday but didn't see a response

Matt: #104, that's PR #146 and needs review

Jerry: I'll do that today

Matt: I don't think those are substantial changes

<paulc> Status on #99 - PR has been reviewed and Matt will implement this today

Matt: Matt: we're already async

PaulC: #74?

Plh: end of next week

<paulc> #74 does NOT block our prep of a draft PR for MSE

MSE recent issues

Matt: #124 gets to some edge cases

<paulc> https://github.com/w3c/media-source/issues/124

Matt: it matters when playback reaches the end
... rendering the whole frame beyond the duration
... Chrome has a bug
... Mozilla doesn't support partial frame rendering

Jerry: not sure what the current behavior is but our preference is not to do partial frame rendering
... so behave like if we don't

Matt: ok, I'll update the spec and we'll process the Chrome bug

Paul: I don't think it's substantive
... but I'll highlight the change in the CfC

Jerry: is it going to break some sites?

Matt: hard to tell
... if we disallow the increase of time

Paul: ok, Matt will produce a PR
... this is a V1

Matt: #147, not sure I understand this one yet

<paulc> https://github.com/w3c/media-source/issues/147

Matt: I'll keep looking at it

Paul: ok, let's assume we do those things in the next 48 hours. is that possible?

Matt: yes, except for #147

removal of @risks

Matt: those have been done
... Jerry should feel free to double check

<paulc> Jerry (and Mark) to review changes for at risk features

Matt: we can revert those changes in v.next btw

MSE test suite

Paul: major concern is the emails from Mozilla
... speaking of bugs in the test suite
... we have outstanding pull requests to fix those

Matt: we need to merge Francois PRs first
... don't know if the changes from Mozilla are getting upstreamed

<jdsmith> https://github.com/w3c/web-platform-tests/pulls?q=is%3Aopen+is%3Apr+label%3Amedia-source

Paul: ok. first is to review and merges Francois PR

<tidoust> [I note https://github.com/w3c/web-platform-tests/pull/3179 probably does not need to be merged anymore since Mozilla merged a similar update]

Paul: then determine if the changes from Mozilla were covered
... then figures out if we need more changes
... would be useful to get a report

<jdsmith> Correction: tidoust has 11 open PRs

<jdsmith> https://github.com/w3c/web-platform-tests/pulls?q=is%3Aopen+is%3Apr+label%3Amedia-source+author%3Atidoust

https://github.com/w3c/web-platform-tests/pulls?q=is%3Aopen+is%3Apr+label%3Amedia-source+author%3Aplehegar

Prep for MSE PR CfC

Paul: we need to close the issues and close out the test suite and rerun the tests
... I'm hoping we can have all of the PRs done this week
... we'll need en editor's draft
... that is stable
... I'll start a thread on the editor list

EME Editorial issues

David: we're pretty good
... waiting on plh to do his PR
... on WebIDL, there are some respec issues. worked around that

Paul: Joe is ok with issue 273 so this unblocks 301

David: #211 is going to be done
... by Mark as soon as 301 is done

Paul: ok, so 273, 301, and 211

PlH: I'll do the final issues by end of next week

EME other issues

<paulc> https://github.com/w3c/encrypted-media/issues/288

Paul: for #288, we got proposed text from Wendy

<paulc> Wendy: https://github.com/w3c/encrypted-media/issues/288#issuecomment-239995220

Paul: she seems to be asking for legal text to be added into a technical document
... against the implications of US jurisdictions

Mark: if it's legal, I'll ask our legal folks to look at this

Paul: not sure how I'll get consensus from a legal point of view
... I encourage people to ask legal folks to look at this

Jerry: so if legal is ok, can we do the change?

Paul: not sure

Mark: it's pretty unlikely we'll accept the change

Paul: Wendy didn't say that she is ready to raise a formal objection yet
... she is asking for a change

<paulc> https://github.com/w3c/encrypted-media/issues/284

Paul: #284 needs to be triaged
... whether this is vnext or v1

<paulc> https://github.com/w3c/encrypted-media/issues/304

Paul: #304 is asking for a normative change that would make it a requirement to turn off EME by default and turning it on would require a prompt to the user
... there is a text along these lines but not mandatory
... and he wants it to be normative and mandatory
... he wants its issue to be treated separately
... again, I need editors to look at this
... we already know that this would be a FO if we reject the proposed change

EME features @risks

Paul: 'The "persistent-usage-record" session type and the related MediaKeySession destroyed algorithm."
... what's the status here?

David: I think there is still confusion
... and whether we have conforming implementations
... which I don't think is the case

<paulc> https://github.com/w3c/encrypted-media/issues/85

David: some work would be needed to increase interop on this feature, so vnext imho

Mark: we don't have multiple implementations
... Edge does it
... depends on how much progress implementations will make

Paul: I heard we need to give this a little more time
... 'Setting the media element's readyState value based on key availability in the Queue a "waitingforkey" Event and Attempt to Resume Playback If Necessary algorithms.'

David: don't have an issue for it, just waiting to avoid going back to CR if we need to remove it
... don't think we have tests
... and we need some

<paulc> We need tests for the 2nd at risk feature: Setting the media element's readyState value based on key availability in the Queue a "waitingforkey" Event and Attempt to Resume Playback If Necessary algorithms.

Paul: ... 'Support for insecure contexts, including the Are insecure contexts allowed? algorithm and steps that call it.'

David: was removed a few weeks ago

<paulc> 3rd at risk feature was already removed: Support for insecure contexts, including the Are insecure contexts allowed? algorithm and steps that call it.

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

EME test suite

Paul: seems we didn't make much progress last week

Mark: we keep working at it, so ongoing

Paul: do we have a multi-DRM strategy?

Mark: yes. we have some servers

Paul: send a summary if you manage to make progress in next 48 hours

Mark: sure, and we welcome help to migrate the clear key tests

AOB

Paul: thanks to the editors

<joesteele> +1 to that — thanks to the editors

Paul: I'll evaluate whether we need to have an other meeting depending on progress

- DRAFT -

HTML Media Task Force Teleconference

16 Aug 2016

Attendees

Contents