21:58:08 <RRSAgent> RRSAgent has joined #mediawg
21:58:08 <RRSAgent> logging to https://www.w3.org/2021/11/09-mediawg-irc
21:58:12 <Zakim> Zakim has joined #mediawg
21:59:24 <tidoust> tidoust has joined #mediawg
22:00:58 <tidoust> RRSAgent, draft minutes
22:00:58 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/09-mediawg-minutes.html tidoust
22:01:30 <tidoust> RRSAgent, make logs public
22:01:50 <cyril_> cyril_ has joined #mediawg
22:01:56 <tidoust> Meeting: Media WG Teleconference
22:01:59 <tidoust> Agenda: https://github.com/w3c/media-wg/blob/main/meetings/2021-11-09-Media_Working_Group_Teleconference-agenda.md
22:02:03 <tidoust> Chair: Chris, Jer
22:02:45 <markw> markw has joined #mediawg
22:02:45 <tidoust> Present+ Francois_Daoust, Alastor_Wu, Chris_Needham, Cyril_Concolato, Eric_Carlson, Jer_Noble, Mark_Watson, Matt_Wolenetz, Peng_Liu,
22:02:55 <tidoust> present+ Greg_Freedman
22:03:22 <tidoust> present+ Thomas_Guilbert
22:04:17 <tidoust> present+ Jean-Yves_Avenard
22:04:43 <peng> peng has joined #mediawg
22:04:51 <tidoust> present+ Gary_Katsevman, Chris_Cunningham
22:05:34 <Cyril__> Cyril__ has joined #Mediawg
22:06:45 <cyril___> cyril___ has joined #mediawg
22:06:54 <jernoble> jernoble has joined #mediawg
22:07:14 <chcunningham> chcunningham has joined #mediawg
22:07:17 <tidoust> scribe: chcunningham
22:07:26 <cpn> scribe+ cpn
22:07:49 <cpn> Topic: requestVideoFrameCallback
22:08:19 <tidoust> -> Moving video.requestVideoFrameCallback spec to media WG https://github.com/w3c/media-wg/issues/34
22:08:24 <chcunningham> tguilbert: current state is that rVFC is shipped in chrome
22:08:37 <chcunningham> ... get a callback next time video frame is presented to compositor.
22:08:50 <chcunningham> ... adds metadata about that frame that is otherwise unavailable. including rtc things
22:09:09 <chcunningham> ... can be used for measuring glass-to-glass latency
22:09:31 <chcunningham> ... can be used to get callbacks at rate of video frame rate
22:09:33 <hober> present+
22:09:43 <chcunningham> ... no other browsers implemented yet. Safari asked a few questions
22:10:08 <chcunningham> ... up next: considering adding an extra parameter to get the actual VideoFrame (webcodecs interface)
22:10:46 <chcunningham> cpn: seen some suggestion from html folks that this should move to html
22:11:19 <jernoble> q+
22:11:28 <tidoust> ack jernoble
22:12:12 <chcunningham> 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
22:12:52 <chcunningham> cpn: would it be acceptable for html to reference webcodecs?
22:12:57 <chcunningham> tguilbert: unclear
22:13:35 <chcunningham> tguilbert: getting the frame that was painted adds feature not currently feasible with WebCodecs
22:14:08 <chcunningham> ... 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
22:14:43 <MattWolenetz> q+ to say some clarification on a rVFC use-case
22:15:09 <chcunningham> 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?
22:16:19 <chcunningham> tguilbert: no way to address these races w/ WebCodecs without synchronizing multiple threads
22:16:31 <chcunningham> ... happy to follow up on these technical details
22:17:14 <chcunningham> cpn: currently not in wg, IIUC we would need to recharter to take this on
22:17:37 <chcunningham> ... option open to us. should we run a cfc on the venue?
22:18:08 <chcunningham> tguilbert: youenn initially asked this, said he would be fine to move to html
22:18:09 <eric> eric has joined #mediawg
22:18:10 <tidoust> ack MattWolenetz
22:18:10 <Zakim> MattWolenetz, you wanted to say some clarification on a rVFC use-case
22:19:38 <cpn> chcunningham: This API, were it extended, it would give you the metadata it's describing
22:21:08 <cpn> ... What are the practical implications?
22:21:35 <cpn> cpn: WG provides a venue for discussion. HTML you'd work with the editors there to integrate the spec
22:22:23 <cpn> chcunningham: I'm happy to move to HTML, seems straightforward from a process standpoint
22:22:54 <chcunningham> cpn: can record that as proposed resolution
22:23:13 <chcunningham> ... give folks offline chance to weigh in
22:23:38 <gregwf> gregwf has joined #mediawg
22:23:39 <chcunningham> ... no formal steps from w3c pov since this isn't yet in WG
22:24:35 <chcunningham> RESOLUTION: lets move this to HTML wg
22:25:08 <cpn> Topic: Autoplay Policy Detection
22:25:36 <chcunningham> cpn: alwu has been putting together a draft. can you summarize current state, open questions?
22:26:32 <chcunningham> alwu: Draft available. API lets devs know if they can play. Underlying decision currently very UA specific (engagment, user gesture, ...)
22:26:50 <chcunningham> ... so this lets devs know whether they should do things like present image vs start video w/ muted audio
22:26:55 <chcunningham> ... several open questions
22:27:11 <cpn> https://alastor0325.github.io/autoplay/
22:27:11 <chcunningham> ... 2 apis. 1 on media element. another on the document.
22:27:33 <chcunningham> alwu: for media element, policy can differ by browser.
22:27:43 <chcunningham> ... for web audio, it is actually spelled out in the spec
22:28:14 <chcunningham> ... previous consenus: web audio folks want to use document api
22:28:25 <chcunningham> ... but my pov, document API is not very clear
22:29:16 <cpn> q?
22:29:41 <chcunningham> ... for ex: stickiness of user gesture may not describe web audio policy (scribe: a little lost)
22:30:34 <chcunningham> ... current API proposal isn't a great fit to accommodate all the various browsers behaviors
22:30:52 <chcunningham> ... one path may be to put a policy attribute on AudioContext
22:32:36 <chcunningham> jer: one path might be to make a new API that consumes <audio> or WebAudio as input and gives answer
22:32:56 <chcunningham> alwu: we're open to it, but not sure how other participants feel
22:33:27 <cpn> chcunningham: From the Chrome point of view, you'd need to talk to Frank, who's not on this call
22:34:16 <jya_> jya_ has joined #mediawg
22:34:28 <chcunningham> gkatsev: from user perspective, an API where you could pass things in seems reasonable
22:34:37 <chcunningham> ... nice consistency
22:35:21 <cpn> chcunningham: In the previous discussions, are you converging on a design, or are there any sticking points?
22:36:01 <chcunningham> alwu: current state on PR. dale reviewed, was feeling positive, but left for PTO
22:37:03 <cpn> chcunningham: Frank is our representative for this topic. So you're now waiting for review feedback from Frank?
22:37:47 <cpn> ... I'll follow up with Frank
22:39:15 <chcunningham> 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
22:39:22 <chcunningham> ... as editor you have that freedom
22:40:29 <cpn> chcunningham: We had similar with Web Codecs. I tried to have conversations in GitHub issues. Chris's suggestion is fine if it helps
22:43:17 <chcunningham> cpn: HTML editors asked whether this should be integrated into HTML.
22:43:43 <chcunningham> ... could be standalone if we pursue what Jer suggested
22:43:48 <jernoble> q?
22:43:50 <jernoble> q+
22:44:04 <chcunningham> ... my view: lets iterate on the spec a bit more first
22:44:57 <chcunningham> wolenetz: another consideration is review audience - which group is best to review
22:45:19 <chcunningham> jernoble: happy to have it media for now, move to html later if needed
22:46:12 <cpn> Topic: Process 2021 and registries
22:46:49 <chcunningham> cpn: w3c process introduced a new "registry" track
22:46:58 <MattWolenetz> q+ to ask about registry and patent policies for externally referenced items (codecs, formats, etc)
22:47:00 <chcunningham> ... are we automatically adopting this process?
22:47:49 <chcunningham> tidoust: I think so. And I think we're allowed to update current registries without changing our charter. But I need to double check.
22:48:20 <chcunningham> cpn: so rather than calling documents "notes", we call the "registry" or "registry entry"
22:48:24 <chcunningham> ... are there additional requirements?
22:48:49 <MattWolenetz> q+ to ask also about "and must not contain any requirements on implementations."
22:48:55 <chcunningham> tidoust: no. process defines exactly what registries should contain, but I  think we're already meeting those requirements
22:50:05 <chcunningham> cpn: so for WebCodecs registry, should be straightforward. Just changing the title? Are there other editorial tasks?
22:50:39 <chcunningham> tidoust: should be just a handful of minor edits to the document
22:50:42 <tidoust> https://www.w3.org/2021/Process-20211102/#switching-tracks
22:50:43 <MattWolenetz> q+ 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.
22:51:32 <chcunningham> cpn: is there an option to continue w/ notes? or are we expected to switch tracks?
22:52:08 <chcunningham> tidoust: no strict expectation. idea is transition should make our lives easier.
22:52:35 <tidoust> q- jernoble
22:52:38 <tidoust> ack MattWolenetz
22:52:38 <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
22:52:41 <Zakim> ... 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
22:52:41 <Zakim> ... ISOBMFF vs MSE WebM etc.
22:52:42 <chcunningham> wolenetz: a few questions
22:52:58 <chcunningham> ... 1. what are the patent requirements for new registry vs current notes?
22:53:23 <chcunningham> ... I read that the new registry documents are still non normative
22:53:59 <chcunningham> ... 2. confused about how registry avoids imposing requirements on implementations
22:54:51 <chcunningham> tidoust: re: 1, registries have no impact on patent policy
22:55:23 <chcunningham> ... re: 2, I don't see any requirements in MSE registry. is there one?
22:56:09 <chcunningham> ... idea is that registry document itself should not have any normative requirements
22:56:40 <chcunningham> wolenetz: we see registry mentions requirements for registration entries. is that a requirement
22:56:54 <chcunningham> tidoust: no. that's not a requirement on implementation, just on registration
22:58:17 <chcunningham> wolenetz: registrations are currently in separate documents (e.g. webm byte stream). is this ok w/ new process?
22:58:29 <MattWolenetz> q-
22:58:42 <chcunningham> tidoust: yes, no need to change those documents. the new process is mostly about the registry table and adding things to registry
22:59:33 <chcunningham> cpn: is there any additional work to publish things that are already published?
23:00:02 <chcunningham> tidoust: good point. suggest that we start w/ WebCodecs since we haven't published that one yet.
23:00:27 <cpn> chcunningham: I don't object, but haven't looked at it closely
23:01:18 <cpn> ... I expect to be ready to run the CfC later this week
23:02:12 <chcunningham> cpn: wrapping up, next call is on 14th of December
23:02:17 <chcunningham> ... thanks!
23:02:46 <cpn> rrsagent, draft minutes
23:02:46 <RRSAgent> I have made the request to generate https://www.w3.org/2021/11/09-mediawg-minutes.html cpn
23:02:57 <cpn> rrsagent, make log public
23:04:51 <chcunningham_> chcunningham_ has joined #mediawg