14:54:45 <RRSAgent> RRSAgent has joined #webrtc
14:54:49 <RRSAgent> logging to https://www.w3.org/2023/05/16-webrtc-irc
14:54:49 <Zakim> Zakim has joined #webrtc
14:54:49 <dom> Meeting: WebRTC May 2023 meeting
14:54:49 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/May_16_2023
14:54:49 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2023Apr/att-0001/WEBRTCWG-2023-04-18.pdf
14:54:49 <dom> Chairs: HTA, Jan-Ivar, Bernard
14:54:56 <dom> RRSAgent, make log public
14:58:02 <jtsiskin> jtsiskin has joined #webrtc
15:00:49 <dom> Present+ JaredSiskin, TonnyHerre, FlorentCastelli, TimPanton, HaraldAlvestrand, PeterThatcher, Dom
15:01:27 <dom> Present+ PhilippHancke
15:01:59 <dom> Present+ BernardAboba
15:02:14 <dom> Present+ HenrikBostrom
15:02:57 <dom> Recording is starting
15:02:57 <dom> Recording: https://www.youtube.com/watch?v=XqYcdxWvlVw
15:03:20 <dom> Present+ JanIvarBruaroey
15:03:27 <dom> Present+ YouennFablet
15:03:54 <dom> Present+ SunSHin
15:04:00 <dom> scribe+
15:05:17 <dom> Present+ EladAlon
15:05:28 <dom> Topic: -> https://github.com/w3c/webrtc-nv-use-cases WebRTC-NV Use Cases
15:05:28 <dom> [slide 10]
15:05:47 <dom> TimPanton: we're renaming the "NV" Use Cases into "WebRTC Extended Use Cases"
15:06:02 <dom> ... questions were raised about its usefulness, which I think are worth discussing
15:06:16 <dom> ... looking for guidance and some sort of agreement of possible improvements
15:06:18 <dom> [slide 11]
15:07:02 <dom> -> https://www.rfc-editor.org/rfc/rfc7478 RFC7478: Web Real-Time Communication Use Cases and Requirements
15:07:08 <dom> Present+ CarineBournez
15:08:04 <dom> [slide 12]
15:08:37 <dom> TimP: "NV" is no longer what we're doing, so we renamed it into "WebRTC Extended Use Cases"
15:08:48 <dom> ... different level of consensus across use cases and requirements
15:09:16 <dom> [slide 13]
15:09:55 <dom> [slide 14]
15:11:05 <dom> Bernard: the Machine Learning use case is a weird one - it does raise a question of what use cases are for
15:11:13 <dom> ... in IETF, we distinguish applicability docs from use cases doc
15:11:32 <dom> ... the applicability tells you things the standard doesn't apply for
15:11:56 <dom> ... documenting that something can be done with the tech would not show up in use cases, but in applicability doc
15:12:10 <dom> TimP: worth discussing - will be covered somewhat later
15:12:12 <dom> [slide 15]
15:12:26 <dom> [slide 16]
15:13:04 <dom> [slide 17]
15:13:43 <dom> TimP: WISH is addressing 3.9 and 3.10, and yet the use cases don't have consensus
15:13:47 <dom> [slide 18]
15:14:29 <dom> [slide 19]
15:16:11 <dom> [slide 20]
15:17:47 <dom> [slide 21]
15:18:38 <dom> [slide 22]
15:18:58 <dom> TimP: proposal to rename it is in process
15:19:16 <dom> ... I want to focus on things that we can only or best do with WebRTC - that implies refocusing on P2P
15:19:27 <dom> ... since that's what WebRTC uniquely does
15:19:32 <dom> ... similar to RFC7478 did
15:19:47 <dom> ... we should take out use cases & requirements done by other standards
15:20:06 <dom> ... I think we need to include use cases that don't have new requirements but extend what 7478 describe
15:20:11 <dom> ... e.g. IoT
15:20:42 <dom> ... We should remove use cases or requirements that don't get consensus in a few months - they can always be added back
15:21:04 <dom> ... we should remove use cases that otherwise don't add new requirements
15:21:41 <dom> ... proposed API changes should all include changes to the use case doc if there is no use case for it - otherwise, why are we changing the API?
15:21:48 <dom> ... this also raises the question of the relationship between explainers and the use case doc
15:22:16 <dom> ... we've also been struggling with where the input comes from; happy to use webrtc.nu to that end if that's of interest
15:22:49 <dom> Bernard: good suggestions - my opinion on them
15:23:11 <dom> ... +1 to the important of P2P; this has been a point of confusion in other WGs use cases
15:23:21 <dom> ... Streaming use cases often require P2P operations
15:23:40 <dom> ... All of the major cloud streaming services use WebRTC also for P2P among clients
15:24:10 <dom> ... "met by other standards" - I would like to see wide usage; WebRTC often wins over other standards because of its reach
15:24:28 <dom> ... re removing non-consensus content, +1
15:25:06 <dom> ... A big question: are we implying that we need to give blessing to a use case to make it "valid"?
15:25:44 <dom> TimP: I think for a small developer, getting some level of reassurance that your usage is available by accident or something that can be relied on makes a big difference
15:26:01 <dom> ... as illustrated in the quote in slide 21
15:26:26 <dom> Bernard: but even if you put in the doc - it doesn't create a requirement for browsers to support it properly
15:27:01 <dom> TimP: True, but when somebody comes up with a change to the API that removes the ability to do this, there is no structural way to push back on the change
15:27:35 <dom> Harald: one of the thing that surprises me in this handling of the doc is the handling of consensus
15:27:54 <dom> ... e.g. the "one way use case" - the developers are eager to use it, but the WG is pushing back on consensus
15:28:13 <dom> ... likewise for trusted JS conferencing - everyone is doing it, but we removed it for lack of consensus
15:28:31 <dom> ... I'm worried by the distance between the use case doc and the use cases that I need to support in the real world
15:29:20 <dom> Peter: +1 to getting our use cases in order, +1 to having a place where devleopers can ask for things and get a status on "yes, it is in", "yes, it will be soon", "we can't figure out how"
15:29:33 <dom> TimP: asking for things shouldn't be asking for features
15:29:48 <dom> Jan-Ivar: +1 this needs a clean up
15:29:57 <dom> ... we should be clear about the scope for this - this is only for this WG
15:30:10 <dom> ... NV was supposed to be WebRTC 2.0
15:30:36 <dom> ... instead, we've been unbundling WebRTC in other specs - which make some of these use cases are no longer in scope for our WG
15:30:51 <dom> ... the purpose of this doc is to drive discussions for our WG and in our github
15:30:58 <dom> ... to help decide what's in or out
15:31:58 <dom> Tony: hope we don't silo P2P vs alternatives; there may be use cases for integration with other standards
15:32:14 <dom> Youenn: in terms of scope, +1 to Jan-Ivar - this doc is for the WebRTC WG
15:32:33 <dom> ... +1 to harald that we haven't had a lot of success with it
15:33:00 <dom> ... explainers allow to combine use cases requirements, API and examples - that provide a better structure from my perspective
15:33:05 <dom> Present+ GuidoUrdaneta
15:33:18 <dom> Youenn: maybe we should migrate towards that more than a standalone use cases doc
15:33:28 <dom> TimP: What remains in the use case doc then?
15:33:40 <dom> ... is it a list of pointers to use cases in explainers?
15:34:04 <dom> ... I'll take this to the list - I can put some time on this once I understand what we want to achieve
15:34:17 <dom> ... I want to expand the scope a bit more than just for the WG
15:34:34 <dom> Bernard: I'll try to create PRs (esp removal PRs) for our call next month
15:34:56 <dom> Topic: -> https://github.com/w3c/webrtc-extensions WebRTC Extensions
15:34:56 <dom> Subtopic: Issue #134 / PR #164: Remove JSEP Modifications
15:34:56 <dom> [slide 25]
15:36:48 <dom> Harald: the RFC errata process is not the process to make change to an IETF document; only the IETF process does that
15:37:05 <dom> ... now that the IETF process has turned the crank with the updated draft, we're in a better situation
15:37:09 <dom> [slide 26]
15:37:17 <dom> Subtopic: Issue #158 / PR #167: Requesting a key frame via setParameters
15:37:18 <dom> [slide 26]
15:38:36 <dom> [slide 27]
15:40:42 <dom> Jan-Ivar: I see a requestFrame boolean - a bit odd for a parameter; why not making it a method? maybe it could be a counter?
15:41:06 <dom> Fippo: I didn't want to separate in 2 methods as it creates all kind of issues
15:41:17 <dom> ... e.g. when deactivating a simulcast layer
15:41:49 <dom> Jan-ivar: this could be done with a Promise.all (vs a boolean attribute); but that's bikeshedding
15:42:01 <dom> Fippo: it could cause 2 keyframes to be generated
15:42:12 <dom> TimP: are there situations where setParameters isn't the right place for it?
15:42:24 <dom> ... e.g. in encryption situations
15:42:34 <dom> Fippo: that's why it has been added to encoded transform
15:42:45 <dom> ... but we haven't needed it so far for E2EE
15:43:06 <dom> Harald: I don't like setParameters setting something that isn't a parameter
15:43:23 <dom> ... I would prefer something like sLD
15:43:32 <dom> ... getParameters should return what setParameters set
15:43:41 <dom> ... requestKeyFrame shouldn't be set
15:43:52 <dom> Fippo: maxBitRate is typically unset in the first call of setParameter
15:44:01 <dom> Harald: yes, but once it's set, it's set
15:44:41 <dom> Florent: I understand the need to have it synchronized with setParameters, but I'm not sure we want it in the encoding parameters
15:44:51 <dom> ... we might want to have another member in the structure passed to setParameters
15:45:01 <dom> ... that may also make it work for getParameters
15:45:12 <dom> ... that would require rid validation - not sure that would necessarily be hard to do
15:45:26 <dom> ... the symetric API on a receiver would be very different since we don't have setParameters on receivers
15:45:35 <dom> ... how would we handle this there?
15:45:48 <dom> ... We do have getParameters on receivers
15:46:09 <dom> Fippo: there are use cases for this indeed, e.g. to adjust jitter buffer
15:46:47 <dom> Henrik: I support this use case
15:47:09 <dom> Jan-Ivar: just because the browser isn't doing the right thing doesn't necessarily imply that it needs to be exposed to JS
15:47:17 <dom> ... e.g. it could be done automatically when active is set
15:47:38 <dom> Youenn: in encoded transform, there is sender/receiver API, and a transformer API
15:47:43 <dom> ... they solve different issues
15:47:49 <dom> ... this one is mostly targeting the sender API
15:47:55 <dom> ... it makes sense to have it sync'd with setParameters
15:48:20 <dom> ... the transform API would still remain, right?
15:48:29 <dom> Fippo: it's probably necessary for some E2EE use cases
15:48:59 <dom> Jared: this makes sense to me - two reasons to deactivate the top layer: the person left the call or  or they're switching down
15:49:19 <dom> ... you'll almost always want to send a key frame when deactivating a higher layer, except for the last participant
15:49:35 <dom> ... this may not require an API change for most cases
15:49:44 <dom> Present+ PatrickRockhill
15:49:55 <dom> Peter: I think this is a good approach to solve the real-world need in a simple way
15:50:46 <dom> Resolved: refine PR #167 based on input during the call
15:50:59 <dom> JIB: I'd like to explore whether we need an API at all
15:51:04 <dom> Subtopic: Issue #159: RTCRtpEncodingParameters: scaleResolutionDownTo
15:51:04 <dom> [slide 28]
15:51:49 <dom> [slide 29]
15:53:19 <dom> Peter: what happens if you set the top layer to 360, and the next layer scale down by 2?
15:53:31 <dom> Henrik: if you mix the two, we should throw an exception
15:53:41 <dom> Peter: so either a factor, or a specific value
15:53:48 <dom> ... do we need any specific value?
15:54:05 <dom> Henrik: same as for scaleResolutionBy - forbidding upscaling
15:54:35 <dom> Peter: what happens when the top layer gets dropped?
15:54:48 <dom> Henrik: generally, do the same as SRDB
15:55:13 <dom> Youenn: are there existing workarounds with setting active to false?
15:55:25 <dom> ... may create short glitch
15:55:37 <dom> Henrik: there are workarounds, but I'm not sure how good they are in practice
15:55:52 <dom> Florent: an API like this would be great
15:56:10 <dom> ... there is a problem with orientation (portrait vs landscape) in terms of interpreting that value
15:56:37 <dom> ... also, as Peter asked, what happens if you feed frames that are smaller into layers that expect bigger frames
15:56:56 <dom> ... this may result in several layers with a single lower resolution
15:57:20 <dom> Henrik: should I provide a PR?
15:57:35 <dom> Youenn: I would want to be careful if this adds a lot of complexity
15:57:36 <dom> RESOLVED: Overall support in the direction, but details need to be fleshed out and complexity assessed
15:57:42 <dom> Topic: -> https://github.com/w3c/mediacapture-extensions Media Capture Extensions
15:57:42 <dom> Subtopic: Issue #98 track.getFrameStats() allocates memory, adding to the GC pile
15:57:42 <dom> [slide 30]
15:58:22 <dom> [slide 31]
15:59:09 <dom> [slide 32]
16:00:09 <dom> [slide 33]
16:00:44 <dom> [slide 34]
16:01:04 <dom> [slide 35]
16:01:27 <dom> [slide 36]
16:01:59 <dom> [slide 37]
16:02:31 <dom> [slide 38]
16:03:11 <dom> Youenn: the use case is to get stats, not real-time information
16:03:26 <dom> ... that's why you call an API, you get a result; if you need it 10s later, you call it again
16:03:46 <dom> ... with an interface, you get the object and then the UA starts the processing whether or not you're going to get data from it
16:03:53 <dom> ... that's more appropriate for real-time usage
16:04:08 <dom> ... it seems an ill-fit for the usage implied by the name getStats
16:04:15 <dom> ... so I would go with getStats()
16:04:26 <dom> ... if we need real-time info later, they can come through different APIs
16:04:46 <dom> ... WebRTC has already this pattern: getStats vs requetsVideoframeCallback
16:04:50 <dom> ... so +1 to Proposal A
16:05:13 <dom> Jan-Ivar: unfortunately Paul couldn't join us today
16:05:31 <dom> ... Paul commented on the issue about IPC - the data has to be in the content process eventually
16:05:44 <dom> ... "real-time" is a spectrum (e.g. audio vs graphics)
16:06:06 <dom> ... this WG has fallen into a pattern - it would be useful to compare e.g. with the Media WG; not everything has to be a stat
16:06:26 <dom> ... there are ways to implement this without locking (which the design guide asks not do in a getter)
16:06:40 <dom> ... it all depends on the use case
16:07:01 <dom> ... other WGs with real-time have APIs already - media.currentTime or audioCtx.outputLatency
16:07:33 <dom> Henrik: the use case is to call it at 1Hz
16:07:44 <dom> ... I fail to see use cases to call it more frequently on the main thread
16:08:00 <dom> ... if we're confident we're not getting other metrics, this would be fine
16:08:13 <dom> ... I don't see a lot of ergonomics difference in using await for async
16:08:27 <dom> ... if we do get requests for additional metrics, we would have painted us in a corner
16:08:47 <dom> Youenn: with a promise-based API, it's clear that the results will be gathered asynchronously
16:09:17 <dom> ... with a getter, it requires updating it very frequently or be specific on the update frequency in the spec
16:09:35 <dom> ... the contract is clearer with async
16:09:41 <dom> Jan-Ivar: "we should make decision out of love not out of fear"
16:10:08 <dom> ... i.e. based on the best information we have now, not anticipating all future uses
16:10:38 <dom> Youenn: if we have to design it as a real-time API - would the sync API still be the best choice?
16:10:50 <dom> ... we don't have a real strong use case to guide us
16:11:04 <dom> Jan-Ivar: a variant of Proposal B is to have the attribute directly on the track
16:11:25 <dom> s/tribute/tributes/
16:11:46 <dom> Henrik: it falls down to async vs sync; could you describe what you meant by "lockless"?
16:12:08 <dom> JanIvar: there is code that allows reading values from another process without a lock
16:12:34 <dom> ... Paul would be the expert on this - he has implemented this for AudioContext (not yet landed in Firefox)
16:13:21 <dom> Harald: implementing it as proposal A seems faster and easier
16:13:50 <dom> Henrik: not detecting consensus at this point
16:14:37 <dom> Jan-Ivar: I'm not hearing a lot of interest in our attribute-based API - will discuss internally and get back to the group on this
16:14:41 <dom> Topic: IceController: Prevent removal of candidate pairs w3c/webrtc-extensions#166
16:14:41 <dom> [slide 42]
16:15:35 <dom> Present+ SameerVijaykar
16:16:01 <dom> s/42/41
16:16:04 <dom> [slide 42]
16:16:33 <dom> [slide 43]
16:17:31 <dom> [slide 44]
16:18:54 <dom> [slide 45]
16:19:58 <dom> [slide 46]
16:21:17 <dom> [slide 47]
16:23:27 <dom> Peter: this makes sense as a first item to tackle - although it's more useful once combined with candidate pair selection
16:23:43 <dom> ... I like the "removable" attribute and a setRemoval method
16:24:09 <dom> ... the idleTimeout is interesting, but there may be underlying complexity there; also the ergonomics of max integer value isn't great
16:24:34 <dom> Harald: removing candidates isn't timer driven - candidates are removed when they fail
16:24:56 <dom> ... the end-of-candidate spec'd in ICE would throw away everything when we reach completed
16:25:05 <dom> ... ICE implementations wouldn't fit well with a timeout
16:25:21 <dom> ... because of this, cancelable event is a better fit - it allows the ICE Agent to match the spec'd protocol
16:25:53 <dom> Jan-Ivar: not an ICE expert - but I prefer preventDefault()
16:26:13 <dom> ... still not clear to me what the UA should done once it's prevented though?
16:26:41 <dom> ... ICE Transport doesn't let you look at all the pairs... is this an insight problem into the state of things?
16:26:54 <dom> ... could you talk a bit more on what happens then?
16:27:26 <dom> Sameer: this is a first set of improvements - listing all candidate pairs would be another improvement
16:27:50 <dom> ... allowing to keep candidate alive is to allow to switch to a different pair (with another additional API)
16:28:00 <dom> Peter: in practice, the UA would continue sending checks on that candidate pair
16:28:24 <dom> TimP: but then what happens when it SHOULD remove it - e.g. because it's no longer working; you don't want to prevent THAT default
16:28:59 <dom> Sameer: Removal would be only for redundant pairs; failed candidates would "deleted"
16:29:14 <dom> JanIvar: that seems confusing - maybe it's a bikeshedding issue
16:29:49 <dom> Sameer: the UA can also send cancelable events that aren't systematically cancelable
16:31:17 <dom> Dom: I think it's primarily a bikeshedding issue - important to keep separate "deleted" and "removed", possibly with better names
16:31:25 <dom> Jared: the RFC uses "prune"
16:31:40 <dom> Sameer: my initial proposal had this; we could revert to that
16:31:52 <dom> ... I'm hearing most support for the cancelable approach, happy to write a PR for that
16:32:09 <dom> RESOLVED: Write a PR for a cancelable event approach
16:32:10 <dom> Topic: RtpTransport Follow-up
16:32:11 <dom> [slide 51]
16:32:20 <dom> RRSAgent, draft minutes
16:32:21 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/16-webrtc-minutes.html dom
16:33:00 <dom> s/51/50
16:33:03 <dom> [slide 51]
16:35:02 <dom> TimP: I'm not convinced these are use cases :)
16:35:10 <dom> Peter: fair - this are things that people want to do :)
16:35:13 <dom> [slide 52]
16:35:28 <dom> [slide 53]
16:35:41 <dom> [slide 54]
16:36:10 <dom> [slide 55]
16:36:34 <dom> [slide 56]
16:36:43 <dom> Peter: Depacketization would be built-in in the jitter buffer
16:36:59 <dom> [slide 57]
16:38:03 <dom> [slide 58]
16:38:10 <dom> [slide 59]
16:38:38 <dom> s|2023Apr/att-0001/WEBRTCWG-2023-04-18.pdf|2023May/att-0000/WEBRTCWG-2023-05-16.pdf
16:38:44 <dom> [slide 60]
16:39:10 <dom> RRSAgent, draft minutes
16:39:11 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/16-webrtc-minutes.html dom
16:39:35 <dom> Peter: what use cases would be needed to make this proposal more appealing? are there other type of examples people would like to see?
16:39:43 <dom> ... how much of the gap should be filled by us vs libraries?
16:39:47 <dom> ... would an explainer be useful?
16:39:58 <dom> Bernard: very helpful to see examples, thanks
16:40:19 <dom> ... how would SSRCs be handled? would that be another gap?
16:40:34 <dom> ... in a conference system, keeping track and routing ssrcs is a lot of work
16:40:45 <dom> ... would there be some help to manage this in the API?
16:41:31 <dom> ... Another question is about the depacketizer - would there be a generic video buffer distinct from the packetizer?
16:41:53 <dom> Peter: you're highlighting that an RTP demuxer would also be part of the gap
16:42:07 <dom> ... it is indeed in the gap, it could be provided
16:42:34 <dom> Bernard: it would provide an handler for a particular stream - that would enable handling them differently
16:42:54 <dom> Peter: for the depacketizer, audio and video need different handling since it's so trivial in audio
16:43:19 <dom> Bernard: how would audio/video sync work? I regularly get that question
16:43:27 <dom> Peter: worth adding to the gap indeed - thanks!
16:44:09 <dom> Jan-Ivar: looking at the use cases - it feels like we're abandoning the original WebRTC API with this, which worries me a bit
16:44:20 <dom> ... maybe we should solve time sync on the datachannel e.g. with timecodes
16:44:31 <dom> ... I'm worried that focusing on the new API means we don't solve it with the existing API
16:44:59 <dom> ... likewise, maybe we should look at exposing the same codecs as WebCodecs without having to use this low level API
16:45:28 <dom> ... This API seems to be using events (vs WhatWG Streams) and operating at very low level
16:45:43 <dom> ... I'm not sure all these use cases should or need to be solved with a new API
16:45:57 <dom> ... it feels this may be stepping on WebTransport (although of course WT isn't P2P)
16:46:19 <dom> Peter: WT is not P2P (yet), doesn't have real-time congestion control (yet), doesn't interoperate with RTP endpoints (ever)
16:47:11 <dom> ... in terms of WebCodecs - I designed an alternative with media senders / receivers for the media half of RTPSender/Receiver - it ended up being almost a duplicate of WebCodecs
16:47:42 <dom> ... in terms of abandoning the WebRTC API - that's part of this "filling the gap" approach I'm suggesting
16:48:02 <dom> ... overall, I wouldn't be sad if we end up abandoning RTCPeerConnection because something better emerges
16:48:34 <dom> ... there are a lot of things that we can continue to do incrementally, but I don't think we're going to get to all of it, esp at the pace we're going
16:49:04 <dom> Youenn: I've had people asking for similar features
16:49:30 <dom> ... for HEVC, there are some niche usages where ti would be hard to get UA support, and an RTPTransport would allow to fulfill these
16:50:00 <dom> ... what is the future though? would we still evolve RTCPeerConnection? it comes with some consistency and performance advantages
16:50:28 <dom> ... it would be interesting to see if you can get good performance with a WebCodecs / RTCTransport approach compared to RTCPC
16:50:28 <dom> ... An explainer would be good
16:50:42 <dom> ... Wrt packetizer, jitter buffer - WT apps would likely want something like that
16:51:03 <dom> ... we should check if a pure JS based approach isn't sufficient - this should be doable
16:51:13 <dom> ... we should focus on RTPTransport for P2P
16:51:38 <dom> ... it would still be useful to design packetizer API / jitter buffer API to help with protocol integration, but it should not be the focus
16:52:06 <dom> Harald: I do want to explode the PeerConnection object in smaller objects
16:52:40 <dom> ... but I would rather concentrate in defining APIs à la Transform API - it defines a dividing point to split the encoder from the packetizer
16:52:53 <dom> ... I'm not happy with the API we've proposed for this and am trying to reshape it
16:53:25 <dom> ... but I think we can go faster to where we want if we make it possible to plug your own object into an existing PeerConnection
16:53:34 <dom> ... breakout box did a good job at that
16:53:55 <dom> ... breaking things apart that way that leaves working systems, this will allow us to get there faster
16:54:33 <dom> Jared: RTPTransport makes me picture a nicely packaged component for SFUs
16:54:49 <dom> ... I would rather let people use this without having to fully unbundle everything
16:55:00 <dom> ... I'm worried by leaking API boundaries
16:55:23 <dom> ... like congestion window pushback where control congestion messages can end up telling the encoder to drop frames
16:55:31 <dom> ... how many of these leaky abstraction will we need to support?
16:55:58 <dom> Bernard: both mediacapture transform and encoded transform use WHATWG streams
16:56:12 <dom> ... Youenn had raised issues about that usage, not all of them have been put to bed
16:56:37 <dom> ... the danger of not using Streams is likely to create issues when using it in workers
16:56:59 <dom> ... transfering individual chunks or frames to worker isn't going to work very well
16:57:35 <dom> Youenn: FWIW, the Streams API issues are being addressed (for transferring ownership)
16:57:42 <dom> Bernard: but not for the one-object per pipeline
16:57:51 <dom> Youenn: might be the next thing worth addressing there indeed
16:58:05 <dom> Peter: I'm hearing support for an incremental approach towards something like RTPTransport
16:58:23 <dom> RRSAgent, draft minutes
16:58:24 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/16-webrtc-minutes.html dom
18:20:24 <Zakim> Zakim has left #webrtc