14:58:41 RRSAgent has joined #mediawg 14:58:41 logging to https://www.w3.org/2021/12/14-mediawg-irc 14:58:43 Zakim has joined #mediawg 14:58:48 RRSAgent, make logs public 14:58:59 Meeting: Media WG monthly teleconference 14:59:29 Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2021-12-14-Media_Working_Group_Teleconference-agenda.md 15:00:45 alwu has joined #mediawg 15:02:42 scribe+ cpn 15:04:42 Present+ Chris_Needham, Chris_Cunningham, Yuhao_Fu, Francois_Daoust 15:05:08 present+ Alastor_Wu 15:06:37 present+ MFX_Worldwide 15:08:19 scribe+ tidoust 15:08:27 topic: Autoplay Policy API design 15:08:31 Topic: Autoplay Policy Detection 15:08:42 s/Topic: Autoplay Policy Detection// 15:09:21 cpn: Proposal from Jer on the last meeting. We received some feedback from Gary and Tom (BBC colleague), Chris Guttandin, and Frank. 15:10:34 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. 15:11:36 ... 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. 15:11:46 cpn: Do we need that distinction? 15:12:02 ... With an element-specific query, is the answer going to be different from one element to another? 15:12:09 alwu: Yes. 15:12:17 present+ Frank_Liberato 15:13:00 alwu: If the UA implementation only allows play with user activation, then the answer will vary on an element per element basis. 15:14:07 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. 15:14:58 ... 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. 15:15:16 cpn: So next step is to prepare a PR along these lines? 15:15:22 alwu: Yes, that's my plan. 15:15:50 zacharycava has joined #mediawg 15:16:01 ... 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? 15:16:38 tidoust: I have a tool that could find the answer. I'll investigate and report back 15:17:20 cpn: Anne van Kesteren might know as well. 15:17:46 topic: Add a WebCodecs registration for H.263 15:18:02 -> https://github.com/w3c/webcodecs/pull/417 Add a WebCodecs registration for H.263 15:18:38 cpn: Someone developing an open source library and using H.263. They prepared a registration to be added to the WebCodecs codec registry. 15:19:06 ... 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. 15:19:13 ... Any thoughts, questions, concerns? 15:20:49 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. 15:21:36 cpn: That was my main question, really. Can we validate the contents of the document? And are we comfortable with a polyfill approach? 15:21:54 chcunningham: Bernard, do you have an opinion on H.263? 15:23:15 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. 15:24:37 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. 15:24:55 present+ Zachary_Cava 15:25:21 Bernard: For instance, is a public spec required? What is the review process? Can the Working Group say no? 15:26:09 tidoust: We could ask whether we accept external specs, or the group will take responsibility for the spec? 15:26:23 Bernard: What if someone tries to register a proprietary codec? Should we require a public spec? 15:26:37 chcunningham: That could be a minimal bar. 15:27:53 Bernard: Happy to draft share an initial process there. 15:28:42 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. 15:29:41 ... It seems like the second option would be unusual. 15:29:58 tidoust: I note W3C often registers things at IETF. 15:30:11 cpn: Both organizations provide stability guarantees. 15:30:57 chcunningham: I note I remain positive about adopting the document. The repo provides a central place, which is good for learning. 15:31:26 ... If they want to be the maintainer of the spec, do they need to tell us more about themselves? 15:32:10 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 15:32:23 ... or we somehow make the contributor part of the WG, e.g., as invited expert 15:33:11 chcunningham: OK, I guess we can just ask the individual. No problem being listed as an editor. 15:33:42 tidoust: I don't think this is from a large company, so not worried about the IE status 15:34:25 ... 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 15:38:18 chcunningham: Do we introduce a lower bar of entry with the invited expert status? 15:40:13 tidoust: Kind of, but that's usually not a real problem. Patent commitments are for the individual if IE, for the organization if participant. 15:40:48 ... I would separate the decision to adopt the spec (group consensus) with the possibility to invite the individual as IE (team + chairs decision) 15:41:44 Bernard: I note that I got a recent example of a codec spec that was only available for a fee. 15:42:12 ... For normative references in IETF, sometimes having access to the spec is a requirement. 15:43:07 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. 15:43:28 ... Given upcoming holidays season, I may leave that for early next year. 15:44:04 chcunningham: Just to confirm that planned codec registrations are still planned? 15:44:15 tidoust: Yes. I confirm that they will be published on Thursday. 15:44:56 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. 15:45:32 Topic: Upcoming CSS meeting - length units in video-* media features 15:46:00 cpn: Just wanted to mention tomorrow's CSS meeting on length units in "video-" media features 15:46:28 -> https://github.com/w3c/csswg-drafts/issues/5044 length units in video-* media features 15:46:33 Topic: Next meeting 15:46:57 cpn: Planning the next meeting to be a joint meeting with the Second Screen Working Group. Some questions there on capabilities. 15:47:09 chcunningham: That sounds like an important call to get Netflix folks on. 15:47:43 RRSAgent, draft minutes 15:47:43 I have made the request to generate https://www.w3.org/2021/12/14-mediawg-minutes.html tidoust 16:10:06 Chair: Chris 16:10:09 RRSAgent, draft minutes 16:10:09 I have made the request to generate https://www.w3.org/2021/12/14-mediawg-minutes.html tidoust 17:40:58 Zakim has left #mediawg 18:33:03 RRSagent, bye 18:33:03 I see no action items