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
Add a WebCodecs registration for H.263
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
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.