[Minutes] Media WG Teleconference - 2021-12-14

Hi,

The minutes of today's Media Working Group teleconference are available 
at:
https://www.w3.org/2021/12/14-mediawg-minutes.html

... and copied as raw text below.

Thanks,
Francois

-----
Media WG monthly teleconference
14 December 2021

    [2]Agenda. [3]IRC log.

       [2] 
https://github.com/w3c/media-wg/blob/main/meetings/2021-12-14-Media_Working_Group_Teleconference-agenda.md
       [3] https://www.w3.org/2021/12/14-mediawg-irc

Attendees

    Present
           Alastor Wu, Bernard Aboba, Chris Cunningham, Chris
           Needham, Francois Daoust, Frank Liberato, MFX Worldwide,
           Yuhao Fu, Zachary Cava

    Chair
           Chris

    Scribe
           cpn, tidoust

Contents

     1. [4]Autoplay Policy API design
     2. [5]Add a WebCodecs registration for H.263
     3. [6]Upcoming CSS meeting - length units in video-* media
        features
     4. [7]Next meeting

Meeting minutes

   Autoplay Policy API design

    cpn: Proposal from Jer on the last meeting. We received some
    feedback from Gary and Tom (BBC colleague), Chris Guttandin,
    and Frank.

    alwu: Alternate API design is about adding a new function to
    Navigator, to which you can give an element and it will return
    the autoplay policy for that element. No need to piggy-back the
    API, that's great. We received mostly positive feedback.
    … So on to navigator.getAutoplayPolicy which takes a
    constructor or a specific media element. If you pass it a
    constructor, it returns the generic autoplay policy. If you
    pass it a specific element, it gives you a more specific
    response for that particular element.

    cpn: Do we need that distinction?
    … With an element-specific query, is the answer going to be
    different from one element to another?

    alwu: Yes.

    alwu: If the UA implementation only allows play with user
    activation, then the answer will vary on an element per element
    basis.

    Frank: My main concern is how reliable the answer is going to
    be. Chrome will have some async loop in there, and the answer
    may be wrong from time to time. We need to be clear that the
    responses will be stale at any time.
    … I see why synchronous makes a lot of sense from a dev point
    of view. It just makes our life harder and means the response
    may not be completely correct.

    cpn: So next step is to prepare a PR along these lines?

    alwu: Yes, that's my plan.
    … One question. It seems that we don't have a lot of APIs that
    take a constructor as input. I wonder whether we have other
    examples?

    tidoust: I have a tool that could find the answer. I'll
    investigate and report back

    cpn: Anne van Kesteren might know as well.

   Add a WebCodecs registration for H.263

    [8]Add a WebCodecs registration for H.263

       [8] https://github.com/w3c/webcodecs/pull/417

    cpn: Someone developing an open source library and using H.263.
    They prepared a registration to be added to the WebCodecs codec
    registry.
    … My question for the group is whether we're comfortable to
    accept that contribution into the WebCodecs repository. I think
    that we need consensus in the group.
    … Any thoughts, questions, concerns?

    chcunningham: I am supportive. At least conceptually. I cannot
    personally vet the choice of codec strings as not an expert in
    H.263. Chrome is not going to implement H.263 any time soon.
    Probably OK if there are mistakes in there. The individual who
    submits the registration can look after the spec.

    cpn: That was my main question, really. Can we validate the
    contents of the document? And are we comfortable with a
    polyfill approach?

    chcunningham: Bernard, do you have an opinion on H.263?

    Bernard: You need to have a policy about what you accept or not
    in a registry. H.263 is a standardized codec, but there needs
    to be a review process. In the IETF registries, there are
    official reviewers, spec required, call for consensus, etc. No
    comment on H.263 specifically, but it raises questions about
    the registry process.

    cpn: What we have in the draft registry is description of the
    technical requirements: having a codec strings, the different
    sections that need to be present. In terms of process, it's
    simply "file an issue and we evaluate for compliance". Onus is
    on the editors. We could add something which is a bit more
    detailed.

    Bernard: For instance, is a public spec required? What is the
    review process? Can the Working Group say no?

    tidoust: We could ask whether we accept external specs, or the
    group will take responsibility for the spec?

    Bernard: What if someone tries to register a proprietary codec?
    Should we require a public spec?

    chcunningham: That could be a minimal bar.

    Bernard: Happy to draft share an initial process there.

    cpn: Please do, thanks. For H.263, we could adopt it as a
    registry entry with a spec that W3C publishes, with a spec that
    lives outside of W3C, or it could remain out of the registry
    entirely.
    … It seems like the second option would be unusual.

    tidoust: I note W3C often registers things at IETF.

    cpn: Both organizations provide stability guarantees.

    chcunningham: I note I remain positive about adopting the
    document. The repo provides a central place, which is good for
    learning.
    … If they want to be the maintainer of the spec, do they need
    to tell us more about themselves?

    tidoust: If the WG adopts the document, the editor needs to be
    a WG participant. That could be you, and we credit the author
    in acknowledgements
    … or we somehow make the contributor part of the WG, e.g., as
    invited expert

    chcunningham: OK, I guess we can just ask the individual. No
    problem being listed as an editor.

    tidoust: I don't think this is from a large company, so not
    worried about the IE status
    … From a WG perspective, there's no way to scope IE's
    participation to that just spec, so they could contribute to
    all WG discussions

    chcunningham: Do we introduce a lower bar of entry with the
    invited expert status?

    tidoust: Kind of, but that's usually not a real problem. Patent
    commitments are for the individual if IE, for the organization
    if participant.
    … I would separate the decision to adopt the spec (group
    consensus) with the possibility to invite the individual as IE
    (team + chairs decision)

    Bernard: I note that I got a recent example of a codec spec
    that was only available for a fee.
    … For normative references in IETF, sometimes having access to
    the spec is a requirement.

    cpn: Two action items on me: 1. Call for consensus on the
    adoption of the document and 2. Check on IE status with Jer and
    Francois.
    … Given upcoming holidays season, I may leave that for early
    next year.

    chcunningham: Just to confirm that planned codec registrations
    are still planned?

    tidoust: Yes. I confirm that they will be published on
    Thursday.

    cpn: Only remaining thing here is switching the actual registry
    to the Registry track. No urgency, but it would be good to do
    that at some point.

   Upcoming CSS meeting - length units in video-* media features

    cpn: Just wanted to mention tomorrow's CSS meeting on length
    units in "video-" media features

    [9]length units in video-* media features

       [9] https://github.com/w3c/csswg-drafts/issues/5044

   Next meeting

    cpn: Planning the next meeting to be a joint meeting with the
    Second Screen Working Group. Some questions there on
    capabilities.

    chcunningham: That sounds like an important call to get Netflix
    folks on.

Received on Tuesday, 14 December 2021 16:26:10 UTC