IRC log of webrtc on 2021-10-14

Timestamps are in UTC.

15:01:13 [RRSAgent]
RRSAgent has joined #webrtc
15:01:13 [RRSAgent]
logging to
15:01:16 [Zakim]
Zakim has joined #webrtc
15:01:53 [dom]
Chair: harald, bernard, jan-ivar
15:02:13 [dom]
Present+ Dom, Harald, Youenn, Jan-Ivar, TimP, BernardA, PatrickRockhill, CullenJennings, EladAlon
15:04:10 [hta]
hta has joined #webrtc
15:04:31 [dom]
15:04:35 [dom]
Present+ Guido
15:04:43 [dom]
Present+ BrianBaldino
15:04:56 [dom]
[slide 8]
15:05:07 [dom]
Bernard: [reviewing agenda]
15:05:24 [dom]
Topic: The Streams Pipeline Model (Youennf)
15:05:27 [dom]
[slide 9]
15:05:29 [dom]
[slide 10]
15:05:51 [dom]
Youenn: this presentation is about topics and issues we discussed with Jan-Ivar when we explored using Streams for media pipelines
15:06:07 [dom]
... goal is to identify blocking issues when looking at adopting streams for media pipelines
15:06:09 [dom]
[slide 11]
15:06:18 [dom]
Youenn: media pipelines connect sources with sinks
15:06:30 [dom]
... sources are readablestreams and sinks writablestreams
15:06:45 [dom]
... we would want to go from camera to network just using streams
15:06:53 [dom]
... I'll be focusing only on video pipelines
15:07:06 [dom]
... and we'll look at threads and intersection between frames and @@@
15:07:09 [dom]
[slide 12]
15:07:24 [dom]
Youenn: dealing with realtime media is better done off the main thread
15:07:45 [dom]
... in the Web Audio API, the graph is done in the main thread but the processing is done in a dedicated audio thread
15:08:01 [dom]
... in our case, there is no dedicated thread
15:08:15 [dom]
... the safest assumption is to asusme the video frames flow where they're set up
15:08:17 [dom]
[slide 13]
15:08:38 [dom]
Youenn: example 1 is a funny hat example using pipeThrough and pipeTo
15:08:53 [dom]
... it's not clear where the video frames would flow in terms of thread
15:09:31 [dom]
... the assumption would be that it runs in the same thread where these operations are being called
15:09:56 [dom]
... example 2 uses a JS transform
15:10:13 [dom]
... example 3 uses a tee - it makes it very unclear where it would be run, whether the UA would optimize it or not
15:10:29 [dom]
... so the safest assumption, with streams being a generic mechanism, is to assume same-thread
15:10:33 [dom]
[slide 14]
15:10:46 [dom]
Youenn: one potential related idea is to transfer the stream to a worker
15:11:28 [dom]
... this requires optimizations that are not standard and hard to expose to Web developers
15:11:40 [dom]
... the current implementation in Chrome is also not compliant
15:11:55 [dom]
... it's really hard to predict whether the optimization will kick in or not
15:11:58 [dom]
[slide 15]
15:12:17 [dom]
Youenn: a few examples - example 1 is the typical example where chrome will optimize after a stream transfer
15:12:28 [dom]
... in example 2 - not clear whether optimization will happen
15:12:33 [dom]
... in example 3 - also unclear
15:12:49 [dom]
... and again in example 4, when using non-camera streams
15:13:12 [dom]
... let's say you transfer an MST to another frame, and then take a stream transfered to a worker - will it be optimized? as a developer, you can never know
15:13:22 [dom]
... as opposed to Web Audio that gives very clear spec'd guarantees
15:13:25 [dom]
[slide 16]
15:13:55 [dom]
Youenn: streams are a generic tool designed for flexibility - we can't guarantee for performance
15:14:12 [dom]
... we can give that guarantee with transferable MediaStreamTrack
15:14:38 [dom]
... this allows to avoid the issues associated with streams when dealing with realtime streams
15:14:56 [dom]
... additional optimizations can still happen as a bonus, but they're no longer a pre-requisite
15:15:02 [dom]
[slide 17]
15:15:16 [dom]
Youenn: buffering with streams happens at each transform step in the media pipeline
15:15:43 [dom]
... a typical pipeline is like the one at the top, with greedy processing
15:16:17 [dom]
... but in cases you don't want to process all frames, e.g. a 1-second old frame might be better skipped
15:16:24 [dom]
... as does mediastreamtrackgenerator
15:16:51 [dom]
... the second pipeline illustrates sequential processing which can be beneficial
15:17:05 [dom]
... I think that's a safer approach
15:17:07 [dom]
[slide 18]
15:17:22 [dom]
Youenn: this is a real issue; videoframe are big and scarce resources
15:17:39 [dom]
... it's also unclear for web developers what happens; buffering is hidden from them
15:18:05 [dom]
... issue-1158 is where this is being described - there is probably a solution that will emerge
15:18:24 [dom]
... but it's unlikely that the default behavior will be the safe behavior for stream of frames
15:18:54 [dom]
[slide 19]
15:19:11 [dom]
Youenn: in general for streams, the idea is that backpressure will deal with buffering
15:19:35 [dom]
... but for us, some limited buffering might be useful to allow
15:19:44 [dom]
... but it's hard to deal with WHATWG streams
15:19:55 [dom]
... the stream queue is opaque to the application by design
15:20:07 [dom]
... and the queuing strategy is very static, based on the high-water mark
15:20:22 [dom]
... updating the strategy requires resetting your pipeline
15:20:45 [dom]
... WHATWG streams might be able to cover the use case, but with complexity
15:21:15 [dom]
[slide 20]
15:21:31 [dom]
Youenn: Tee is the typical way to allow multiple consumers with streams
15:21:58 [dom]
... tee is part of the design of the API so we should support it
15:22:01 [dom]
[slide 21]
15:22:27 [dom]
Youenn: but we know tee is broken when used with our videoframes stream
15:22:38 [dom]
... structured clone might solve this, as suggested in issue 1156
15:22:56 [dom]
... but the default behavior again won't be the right one for us
15:23:07 [dom]
[slide 22]
15:23:17 [dom]
Youenn: but even with structured clone, more changes are needed
15:23:29 [dom]
... if you apply structureClone, you add hidden buffering
15:23:53 [dom]
... if the two branches don't consume data at the same pace
15:24:15 [dom]
... issue 1157 discusses this - so far, no clear solution to this
15:24:22 [dom]
... streams by design aren't made to drop items
15:25:14 [dom]
Present+ Carine
15:25:16 [dom]
[slide 23]
15:25:26 [dom]
Youenn: the last issue I want to discuss is lifetime management
15:25:50 [dom]
... streams rely on garbage collection, whereas we don't want to rely on GC for videoframe
15:26:38 [dom]
... there is no easy way to enforce who will close a VideoFrame, making it error prone for Web developers
15:26:54 [dom]
... there is no API contract, so unclear how to solve this
15:27:15 [hta]
15:27:17 [dom]
... maybe a dedicated subclass with built-in memory management?
15:27:27 [dom]
... but no work has started in that direction
15:27:47 [dom]
... if you look at the pipeline - if you change the pipeline, you need to cancel streams
15:28:06 [dom]
... these streams might have buffer, which raises the question of GC again
15:28:18 [dom]
[slide 25]
15:28:31 [dom]
Youenn: we need to solve these issues, buffering, tee and life management for VideoFrame
15:28:51 [dom]
... there has been progress, but more is needed and it's unclear to me how far we can go
15:28:54 [dom]
[slide 27]
15:29:17 [dom]
Youenn: having a high level confidence that these issues can be solved before picking it as our model for designing our APis
15:29:45 [dom]
... if we select streams, we should extend support for them in existing and new API (e.g. videodecoder/encoder, barcodedetector)
15:29:57 [dom]
... this doesn't seem to be part of the plans for e.g. WebCodecs
15:30:27 [dom]
Jan-Ivar: a couple of comments
15:31:11 [dom]
... on backpressure, I believe with a transformstream and highwatermark of 0 will automatically call backpressure
15:31:50 [dom]
... wrt dynamic buffering, highwatermark is indeed static, but dynamic buffering can be dealt with a transformstream - but not with a high water mark of 0
15:32:29 [dom]
Youenn: I'm not optimistic of seeing the problem solved at the source level
15:32:39 [dom]
... my understanding with life time management is that there is no API contract
15:32:49 [dom]
... you don't know if close will be called; I like consistency
15:33:19 [dom]
... memory management would be something we would want to design carefully
15:33:29 [hta]
I intended to write q+
15:33:32 [dom]
Bernard: in the current model where we don't have highwatermark
15:33:32 [hta]
15:35:22 [dom]
Youenn: the camera pool might have 10 video frames; with a 5 steps pipeline, 5 frames will be automatically allocated - this leaves only 5 remaining slots which might not be enough
15:35:29 [dom]
... and some devices might have a smaller buffer of frames
15:35:52 [dom]
... which will create variable framerates
15:36:18 [dom]
bernard: the lack of streams integration in webcodecs creates two queues that need to be managed
15:36:40 [dom]
... and that's not particularly transparent, something you have to keep track of
15:36:56 [dom]
... this can create significant memory management issues
15:37:13 [dom]
... wrapping streams is not particularly satisfactory in our case
15:37:39 [dom]
Harald: a couple of observations
15:37:58 [dom]
... webcodecs did have a stream-based API for a while; MSTP and MSTG was the reason they got dropped
15:38:10 [dom]
... we've had very few people reporting problems with these issues
15:39:09 [dom]
... my impression is that the Stream model has been somewhat confused with the stream shim implementation
15:39:21 [dom]
... we should have a clean model where issues are moved to implementations, not the model
15:39:35 [dom]
... wrt tees, I have some experience with reading the CL that added tee to the spec
15:39:48 [dom]
... worries were expressed that are very similar to ours
15:39:51 [dom]
... tee is a bad design
15:40:07 [dom]
... it's fairly easy to write your own JS to get the tee you want, which is quite dependent on your app
15:40:28 [dom]
... tee doesn't respect the high water mark on down stream - tee is bad
15:40:58 [dom]
... on the contract point, I think it's natural to say that downstream either has to call close, or pass it to something that will call close on VideoFrame
15:41:09 [dom]
... we shouldn't depend on upstream to do anything
15:41:22 [dom]
... we do have an issue with disrupted pipeline - that needs to be solved
15:41:53 [dom]
... my conclusion is that some of these issues are with the description more than implementations, and some are issues we need to solve but aren't fatal
15:42:10 [dom]
... like tee - it's not because it's possible to use it badly that we shouldn't use streams
15:42:30 [dom]
... the streams API is superior to callbacks because it avoid re-doing it all
15:42:48 [dom]
Youenn: I agree with you that tee is bad - salvaging it will be difficult
15:43:09 [dom]
... doing one's tee in JS is indeed better - but you'll end up using promise-based callbacks
15:43:17 [dom]
... but if so, why using streams?
15:43:35 [dom]
... re other issues not being fatal, I would welcome proposals that address these concerns
15:44:07 [dom]
... at the moment, I'm not confident we can proceed with confidence that streams is a good enough match
15:44:15 [dom]
... if they can be solved, I agree that streams are appealing
15:44:34 [dom]
Jan-Ivar: all these issues filed on github are with the model
15:44:46 [dom]
... they're not necessarily huge though, and I'm not sure we should block on them
15:45:08 [dom]
... given that one API is already shipping, I think we need to converge on a standard sooner rather than later
15:46:07 [dom]
Youenn: I'd be interested in getting a pro/cons comparison of promsise callbacks vs streams
15:46:11 [dom]
Topic: Altnerative Mediacapture-transform API
15:46:43 [dom]
[slide 30]
15:47:07 [dom]
jib: today, the realtime media pipelie is off main thread today
15:47:15 [dom]
15:47:35 [dom]
[slide 31]
15:47:44 [dom]
jib: that remains true in webrtc-encoded-transform
15:48:05 [dom]
... the original chrome APi was on main thread, but we then converged on a standardized API off the main thread
15:48:22 [dom]
... this was importatn for encoded media, all the more so for aw media
15:48:25 [dom]
[slide 32]
15:48:55 [dom]
jib: the premise here is that the main thread is bad - "overworked & underpaid" as surma qualified during a chrome dev summit in 2019
15:49:23 [dom]
... surma highlighted webworkers as the solution to that problem
15:49:51 [dom]
... contention on the main thread is common and unpredictable
15:50:16 [dom]
... and hard to detect outside of a controlled environment - as opposed to web workers
15:50:20 [dom]
[slide 33]
15:50:54 [dom]
jib: when webcodecs made the decision to expose the API on the main thread, they based this on non-realtime media use cases
15:51:11 [dom]
... and they strongly encourage to do realtime processing off the main thread
15:51:16 [dom]
[slide 34]
15:51:42 [dom]
jib: we have a non-adopted document "mediacapture-transform" (which has shipped in Chrome 94 despite not being standardized)
15:52:27 [dom]
... my position is that this proposal is not satisfactory because it exposes realtime pipeline on main thread by default, it doesn't encourage use in workers, relies on non-standardized optimizations
15:52:41 [dom]
... also, now mediastreamtrack is transferable so this creates new opportunities
15:52:46 [dom]
[slide 35]
15:53:17 [dom]
[slide 36]
15:53:58 [dom]
jib: having to ask the main thread all the time to interact with the API makes sense
15:54:10 [dom]
... it's baked in the assumption of main thread
15:54:13 [dom]
hta: that's untrue
15:54:32 [dom]
[slide 37]
15:55:12 [dom]
jib: for a processed (e.g. background replacement) self-view use case combined with webtransport
15:55:29 [dom]
... tee, clone, postMessage(constraints) aren't good approaches
15:56:01 [dom]
... whereas with track available in a worker, we have a natural API
15:56:07 [dom]
[slide 38]
15:57:07 [dom]
jib: the tunnel semantics of WHATWG streams are not meant to solve creating streams on the wrong realm
15:57:16 [dom]
... MSTP is built on broken assumptions
15:57:30 [dom]
[slide 39]
15:57:55 [dom]
jib: I have an alternative proposal based on transferable mediastreamtrack
15:58:05 [dom]
... the proposal focuses on video at the moment
15:58:18 [dom]
... it encourages use on workers
15:58:36 [dom]
... it still uses streams, despite youenn's identified issues - which I think we can find solutions for
15:58:39 [dom]
[slide 40]
15:59:13 [dom]
jib: we expose a readable attribute in a worker version of the MediaStreamTrack
15:59:50 [dom]
... this keeps data off the main thread
15:59:52 [dom]
[slide 41]
16:00:00 [dom]
jib: a more complicated example, read & write
16:00:18 [dom]
... this is the equivalent of mediastreamtrackgenerator
16:00:29 [dom]
... we expose only on workers a new VideoTrackSource interface
16:01:07 [dom]
... the example is a crop example inspired from WebCodecs
16:01:39 [dom]
... it aligns better with the separate of source and track of the mediacapture-streams spec
16:01:47 [dom]
... it interacts well with clone and structured cloning
16:02:03 [dom]
[slide 42]
16:02:43 [dom]
jib: for any video processing, you have a self-view (with high framerate) and a low-fps to send on the network
16:03:35 [dom]
... applyConstraints works well with a peerconnection
16:03:37 [dom]
[slide 43]
16:03:57 [dom]
jib: now with WebTransport, using track cloning
16:04:37 [dom]
... this shows native downscaling with applyConstraints as a workaround to using tee
16:04:49 [dom]
... not clear how MSTG would let you do this via a worker
16:04:53 [dom]
[slide 44]
16:05:07 [dom]
jib: benefits: simpler API taking advantage of transferable tracks, with fewer APIs to learn
16:05:20 [dom]
... doesn't block real-time media pipeline by default
16:05:39 [dom]
... it has parity with MSTP & MSTG features
16:05:52 [dom]
... similar in terms of brevity
16:05:59 [dom]
... doesn't rely on UA optimizations
16:06:07 [dom]
... and deal with muted sources
16:06:13 [dom]
[slide 45]
16:06:46 [dom]
jib: Bonus: if we want promise callbacks for stream-based, you can use "for await" on the stream
16:06:54 [dom]
[slide 46]
16:07:24 [dom]
jib: if you want more than a readable - this can be done with cloning, but we could also provide dedicated surface
16:07:47 [dom]
Harald: I kind of like the proposal - it's almost totally equivalent to MSTG and MSTP
16:08:23 [dom]
... the examples where you have posting messages to the main thread - MSTG and MSTP are designed to be available to the same contexts where tracks are
16:08:42 [dom]
... MSTG and MSTP will need to be available on workers when MST are
16:09:18 [dom]
... in terms of quoting Chris Cunningham on the Web Codecs decision - one of the motivation for main thread is the availability of other APIs on the main thread
16:10:06 [dom]
... transfering streams as a pipeline between origin and destination context - it assumes the source is main thread, but that's not true
16:10:13 [dom]
... with a camera, the source of the stream is the camera, not the main thread
16:10:39 [dom]
... otherwise, I like the shape of the API; it's very similar to what I proposed
16:11:02 [dom]
jib: I didn't mean to misrepresent these aspects; I see now that MSTG and MSTP are available in workers
16:11:07 [dom]
... but they're not transferable
16:11:13 [dom]
... so they would have to be created in the worker?
16:11:14 [dom]
harald: yes
16:12:54 [dom]
youenn: re slide 37
16:13:14 [dom]
... re not using tee because it's bad - I agree, but I hope we should be able to use it
16:13:23 [dom]
... with the example in slide 37, we lose back pressure
16:13:37 [dom]
... we might be able to add it back
16:14:07 [dom]
... in general, in terms of API shape, if we assume that we use streams, this is a good shape that solves some of the issues that I had with the prior proposal
16:14:15 [dom]
... in general, mediacapture-main has concepts of source and track
16:14:27 [dom]
... having a JS object that represent the source is a good thing
16:14:38 [dom]
... similar to a readablestream that can be native or a JS object
16:14:50 [dom]
... I think we should go there, will make it easier to extend the API and remove edge cases
16:15:12 [dom]
... I would prefer not to rely on tranferable streams, but instead rely on transferable MST
16:15:34 [dom]
... which creates a typed way of transferring that can help fulfill the requirements we need
16:16:07 [dom]
jib: my example may have a mistake on which track to clone - would flipping it around fix backpressure?
16:16:10 [dom]
youenn: I don't think so
16:17:00 [dom]
... introducing backpressure on the writablestream might do the trick
16:17:09 [dom]
harald: backpressure cannot deal with framerate
16:17:39 [dom]
[slide 47]
16:17:59 [dom]
jib: tee can help with backpressure, at the cost of tee problems
16:18:19 [dom]
... the only thing odd is the "createFrameDropper", a transform stream to drop frames
16:18:39 [dom]
... clone/applyConstraint is a work around if we can't solve the tee problem
16:19:18 [dom]
bernard: slide-36 and -37 don't make sense to me
16:19:38 [dom]
jib: right, I wasn't aware that MSTP and MSTG were be available in workers
16:19:48 [dom]
... but you could still do this, and the situation would need to be handled
16:20:08 [dom]
... but Harald is right there is a lot of similarities between two proposals
16:20:26 [dom]
... the advantage is that we don't need to add a new object
16:21:00 [dom]
bernard: re slide 33
16:21:15 [dom]
... datachannels for instance is only available on the main thread
16:21:28 [dom]
... the lack of consistent API support in workers was part of the challenge
16:21:34 [dom]
16:21:53 [dom]
jib: MSTG is a bit of an odd duck - it's also track
16:22:30 [dom]
... re lack of APIs, you can always transfer tracks back to the main thread when needed
16:22:40 [dom]
... this doesn't require breaking transferable streams semantics
16:23:11 [dom]
Harald: if you have to tell some place upstream that you're frame is 30, then backpressure can't carry that information
16:23:28 [dom]
... backpressure can't tell the difference between "I'm slightly late" and "I want only every other frame"
16:23:40 [dom]
... we need to be able to carry these signals
16:23:56 [dom]
... we haven't gotten to it yet
16:24:14 [dom]
bernard: there may be several stages of reporting that's needed
16:24:29 [dom]
youenn: this depends on whether sources are push or pull
16:24:38 [dom]
... consumers need to propagate things up to the source
16:24:49 [dom]
... backpressure may not always be the right mechanism, but we need to support it
16:25:06 [dom]
... I also agree we need to fix carry backmessages
16:26:11 [dom]
... the fact that some of the APIs need to be done in the main thread is sad, but it still moves a lot of the heavy processing to workers, leaving only some of the plumbing on the main thread
16:26:40 [dom]
... there may be gaps to do good media processing - if so, we should make them available in workers, and this API would help accelerate that transition
16:27:40 [dom]
Guido: in addition to APIs availability on the main thread, we have first-hand feedback from app developers who WANT to do on main thread for their use cases
16:28:32 [dom]
... otherwise, the two APIs are equivalent beyond their shape
16:29:16 [dom]
dom: re use cases on main thread, is it a matter of developer experience?
16:29:42 [dom]
guido: for certain apps, adding workers in the mix is adding a cost, not a value
16:29:57 [dom]
... it only adds complexity and extra resource consumption
16:30:16 [dom]
jib: even there are such use cases, we're trying to protect a realtime media pipeline
16:30:53 [dom]
Topic: Mediacapture Transform API
16:31:07 [dom]
[slide 50]
16:31:24 [dom]
Harald: [summarizes the API of MSTP and MSTG]
16:31:28 [dom]
[slide 51]
16:31:46 [dom]
Harald: it shipped in Chrome 94, it's actually used in products with new features based on it
16:32:01 [dom]
... very few problems reported on it
16:32:07 [dom]
[slide 52]
16:32:27 [dom]
Harald: we believe the threading model is something that app developers need to pick, with encouragement from platform developers
16:32:34 [dom]
... but dictacting it is not the right approach
16:32:40 [dom]
... Streams are transferable objects
16:33:17 [dom]
... adding worker availability to MSTG and MSTP is a reasonable addition following the transferability of MST
16:33:31 [dom]
[slide 53]
16:33:53 [dom]
Harald: we need to make sure we have samples that show realistic working real-time operations
16:33:59 [dom]
... including offthread processing
16:34:12 [dom]
[slide 54]
16:34:35 [dom]
Harald: in terms of improvements, we need better control of adaptation source (backpressure, synchronizing streams, framerate)
16:34:58 [dom]
... we need to improve experience with streams that don't come from camera - not trivial to synchronize them
16:35:13 [dom]
... we can work on these aspects once we have agreed on a common base
16:35:20 [dom]
[slide 55]
16:35:48 [dom]
Harald: the two proposals agree on Streams for frame delivery
16:35:58 [dom]
... difference of opinion for availability on main thread
16:37:08 [dom]
... the proposals differ on whether the generator or the consumer expands MST or use a separate class
16:38:23 [dom]
... this can be discussed
16:38:35 [dom]
... another difference is that MSTG/MSTP is dealing with both audio and video
16:38:42 [dom]
... where jib is focused on video only
16:39:15 [dom]
... clear similarities on model, and distinctions that can be derived in specific issues
16:40:22 [dom]
jib: streams are transferable, but implicit transfer of the source isn't web compatible and we should go away from it
16:40:39 [dom]
harald: my interpretation is that the stream source is NOT on the main thread - e.g. it's attached to the camera
16:41:31 [dom]
jib: the optimizations that chrome has been doing is not compliant to spec AFAICT
16:41:46 [dom]
harald: I haven't been convinced the issue is not with the spec
16:42:08 [dom]
jib: the fact that this can't be optimized all the time would make this head scratching
16:42:15 [dom]
s/the time/the times/
16:43:20 [dom]
harald: I find the stream spec impossible to navigate - happy to get pointers
16:43:29 [dom]
jib: one of my slide covered the intent of the spec
16:43:55 [dom]
harald: but it relies on the interpretation that the source is in the main thread
16:44:25 [dom]
youenn: the algorithms described in the stream spec will need to be run in the context of the stream (not the source)
16:44:36 [dom]
... there is some leeway in the stream spec to optimize pipethrough et al
16:44:40 [dom]
... but not for the rest afaict
16:45:09 [dom]
... Adam Rice (stream editor) suggested a specific optimizable stream might be needed
16:45:56 [dom]
[slide 38]
16:46:14 [dom]
jib: [quoting from the spec]
16:46:23 [dom]
... it's explicitly about transfer between realms
16:49:56 [dom]
-> Transferable streams: the double transfer problem #1063
16:50:35 [dom]
jib: re exposure to main thread - for webrtc-encoded-transform, we agreed to focus off-thread only
16:50:50 [dom]
harald: I have a bug open to allow to reenable it on main thread
16:51:07 [dom]
... I think this was a bad decision
16:51:07 [dom]
Topic: Wrap up and next steps
16:51:31 [dom]
[slide 55]
16:51:48 [dom]
bernard: I would like to get a sense of the room on the major distinctions between the 2 proposals
16:52:51 [dom]
jib: would also like to get a sense on whether my proposal is acceptable under what changes
16:53:15 [dom]
harald: we have 2 potential starting points, I don't see any reason to pick one over the other
16:55:10 [dom]
youenn: I want to reiterate my concerns about the difficult stream issues that I raised and for which I'm not seeing progress
16:57:31 [dom]
dom: I think the question is about API shape (readable/VideSource vs MSTP/MSTG)
17:00:29 [dom]
Cullen: I don't feel strongly about any of these questions, not knowing enough about the impact on implementations
17:00:50 [dom]
... I would need more background to give an informed opinion
17:04:25 [dom]
Bernard: So, we will bring these questions to the mailing lists
17:05:08 [dom]
Dom: ... after discussions with the chairs
17:05:21 [dom]
RRSAgent, draft minutes v-slide
17:05:21 [RRSAgent]
I have made the request to generate dom
17:05:28 [dom]
RRSAgent, make log public
17:07:02 [dom]
Meeting: WebRTC October 2021 Virtual Interim
17:07:04 [dom]
RRSAgent, draft minutes v-slide
17:07:04 [RRSAgent]
I have made the request to generate dom
17:33:16 [hta]
hta has left #webrtc
18:00:29 [Zakim]
Zakim has left #webrtc