W3C home > Mailing lists > Public > public-media-wg@w3.org > April 2021

[Minutes] Media Working Group Teleconference - 2021-04-13

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>
Message-Id: <em1761aa1c-275e-4bf2-a544-382b5945c682@tipc>
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

This archive was generated by hypermail 2.4.0 : Tuesday, 13 April 2021 15:27:27 UTC