Meeting minutes
Agenda bashing
cpn: Fairly light agenda for today, centered on Autoplay Policy Detection. We may also want to discuss H.263 WebCodecs registration. Any other topics?
Autoplay Policy Detection
cpn: Thank you for the editorial work, Alastor. Good progress towards convergence on the API shape.
alwu: The current API shape is that we expose some method on Navigator: getAutoplayPolicy.
https://
alwu: Different overloads. You may give it an enum value so that the browser tells you the general policy for the type of media content requested.
… The second type of calls is when you give the method an element, in which case the browser returns a more specific answer for that particular element.
cpn: Either instance of HTMLElement or AudioContext. Or general policy based on the enum.
cpn: Initial idea was to pass a constructor, but I think we established in the GitHub discussion that this isn't actually possible.
… Next question is whether we're ready to move to next step on the Rec track, meaning publication as First Public Working Draft?
… Once there are implementations and tests, we can then take things further.
… So: publication as First Public Working Draft, and then shortly after that initiate horizontal reviews.
… An initial TAG review was done. But there are other reviews that we need to perform.
Frank: From a Chrome perspective, that looks good. Regarding the language in the "Querying by element" section, we'll want to clarify that the answer may be wrong once in a while due to the call being sync and our implementation building the answer in an async way.
cpn: That relates to my question on how long do we expect the answer to be correct?
Frank: That's a good question. I'm a bit concerned that this is going to be implementation specific.
cpn: I can capture this in a GitHub issue as something to look back into once we have more implementation experience.
… From a process perspective, next step is that I'll issue a Call for Consensus for publication of the Autoplay Policy Detection specification as First Public Working Draft.
… Then horizontal reviews. Whether we need another TAG review, I don't know.
WebCodecs H.263 registration
cpn: There's been some follow-up from the contributor. This is for their own JS-based implementation.
… I think that what we've discussed so far is whether we can find some outside expertise to review the registration.
… I haven't done that yet. Thanks for suggestions that you provided.
… I'd like to move ahead and run the call for consensus on adding the H.263 registration on the basis that we get positive feedback on the review.
tidoust: Two questions in one. The Media WG may add a line to the registry that targets an external document. Then there is the question on whether the Media WG adopts and publishes the document.
Bernard: Also wondering about implementation evidence?
tidoust: No specific process requirements on implementations for registries.
cpn: I'll separate the two questions in the CfC.
Bernard: I think we should focus on what he's willing to do. I don't think we want to adjust the API to better support H.263.
cpn: Issue suggests he's using FFMPEG, which does not support "++".
Bernard: So that's essentially "+", which is fine.
AOB
Bernard: At some point, I'd like to talk about Media Capabilities in its relation with WebRTC. I've done some testing. What comes out of Media Capabilities (scalability modes) does not match what's supported in WebRTC.
chcunningham: That should not happen, at least that is not intentional.
Bernard: I think it advertises what the encoder supports, not what WebRTC supports.
… It's not obvious to me that it is a bug because the spec does not say what it should do.
… In the WebRTC-SVC spec, it is explicit that you should not advertise capabilities that you then cannot support.
chcunningham: That makes sense to me.
Bernard: But it's tricky in practice.
… Because of coupling between parameters width, height, framerate and bitrate.
chcunningham: OK, then Media Capabilities could give a more constrained answer.
Bernard: Where does that kind of things get discussed? It's a joined group discussion. On the WebRTC WG agenda for next call.
cpn: Good thing that you're attending both WebRTC and Media WG calls, Bernard. If there are things we can do to help facilitate joint discussions, let us know.
Bernard: Yes, that would be useful. There are questions coming up, e.g. on color spaces and machine learning. Only interaction is often TPAC and more seems needed.
cpn: On this one, the next WebRTC WG call seems like the right next step. If there are cross-group discussions needed, let's not wait until October to have those conversations.
TPAC 2022 plans
cpn: One final thing from me. There is now a survey from W3C staff to assess groups appetite for in-person meetings at TPAC 2022 in Vancouver.
… Last time I mentioned this, I didn't see any indication that people could say whether an in-person meeting would be possible. I'll send an email to the WG to get feedback.
… The assumption that I'm having is that we would not plan to meet during TPAC based on feedback from last time.