See also: IRC log
<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> 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
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
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
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
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
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
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
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
<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
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
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
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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/thise/this/ Found ScribeNick: plh Inferring Scribes: plh Present: paulc jdsmith joesteele MattWolenetz ddorwin tidoust plh johnsim markw Agenda: https://lists.w3.org/Archives/Public/public-html-media/2016Aug/0047.html Found Date: 16 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/16-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]