Meeting minutes
requestVideoFrameCallback
<tidoust> Moving video.requestVideoFrameCallback spec to media WG
tguilbert: current state is that rVFC is shipped in chrome
… get a callback next time video frame is presented to compositor.
… adds metadata about that frame that is otherwise unavailable. including rtc things
… can be used for measuring glass-to-glass latency
… can be used to get callbacks at rate of video frame rate
… no other browsers implemented yet. Safari asked a few questions
… up next: considering adding an extra parameter to get the actual VideoFrame (webcodecs interface)
cpn: seen some suggestion from html folks that this should move to html
jer: what are the use cases for emitting a WebCodecs frame? beyond that: not seeing anything that media wg must own here, unless we take over all of media element from html
cpn: would it be acceptable for html to reference webcodecs?
tguilbert: unclear
tguilbert: getting the frame that was painted adds feature not currently feasible with WebCodecs
… can presently construct VideoFrame(<video>), but this affords means to be confident that the frame they have metadata for is the frame they're constructing
jer: could we spec webcodecs to say that if you paint during this run loop that its syncronized w/ what you might get from rVFC?
tguilbert: no way to address these races w/ WebCodecs without synchronizing multiple threads
… happy to follow up on these technical details
cpn: currently not in wg, IIUC we would need to recharter to take this on
… option open to us. should we run a cfc on the venue?
tguilbert: youenn initially asked this, said he would be fine to move to html
<Zakim> MattWolenetz, you wanted to say some clarification on a rVFC use-case
chcunningham: This API, were it extended, it would give you the metadata it's describing
… What are the practical implications?
cpn: WG provides a venue for discussion. HTML you'd work with the editors there to integrate the spec
chcunningham: I'm happy to move to HTML, seems straightforward from a process standpoint
cpn: can record that as proposed resolution
… give folks offline chance to weigh in
… no formal steps from w3c pov since this isn't yet in WG
RESOLUTION: lets move this to HTML wg
Autoplay Policy Detection
cpn: alwu has been putting together a draft. can you summarize current state, open questions?
alwu: Draft available. API lets devs know if they can play. Underlying decision currently very UA specific (engagment, user gesture, ...)
… so this lets devs know whether they should do things like present image vs start video w/ muted audio
… several open questions
https://
alwu: 2 apis. 1 on media element. another on the document.
alwu: for media element, policy can differ by browser.
… for web audio, it is actually spelled out in the spec
… previous consenus: web audio folks want to use document api
… but my pov, document API is not very clear
… for ex: stickiness of user gesture may not describe web audio policy (scribe: a little lost)
… current API proposal isn't a great fit to accommodate all the various browsers behaviors
… one path may be to put a policy attribute on AudioContext
jer: one path might be to make a new API that consumes <audio> or WebAudio as input and gives answer
alwu: we're open to it, but not sure how other participants feel
chcunningham: From the Chrome point of view, you'd need to talk to Frank, who's not on this call
gkatsev: from user perspective, an API where you could pass things in seems reasonable
… nice consistency
chcunningham: In the previous discussions, are you converging on a design, or are there any sticking points?
alwu: current state on PR. dale reviewed, was feeling positive, but left for PTO
chcunningham: Frank is our representative for this topic. So you're now waiting for review feedback from Frank?
… I'll follow up with Frank
cpn: suggestion on PR - it's quite long with lots of threaded comments. you may try merging it and then taking individual points of feedback
… as editor you have that freedom
chcunningham: We had similar with Web Codecs. I tried to have conversations in GitHub issues. Chris's suggestion is fine if it helps
cpn: HTML editors asked whether this should be integrated into HTML.
… could be standalone if we pursue what Jer suggested
… my view: lets iterate on the spec a bit more first
wolenetz: another consideration is review audience - which group is best to review
jernoble: happy to have it media for now, move to html later if needed
Process 2021 and registries
cpn: w3c process introduced a new "registry" track
… are we automatically adopting this process?
tidoust: I think so. And I think we're allowed to update current registries without changing our charter. But I need to double check.
cpn: so rather than calling documents "notes", we call the "registry" or "registry entry"
… are there additional requirements?
tidoust: no. process defines exactly what registries should contain, but I think we're already meeting those requirements
cpn: so for WebCodecs registry, should be straightforward. Just changing the title? Are there other editorial tasks?
tidoust: should be just a handful of minor edits to the document
<tidoust> https://
cpn: is there an option to continue w/ notes? or are we expected to switch tracks?
tidoust: no strict expectation. idea is transition should make our lives easier.
<Zakim> MattWolenetz, you wanted to ask about registry and patent policies for externally referenced items (codecs, formats, etc) and to ask also about "and must not contain any requirements on implementations." and to ask further about provision of registry data (required in the report or section) -- these are currently distinct notes, e.g. MSE ISOBMFF vs MSE WebM etc.
wolenetz: a few questions
… 1. what are the patent requirements for new registry vs current notes?
… I read that the new registry documents are still non normative
… 2. confused about how registry avoids imposing requirements on implementations
tidoust: re: 1, registries have no impact on patent policy
… re: 2, I don't see any requirements in MSE registry. is there one?
… idea is that registry document itself should not have any normative requirements
wolenetz: we see registry mentions requirements for registration entries. is that a requirement
tidoust: no. that's not a requirement on implementation, just on registration
wolenetz: registrations are currently in separate documents (e.g. webm byte stream). is this ok w/ new process?
tidoust: yes, no need to change those documents. the new process is mostly about the registry table and adding things to registry
cpn: is there any additional work to publish things that are already published?
tidoust: good point. suggest that we start w/ WebCodecs since we haven't published that one yet.
chcunningham: I don't object, but haven't looked at it closely
… I expect to be ready to run the CfC later this week
cpn: wrapping up, next call is on 14th of December
… thanks!