15:10:45 <RRSAgent> RRSAgent has joined #webrtc
15:10:49 <RRSAgent> logging to https://www.w3.org/2024/10/15-webrtc-irc
15:12:40 <hta> jib: it's "setcodecpreferences" not "setcodecrequirements" - so proposal A is acceptable
15:13:33 <hta> orphis: proposal b might be better (fail early)
15:13:33 <Zakim> Zakim has joined #webrtc
15:16:09 <hta> pthatcher: not clear on send / receive codec preferences
15:18:09 <hta> jib: might need language to clarify "it's input to negotiation".
15:19:04 <hta> jib: fallback (A) should be more user friendly than failure (B)
15:20:31 <hta> tim panton: it's going to be pretty rare, easier to let the user who does strange things work things out than footguns. Prefer A.
15:20:51 <hta> orphis: A is a silent error, B is an explicit error.
15:24:05 <hta> Decision: Rough consensus on proposal A (fall back to "all supported codecs").
15:24:35 <hta> [slide 15]
15:29:12 <hta> [slide 17]
15:29:18 <hta> bernard: duration?
15:31:55 <hta> bernard: in favor of doing a PR.
15:33:26 <hta> youenn: this exercise needs to be done. <Not clear what is being proposed>
15:33:56 <hta> youenn: on the receiving side, we need the DecodedSource proposal, which doesn't exist yet.
15:35:39 <hta> jib: we need to solve this problem. worried about the different data semantics. Might be an alternative to use EncodedVideoChunk in webrtc transforms.
15:36:01 <hta> bernard: both audio and video?
15:36:02 <hta> hta: yes.
15:37:03 <hta> jib: is round-trip conversion lossless or lossy?
15:37:23 <hta> hta: it's lossy from RTC to EncodedVideoChunk
15:38:09 <hta> youennf: should consider sending encodedvideochunk + metadata to the encodedvideosource.
15:39:20 <hta> orphis: what happens if new fields are added in the video chunk?
15:40:11 <hta> hta: we will have to update both specs in tandem.
15:41:51 <hta> [slide 21]
15:42:31 <hta> [slide 22]
15:42:36 <hta> Encoder complexity control
15:44:33 <hta> [slide 23]
15:44:48 <joachimr> joachimr has joined #webrtc
15:45:16 <hta> bernard: both for audio and video?
15:45:25 <hta> bernard: this control exists for Opus.
15:47:10 <hta> youennf: don't know if the application can get enough information to use this API effectively.
15:50:30 <hta> hbos: much like the content-hint API.
15:51:14 <hta> tim panton: see an use for this when sending multiple streams of opus, for instance.
15:52:40 <hta> hta: we can use compute pressure as one signal
15:52:57 <hta> youennf: hope we have more signals than compute pressure
15:53:01 <hta> [[slide 26]
15:53:21 <hta> App control over ICE checks (restricted from previous version)
15:55:11 <hta> [slide 28]
15:56:23 <hta> pthatcher: looks good, straightforward
15:57:01 <hta> [slide 29]
15:57:14 <hta> sameer: ready to move to a PR.
15:58:50 <hta> [slide 30]
15:58:54 <hta> future extensibility
16:00:29 <hta> [Slide 34]
16:00:50 <hta> [slide 35]
16:01:14 <hta> [slide 36]
16:02:29 <hta> [slide 37]
16:03:32 <hta> [slide 38]
16:03:36 <hta> [slide 39]
16:04:18 <hta> pthatcher: at TPAC - asked about community group (CG) - some people interested in joining a CG that wouldn't join a WG
16:05:01 <hta> jib: would be good to keep it in the WG
16:05:53 <hta> jib: if someday we could polyfill RTPSender and RTPReceiver on top of RTPTransport, this would be something that we could get behind.
16:06:37 <hta> pthatcher: the hard part of polyfilling RTPReceiver is the jitter buffer.
16:10:02 <hta> [slide 42]
16:10:06 <hta> [slide 43]
16:10:20 <hta> [slide 44]
16:12:17 <hta> [slide 47]
16:12:52 <hta> [slide 48]
16:13:42 <hta> [slide 49]
16:14:23 <hta> proposal: go with #2
16:14:33 <hta> jib: what was wrong with what you proposed at tpac?
16:15:17 <hta> jib: not sure it's powerful enough to mitigate against remote control
16:15:47 <hta> [slide 51]
16:16:11 <hta> eladalon: we can add a restricted list of events
16:16:52 <hta> eladalon: the TPAC proposals were clunky and unique on the web platform. This is more idiomatic.
16:17:48 <hta> jib: need to agree on the security level we are seeking.
16:18:53 <hta> youennf: look at ipad where pinch allows you to scroll & zoom at once.
16:20:12 <hta> youennf: could have an unified interface for both capture-wheel and set-zoom.
16:21:14 <hta> eladalon: don't understand why you'd want to merge these two very different user interactions.
16:22:41 <hta> eladalon: the demo works flawlessly with the trackpad.
16:23:11 <hta> jib: doesn't seem like tpac feedback has been incorporated.
16:23:25 <hta> eladalon: the minutes from tpac show a very different mood.
16:26:59 <hta> discussion....
16:27:52 <hta> youennf: capturewheel has a reasonable degree of consensus on the model, but has comments - will provide feedback within 1-2 weeks.
16:37:11 <hta> hta: capturewheel is ready to ship. we should concentrate on objections to setzoomlevel that show that there are security concerns are not mitigated.
16:37:44 <hta> youennf: we should consider whether reusing the direct forwarding mechanism is possible.
16:38:22 <hta> guidou: the setzoomlevel is interaction with an app-provided API that needs to work without a touch screen.
16:39:43 <hta> eladalon: note - don't look at the spec until end-of-day tomorrow.
16:45:35 <hta> youennf: need to file an issue with HTML - we want a stricter limit than transient activation, think we need HTML experts to chime in on this.
16:46:10 <hta> eladalon: the proposals #1 and #2 give stricter limitations than transient activiation (as you requested).
16:47:08 <hta> youennf: we want synchronous actcivation, not transient activation. html spec should define that.
16:49:30 <hta> eladalon: can you give me a timeline to come back with feedback?
16:49:42 <hta> jib / youennf: 2 weeks for feedback.
16:51:39 <hta> jib: limiting to click in the initial version seems good to me.
17:37:29 <Zakim> Zakim has left #webrtc