- From: Francois Daoust <fd@w3.org>
- Date: Tue, 13 Apr 2021 15:27:21 +0000
- To: "public-media-wg@w3.org" <public-media-wg@w3.org>
Hi all,
The minutes of today's Media WG call are available at:
https://www.w3.org/2021/04/13-mediawg-minutes.html
... and copied as raw text below.
Please look at pending proposals to update the draft charter in the next
few days, and comment as needed (or get back to me):
https://github.com/w3c/charter-media-wg/issues
Thanks,
Francois.
-----
Media WG Teleconference
13 April 2021
[2]Agenda. [3]IRC log.
[2]
https://github.com/w3c/media-wg/blob/main/meetings/2021-04-13-Media_Working_Group_Teleconference-agenda.md
[3] https://www.w3.org/2021/04/13-mediawg-irc
Attendees
Present
Chris Cunningham, Chris Needham, Francois Beaufort,
Francois Daoust, Greg Freedman, Jer Noble, Joey Parrish,
Mark Watson, Matt Wolenetz, Mounir Lamouri, Peng Liu,
Tommy Steimel, Yoav Weiss
Regrets
-
Chair
Jer
Scribe
cpn
Contents
1. [4]Web Codecs FPWD
2. [5]New Media WG Charter
3. [6]Default repo branch naming
4. [7]New actions in Media Session
5. [8]Publishing FPWDs
Meeting minutes
Web Codecs FPWD
Francois: Web Codecs has been officially migrated to the Media
WG, and we've published as FPWD
… This has triggered a call for exclusion of essential claims
… Three documents: Web Codecs spec, Registry, and AVC
registration
… They'll become WG notes. If the process includes a better
process for registries, we can adopt that
… Plan is to keep the registration non-normative
ChrisC: Thank you Francois for guiding us through the process
Francois: Next step is to automate publication to /TR
… Same as we've done with Media Capabilities and other specs
… It needs some updates on the boilerplate, which should be
done soon
ChrisC: On registries, we currently only have an entry for AVC
codec, but we expect other to be added such as VP9, AV1
New Media WG Charter
Francois: As part of rechartering, I ran horizontal reviews on
the draft charter, per usual process
… Three issues were raised. A couple are privacy related
against the current draft charter
… Want to resolve them in a way that satisfies everyone, the WG
and the privacy folks
… The first is #16, clarifying fingerprinting text
[9]Issue #16: clarify fingerprinting text; perhaps bring
sec/priv text into alignment with template
[9] https://github.com/w3c/charter-media-wg/issues/16
[10]Related PR #22
[10] https://github.com/w3c/charter-media-wg/pull/22
Francois: There have been updates to the charter text, PR #22
… I want to make sure you're ok with that text
… It's easier to change now than when we run the call for
review of the draft charter
… The privacy folks are worried about the capabilities that the
media specs expose, so they'd like to strengthen the wording in
the charter, so that mitigation strategies will appear in the
specs alongside the privacy issues
… Any comments?
ChrisC: The text looks good initially, would like to review
later this week
[11]Issue #19: How to gatekeep the EME "API to find existing
sessions"?
[11] https://github.com/w3c/charter-media-wg/issues/19
Francois: Next is #19, on finding existing sessions in EME.
Joey responded, to clarify intent
… I don't think it affects the draft charter. I can close the
loop with Sam on that
[12]capability negotiation, big picture
[12] https://github.com/w3c/charter-media-wg/issues/20
Francois: The last #20 is capability negotiation. I'm trying to
understand what the privacy folks want to see in the charter,
and in the specs themselves
… They'd like the group to document architectural alternatives,
to achieve the same thing
… I'm not clear what those could be. There are different
granualities per spec. For MC API it could be for each
individual capability
… There's suggested text in the issue. I'd like your feedback
ChrisC: I discussed with Sam the MC API issue that he raised
… He'd prefer a design where you request N capabilities and the
UA reports which one it likes best
… We mention it in passing in the explainer, could write more
… This is a late stage privacy review. MC API is widely
implemented and used. We should incorporate changes and
improvements where we have an opportunity
… We don't have an opportunity to make a large breaking change
at this stage
Francois: Sam would say it can't be too late, as it's going
through horizontal review
… I'm not surprised we get issues raised from privacy folks,
that's to be expected
… This is why WebRTC have added to MC API, push it to the Media
WG
… So a balance needs to be found
ChrisC: Are we being asked to add sections to the spec itself?
Francois: Not necessarily in the spec. The group has the choice
of where to document alternatives, but Sam would like to see
alternatives discussed and part of the exchange we have with
privacy folks
… I don't disagree it may be too late
ChrisC: I'm happy to continue talking with him about it, and
document the alternative proposals
… Web Codecs will have an interesting discussion around
privacy. It's low level, not clear whether an alternative can
be suggested. We'll need to work with Sam to understand how to
address on a per spec basis
Francois: From a draft charter perspective, what I'm interested
in is whether the group is fine to include Sam's suggestion, or
propose something else?
… The goal is to find a suitable solution, so that we don't
have issues when we send an official call for review
Matt: I agree that documentation of discussion around these
points is a good thing to have. There's a history in MSE of
doing this in F2F and in GitHub issues
… To what extent would this be done in the specs. Formal
process for doing this? With respect to the idea of any
capability that an app wants the UA to provide, simply having
the UA to select a preferred option from a large set ... that
form of API could be gamed easily by changing inputs slightly
Jer: One of the fingerprinting mitigation strategies was rate
limiting. You could imagine hitting a rate limit quickly for an
individual query API like MC. A group based query would allow
you to not hit the rate limit so quickly
… So rate limiting would be more effective in the latter case,
and still deal with the ability to change inputs slightly
… AIUI, we're not being asked to change the design, more
document alternatives
Francois: Documenting alternatives helps with making the
choice, but here we've already chosen
… In the MSE case, Sam is looking at new features, not the
existing W3C rec
Matt: The first feature, changeType, relates to capability
detection, so the documentation needed to accommodate these
requests could go with the first draft
ChrisC: I'd like to take a few more days to take a look at the
proposed text
Default repo branch naming
[13]Rename default branch repos to "main"
[13] https://github.com/w3c/media-wg/issues/30
Francois: We're progressively migrating all our specs to use
main instead of master as default branch name
… This affects some of our repos
… It's a small thing to help improve diversity and respect
… I'll implement the branch name change over time. It normally
doesn't break much, you'll have to change the default branch
name locally
Jer: That sounds straightforward
ChrisC: The change went smoothly for Web Codecs. The only
gotcha was needing to update the Makefile, for Travis to
publish from the branch
Francois: One thing that breaks is GitHub Pages, you have to
disable then re-enable before it fixes itself
New actions in Media Session
Tommy: Our concern is that for browsers that haven't
implemented the new actions, we throw an exception. This
requires a try/catch block around the action handler
… It relates to use of an enum in the parameter. How to make it
better for developers? Add an isActionValid() that returns a
yes or no. Open to ideas
Jer: Sounds fimiliar from another spec, where adding to an enum
caused exceptions. Solution was to use DOMString while also
using enum in the spec
… We'll see if we can dig up the exact issue
Mounir: We couldn't use a string in the EME case. You get a
promise if the request succeded
Jer: Might need to change the API to return something, rather
than throw an exception
Yoav: The fact the API throws on unknown input seems not future
compatible. If developers don't try/catch those calls, their
code will break
… The ideal would be to add a feature detection mechanism so
developers know the supported action ahead of time
… Change the API to not throw on unknown values and return a
value to indicate action not taken
… Is this something other APIs are doing?
Matt: What is the expected variety of action types? Could they
be independently named items on the object that could be
detected?
… For the microphone and camera use cases, if there are
multiple how would Media Session know which one?
Jer: For the latter question, Media Session is a simplification
- goal is to give a single playback session. While it's
possible to have multiple sessions, the UA wouldn't necessarily
want to expose that
… Potential future API surface is to choose the camera or
microphone. But we'll have the same problem of exceptions being
thrown. Without some change it's hard to know if the action is
accepted
… If we want to remove exceptions we'd want an alternative to
know what's supported
Tommy: That clarifies things for me
Yoav: In terms of shipping the current new actions, ideally
we'd decouple feature detection from shipping new actions
… What's the breakage risk of shipping with the current API
shape?
Jer: Seems riskier to remove an action. That would break
existing sites. The only break would be new sites, tested in a
single browser, UAs not yet implementing would find those sites
don't work any more
Mounir: IMO, that's bigger than previous actions we added
(stop, skip, etc). I'd expect sites to check for presence of
those methods
… Following Yoav's feedback, I looked at pages using the API.
50/50 split on use of try/catch around setActionHandler()
… Everyone who is launching Media Session today has all actions
implemented, so not the best metric
… Jer, if Chrome were to ship this, would you be concerned
about potential impact?
Jer: I believe Safari has experimental implementation. That
realises the risk here
Mounir: I don't know the difference in risk
… If adding an action becomes a no-op, it would break the
experience
Jer: If a developer could tell if an action was unsupported,
what would they do instead?
Mounir: In the case of the new mute camera and mute microphone
actions, we'd expect them to not use the features
… In Chrome, there'll be UI in PiP. Developers are used to use
PiP for communication use cases, but want the ability to
mute/unmute from PiP
… A site could refuse to use PiP if they don't have ability to
mute/unmute
Matt: Would such an application, doing PiP integration , should
there be a way to pro-actively detect instead of using
exceptions?
Mounir: Not sure of the difference
Jer: I dont' think anyone's arguing not to have feature
detection. Raise an issue on how to do feature detection
without throwing exceptions
… The Media Session API isn't a guarantee about where the UI
will appear, so I worry about introducing a contract we can't
full
… Mounir, can we follow up offline?
Publishing FPWDs
Francois: We have other documents not yet published. People may
be concerned that nothing happened, so why are they still in
the charter?
Matt: For MSE, I definitely want to get canChangeType in from
WICG. We have editors. What are the next steps? It's already
shipped
Francois: There needs to be group resolution to publish
Matt: Should I just ask you, Francois, to start the CfC once I
have upstreamed the text?
Francois: Yes, good plan
MarkW: If you need any help, please let me know
Matt: I'll look at it this week
FrancoisB: I noticed Webkit experimenting with a Media Session
coordinator API, anything to share?
Jer: Not yet, but it will become clear when we do
Matt: Chrome implementation of MSE in Workers is stabilizing,
expect to begin origin trials soon. Invite people to look at
the feature, send comments to the spec issue, sooner than later
… [14]Issue #175 in MSE repo
[14] https://github.com/w3c/media-source/issues/175
Jer: Anything else?
[none]
Jer: Look forward to seeing you at the next meeting
[adjourned]
Minutes manually created (not a transcript), formatted by
[15]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[15] https://w3c.github.io/scribe2/scribedoc.html
Received on Tuesday, 13 April 2021 15:27:25 UTC