14:54:46 <RRSAgent> RRSAgent has joined #webrtc
14:54:46 <RRSAgent> logging to https://www.w3.org/2021/10/28-webrtc-irc
14:54:48 <Zakim> Zakim has joined #webrtc
14:55:31 <fluffy> fluffy has joined #webrtc
14:57:15 <kajihata> kajihata has joined #webrtc
14:59:11 <eehakkin> eehakkin has joined #webrtc
14:59:29 <jib> jib has joined #webrtc
15:00:43 <takio> takio has joined #webrtc
15:03:26 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/TPAC_2021#WebRTC_WG_Meeting
15:03:32 <dom> Chair: Bernard, Jan-Ivar, harald
15:04:02 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2021Oct/att-0018/WEBRTCWG-10-28-2021.pdf
15:04:16 <dom> scribe+
15:04:39 <Louay_> Louay_ has joined #webrtc
15:05:28 <eric> eric has joined #webrtc
15:05:40 <dom> Present+ Dom, Bernard, BrianBaldino, Cullen, EeroHakkinen, EladAlon, FlorentCastelli, HiroshiKajihata, JakeHolland, JanIvarBruaroey, LouayBassbouss, TakioYamoka, TimPanton, TovePetersson, YouennFablet, ZoltanKis
15:05:43 <Louay_> Present+ Louay_Bassbouss
15:06:02 <dom> Present+ HaraldAlvestrand
15:06:10 <dom> Topic: State of the WebRTC WG
15:06:25 <dom> [slide 10]
15:06:33 <dom> Present+ RandellJesup
15:06:41 <dom> Harald: We'll review what we're chartered to do
15:06:51 <dom> ... What we've been doing (not in too many details)
15:06:58 <dom> ... and what we need to do going forward
15:07:00 <dom> [slide 11]
15:07:15 <dom> ... We last rechartered in October 2020, with a focus on forward looking changes
15:07:35 <dom> ... there is also a bunch of document that needs to get published and maintained - 15 listed in the charter
15:07:51 <dom> ... the charter pushes us toward starting from use cases for new work
15:07:59 <dom> ... and look at direct control (inspired by ORTC)
15:08:02 <dom> [slide 12]
15:08:12 <dom> ... What we have done within our chartered work:
15:08:16 <vr000m> vr000m has joined #webrtc
15:08:20 <dom> ... We have got WebRTC 1.0 to Rec!!!!
15:08:32 <dom> ... we're still working on bringing mediacapture-main to Rec
15:08:44 <dom> ... and have 13 documents that are more or less dormant
15:08:47 <vr000m> Hi, could someone let me in to the Hangout call?
15:10:03 <dom> ... use cases need more work, incl clarity on what they are and need
15:10:24 <dom> ... we're also doing maintenance work on webrtc based on the bugs found through experience, with fixes coming in
15:10:38 <dom> ... in some cases, it's a matter of aligning the spec with existing implementations
15:10:43 <dom> [slide 13]
15:11:02 <dom> ... what we've done beyond what the charter envisioned - a number of extensions have been proposed
15:11:17 <dom> ... they unlock some use cases, but not necessarily the ones we've listed
15:11:31 <dom> ... some of these proposals have been highly controversial, some a bit, and some not at all
15:11:41 <dom> [slide 14]
15:11:42 <vr000m> @dom no a different URL. joining the new one, thanks!
15:11:57 <dom> Present+ VarunSingh
15:12:30 <dom> Harald: one of my worries is that a lot of the discussions are happening between roughly 3 people, all representing browser vendors
15:12:45 <dom> ... the mailing list is mostly used for announcements, and the debates happen mostly in github issues
15:13:02 <dom> ... we've managed to pull feedback from other groups (which is good), but failed to attract input from our own group (bad)
15:13:25 <dom> ... may be too hard to follow, or not directly relevant to most participants - but that's worrisome in the quality of consensus we're obtaining
15:13:27 <dom> [slide 15]
15:14:06 <dom> ... The way we imagined the work would happen: a need emerges, is distilled in a scenario in the use case doc, we build an extension to match, and get consensus on it
15:14:09 <dom> [slide 16]
15:14:25 <dom> ... but in practice, the needs tend to emerge "in house"
15:14:32 <dom> ... the solution gets developed also in house
15:14:40 <dom> ... which is then brought to the WG
15:14:54 <dom> ... and then we're struggling in finding consensus, esp fast consensus
15:15:02 <dom> ... e.g. my 11 months journey on breakout box
15:15:16 <dom> ... is an illustration on how we don't want the process to go
15:15:21 <dom> [slide 17]
15:15:29 <dom> ... Another problem is editing resources
15:15:38 <dom> ... The goal of W3C process is to reach Recommendation
15:15:53 <dom> ... that means a spec with consensus, a test suite that exercises that can be tested
15:15:57 <dom> ... and matching implementations
15:16:16 <dom> ... We have a lot of documents that are languishing
15:16:24 <dom> ... they specific interface present (maybe) in some browsers
15:16:44 <dom> ... but we're missing test suites, implementations, people that address bug fixes
15:16:49 <dom> ... that is worrisome
15:17:19 <dom> ... Who need these features? can those that need these features put the time and energy to get the work done?
15:17:29 <dom> ... If nobody shows up, should we abandon the work?
15:18:49 <dom> TimP: in the process you describe we currently use is strongly tied to ability to deploy new browser code
15:19:09 <dom> ... which reinforces the problem you were describing in terms of involvement
15:19:40 <dom> Harald: the only counter-example I can think of is Sergio bringing SVC to Chromium
15:19:56 <dom> ... it shows it's possible to bring code in Chrome without being a Googler
15:20:25 <dom> ... but I agree the risk you describe is real
15:20:52 <dom> Youenn: 13 documents is a lot, but some are with implementations (getDisplayMedia, mediarecorder)
15:20:59 <dom> ... they get updated based on implementation feedback
15:21:15 <dom> ... they're shipped and used, they need to pass the line to go to Rec
15:21:21 <dom> ... what will be the gain to go to Rec?
15:21:37 <dom> ... this may explain the lack of motivation
15:21:42 <dom> ... if we have good enough interop
15:22:06 <dom> Harald: one of my example was on media capture depth
15:22:22 <dom> Bernard: in IETF, we pared down the process because it was too much work with too little benefit
15:22:32 <dom> ... the same may be happening here
15:22:43 <dom> ... due to the different between costs and benefits
15:23:02 <dom> ... but we need to distinguish the ones that are abandoned and not used, vs those that are not pushed forward
15:23:22 <dom> Harald: quite a few are in active use in multiple browsers
15:23:41 <dom> ... but the presence of years old bugs in these specs make me nervous
15:24:23 <dom> Cullen: in the general sense, when the WebRTC effort started, it was seen as a negotiation between implementors and users
15:24:59 <dom> ... but the W3C Process gives a veto to implementors on every thing (esp given that there isn't so many real different implementations)
15:25:39 <dom> ... I'm not saying it didn't work in delivering result, but if it has become a one-sided process, it has led to a one-sided conversation
15:25:59 <dom> ... In terms of the use cases that are needed: we're doing this for developers, but also for end users
15:26:35 <dom> ... every major rtc apps are moving away from the Web because of the poor UX there
15:26:50 <dom> ... the biggest reason being likely camera/microphone selection
15:26:58 <dom> ... we need to look at it holistically
15:27:29 <dom> ... the Web apps would be better in many ways, but we need to go back to look at the pain points
15:29:45 <dom> dom: @@@
15:30:17 <dom> TimP: I don't expect vendors to go back to the Web given all the investments in native
15:30:31 <dom> ... what we should be look at instead is where it isn't used and it should be
15:30:41 <dom> ... my own view is IoT
15:30:56 <dom> ... there are just a few things that needs changing that would make it so much easier
15:31:07 <dom> ... I would love for us solve these issues, mostly around ICE
15:31:31 <dom> Jan-Ivar: Companies have been redirecting from Web to apps beyond WebRTC due to other incentives
15:32:03 <dom> ... and the WebRTC client gives broader reach when the audience doesn't want to install the app of the host
15:32:22 <dom> ... The fact that we're recording and publishing our meetings may play as a disincentive to participation
15:32:34 <dom> Bernard: thanks - we need to move on but we'll need to discuss this more
15:32:39 <dom> Topic: Media Capture Transform
15:32:42 <dom> [slide 19@
15:32:48 <dom> s/19@/19]
15:33:53 <dom> s/@@@/re reaching Rec, we're in a position to assert how much efforts is worth doing in going to the last stage - but we need people to do to assessment; in terms of process - I don't think the W3C process is one-sided, but if it has worked that way in the group, than obviously we need to improve
15:35:34 <dom> [slide 22]
15:38:09 <dom> [scribe missed part of discussion due to connection issue]
15:38:30 <dom> JIB: re audio, one way to move ahead may be to polyfill the API based on audio worklet
15:38:54 <dom> ... re main thread, both proposals can be made to work on the main thread
15:39:27 <dom> youenn: I would say there are 3 proposals, with Jan-Ivar's taking the middle path between the two others
15:39:33 <dom> ... it's difficult to try to solve everything
15:39:51 <dom> ... we really need to improve video transform - that's our P1
15:39:56 <dom> ... if we focus on that, we can go faster
15:40:17 <dom> ... if we're trying to address the problem of audio or main thread, it will only delay getting to a good solution for the biggest issue of video processing
15:40:33 <dom> ... I would leave anything but video processing on the side
15:41:02 <dom> ... the key question is whether to use streams or not - I'm hoping the discussion with the WHATWG Streams editors will give us a good picture of whether Streams is workable
15:41:11 <dom> ... I wouldn't make a decision before we have that discussion
15:41:43 <dom> Bernard: our ongoing work is at the intersection of multiple groups: webcodecs, ml, audio, ...
15:42:00 <dom> ... we don't always understand how these intersections work
15:42:12 <dom> ... e.g. how well would media capture transform would work with ML APIs
15:42:30 <dom> ... that makes it harder to answer the design questions
15:42:38 <dom> ... when in the end, all the APIs need to work together
15:43:22 <dom> Harald: we manage to Stream-based WebRTC Encoded Transform API that was developed at the same time of Web Codecs with a different frame wormat
15:43:26 <dom> s/wor/for/
15:43:34 <dom> ... which is now causing issues
15:43:54 <dom> ... getting interfaces to work together is problematic - cross-participation helps, but it's hard to find people that can do that
15:44:37 <dom> Bernard: so what should be our next steps? we've mentioned the joint meeting on the Streams issues
15:44:41 <dom> ... but about the other aspects?
15:45:19 <dom> Jan-Ivar: the poll only indicated major support for Streams; no clear support for audio or main thread
15:46:12 <dom> Youenn: before picking stream-based, I think we need to have a clearer picture of streams
15:46:27 <dom> ... e.g. Dom asked whether it solves more than issue than it created, which to me is still unclear
15:46:46 <dom> ... a future version of Streams might have these issues solved, which may lead to clear informed answer
15:46:58 <dom> ... hopefully we can have an answer in the upcoming few days or weeks
15:47:35 <dom> Harald: I can wait a few more weeks - but we can decide that we're adopting a stream-based proposal knowing the decision can be revisited if it turns out unworkable
15:47:42 <dom> ... failure is part of life
15:47:53 <dom> ... but if we wait too long, there is no path to success
15:48:13 <dom> Youenn: we can keep making progress in the github issues
15:48:28 <dom> Bernard: my biggest concern with streams is around feedback between stages
15:48:44 <dom> ... stream backpressure doesn't help with encoder rate control
15:48:59 <dom> ... Harald argued we needed to feedback stream, but we haven't worked it out yet
15:49:17 <dom> Youenn: it might be worth filing an issue - not sure if it needs to be streams based
15:50:37 <dom> Jan-Ivar: I feel pretty confident about the upcoming Streams meeting - we're getting positive signals on getting some of the resolutions we want landed ni
15:50:40 <dom> s/ni/in/
15:50:56 <dom> ... In terms of rate control - is it specifically about streams getting in the way?
15:51:04 <dom> bernard: probably just not helping
15:51:25 <dom> jan-ivar: assuming the stream discussions turns out as I expect, how do we move forward with the two other questions?
15:51:59 <dom> Harald: re rate control, my initial design had a stream going the other way for feedback incl rate control
15:52:22 <dom> ... but I abandoned it because it could only be useful if fully specified
15:53:00 <dom> ... I thought we had an open bug on it, but can't find it - will open one
15:53:21 <dom> ... not clear that the backchannel had to be stream-based in retrospect
15:53:36 <dom> TimP: if you look at gstreamer, the backchannel isn't done the same way as the forward channel
15:53:40 <dom> ... it's pub/sub bus
15:54:02 <dom> ... I think the backchannel needs more flexibility that what streams can give you
15:54:25 <dom> Jan-Ivar: one way I would frame the state we're in - we have consensus about exposure in workers, we don't have consensus on main thread
15:54:40 <dom> ... we could proceed by starting with workers-only - exposing on the main thread would be a simple IDL change
15:55:57 <dom> Harald: that's possible; speaking with my Chrome hat, the current API is exposed on the main thread and removing it will take work
15:56:10 <dom> Youenn: can we apply the same logic to focusing on video first?
15:56:49 <dom> Topic: Wrap-up
15:57:07 <dom> Bernard: next steps include meeting with WHATWG
15:57:21 <dom> ... should we include discussion about the use cases at an upcoming interim?
15:57:29 <dom> Harald: more generally, doing triage on our document list
15:59:09 <dom> Dom: how can we unblock the shape discussion on mediacapture transform
15:59:51 <dom> harald: I'm discussing open issues on Jan-Ivar's proposals that is generally growing on me; but need to check broader support from implementation side
16:00:03 <dom> ... I've created a label in media capture extensions to help tracking these
16:00:44 <dom> Bernard: what about the feedback channel discussion?
16:00:51 <dom> Harald: file an issue - I have some thoughts on the topic
16:01:10 <dom> RRSAgent, draft minutes v-slide
16:01:10 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/28-webrtc-minutes.html dom
16:02:05 <dom> RRSAgent, make log public
16:03:21 <dom> Meeting: WebRTC WG TPAC 2021 Meeting
16:03:24 <dom> RRSAgent, draft minutes v-slide
16:03:24 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/28-webrtc-minutes.html dom
16:03:35 <takio> takio has left #webrtc
16:05:10 <dom> dom has left #webrtc
17:26:01 <Zakim> Zakim has left #webrtc