14:59:08 <RRSAgent> RRSAgent has joined #webrtc
14:59:12 <RRSAgent> logging to https://www.w3.org/2024/08/27-webrtc-irc
14:59:12 <Zakim> Zakim has joined #webrtc
14:59:12 <dom> RRSAgent, make log public
14:59:44 <dom> Meeting: WebRTC August 27 2024 meeting
14:59:44 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/August_27_2024
14:59:44 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2024Aug/att-0003/WEBRTCWG-2024-08-27__1_.pdf
14:59:44 <dom> Chairs: HTA, Jan-Ivar, Bernard
15:00:17 <dom> Present+ Bernard, Dom
15:00:48 <dom> Present+ Florent, Henrik, PeterT
15:01:38 <dom> Present+ PatrickRockhill
15:02:01 <dom> Present+ TimP, Carine, Sameer, Tove
15:02:23 <dom> Present+ Youenn
15:02:48 <dom> Present+ Alfred_Heggestad
15:03:37 <dom> Present+ Elad, Guido
15:04:27 <dom> Present+ Lucia_Google, Frederick_Google
15:04:55 <dom> Recording is starting
15:05:06 <dom> Present+ Markus_Handell
15:05:31 <dom> Present+ Jan-Ivar
15:06:50 <dom> Bernard: TPAC is ahead of us - please send request for agenda time, takind advantage of the longer meetings we'll have there
15:07:10 <dom> Present+ Varun_Singh
15:07:52 <dom> Present+ Harald
15:08:21 <dom> Topic: -> https://github.com/screen-share/captured-surface-control Captured Surface Control
15:08:21 <dom> [slide 11]
15:10:19 <dom> Present+ SunShin
15:10:43 <dom> [slide 12]
15:11:24 <dom> [slide 13]
15:12:22 <dom> [slide 14]
15:13:35 <dom> [slide 15]
15:15:05 <dom> [slide 16]
15:15:42 <dom> [slide 17]
15:18:51 <dom> Jan-Ivar: the capture wheel solution looks promising, I'm supportive; couldn't we use it for zoom as well, through the preview tile with some browser controls?
15:19:30 <dom> ... re zoom level, would there be an opportunity to give feedback on the API shape? e.g. use an attribute instead of a method
15:20:12 <dom> ... re transient activation, would it be consumed? would this through a button?
15:20:25 <dom> Elad: for instance, but it would vary across apps
15:20:36 <dom> Jan-Ivar: why a 0-100 integers rather than floating point?
15:21:36 <dom> Elad: it matches what browsers show in their UI; also helps with other UI (e.g. drowdown, slider, radio buttons) which is also why we want to leave the UI to the app
15:22:36 <dom> Jan-Ivar: I still would prefer to use the same solution for zoom; does the zoom affect only the capture or also the original doc?
15:22:44 <dom> Elad: also the original document
15:23:42 <dom> Youenn: I discussed this internally; being able to send commands to another app breaks a pretty high security boundary, which got pushback
15:24:12 <dom> ... +1 on consuming user activation
15:24:45 <dom> ... re scrolling - how should this work on touch devices (e.g. ipad)? limiting this to "wheels" isn't ideal
15:24:51 <dom> Guido: scrolling might be a better name indeed
15:25:43 <dom> ... we could limit this to a browser surface for the time being and leave it window to a later iteration
15:26:22 <dom> youenn: in terms of UX, either you embed everything in the capturing app, or you leave the capturing app aside
15:26:35 <dom> ... in the latter case, managing scrolling is of less interest
15:27:05 <dom> Elad: yes, but that pattern doesn't work across all apps/UXes
15:27:14 <dom> ... there is finite real estate on the screen to make use of
15:28:17 <dom> youenn: this is an area of experimentation, e.g. macos provides new options in this space
15:28:50 <dom> ... but in general, having inconsistent behavior across browser/non-browser apps would be un-optimal
15:29:14 <dom> ... conversely, if the plan is to integrate both, we need to understand how that would work and if that could work
15:29:23 <dom> Guido: how about to start with tab?
15:29:46 <dom> Youenn: tab is interesting, but if we limit ourselves to tab, this isn't necessarily the best API
15:30:31 <dom> Elad: but shipping tab would be a good way to validate the interest before we invest in the more complicated space for "window" (which requires different OS adaption and different security barriers)
15:31:01 <dom> Jan-Ivar: re transient activation, it doesn't resolve the remote attack - e.g. setting a very high zoom would confuse the user
15:31:30 <dom> ... hence why I would prefer the wheel approach
15:32:15 <dom> ... the PiP button in the media element in FF could serve an example of a browser-provided UI
15:33:09 <dom> Elad: so I hear support for send wheel from Jan-Ivar
15:33:36 <dom> Youenn: on our end, feedback is negative at the moment - having something that keeps more control under the user agent would be preferable
15:33:44 <dom> Elad: does that apply if we only do tabs?
15:34:05 <dom> Youenn: not currently opposed to tabs, but it remains that the more control left in the UA, the better
15:34:22 <dom> Present+ JohannesKron
15:34:27 <dom> Topic: -> https://github.com/w3c/mediacapture-main/issues/982 Moving Forward with Mute
15:34:27 <dom> [slide 20]
15:35:13 <dom> [slide 21]
15:37:46 <dom> [slide 22]
15:38:58 <dom> [slide 23]
15:40:18 <dom> [slide 24]
15:42:19 <dom> [slide 25]
15:42:27 <dom> [slide 26]
15:43:15 <dom> Youenn: track.muted means no frame, not black frame - we should decide first what to do with black frames
15:43:24 <dom> ... this is JS-observable
15:43:41 <dom> ... in Safari, there will no rfvc callback from a muted track
15:44:08 <dom> ... we should have a consistent implementation
15:44:26 <dom> guido: not opposed to that, but the spec currently supports including black frames in muted
15:44:38 <dom> youenn: so let's try to converge on muted = no frame
15:45:40 <dom> guido: the goal would be to transition existing apps to the new attribute, and then frame counter
15:46:03 <dom> youenn: I'm not sure Safari would implement this, but this may not impact compat
15:46:28 <dom> ... re "isSendingFrames = false", it would be best to use "isNotSendingFrames" for compat with UA that wouldn't implement it
15:46:42 <dom> ... if the source is generating black frames, I'm happy for them to have a counter
15:46:48 <dom> Bernard: I share some of Youenn's concerns
15:47:14 <dom> ... originally, we did say that black frames would be sent on muted, but I don't think we thought this through the whole system
15:47:34 <dom> ... inferring muted from seeing black frames feel like it may generate many interop issues across many APIs
15:47:53 <dom> ... Why did we decide to send blackframe (vs not sending)?
15:49:15 <dom> HTA: sending a single black frame to replace the content of a muted stream would be sufficient, but the spec allows to continue sending black frames
15:49:49 <dom> Jan-Ivar: I appreciate the migration path you've identified; +1 to using the negative form, and maybe not "sending", but e.g. "producing"
15:50:02 <dom> Guido: happy to bikeshed if there is interest in the direction
15:50:37 <dom> Jan-Ivar: adding 3 stats feel a bit excessive; maybe we can count which of the frames are black
15:50:55 <dom> Youenn: safari only send black frames on a peerconnection (maybe mediarecorder)
15:51:15 <dom> ... it's a on consumer basis
15:51:31 <dom> -> https://jsfiddle.net/jib1/cfcoqdwz/12/ JSFiddle exploring what happens on mute
15:52:04 <dom> Guido: the goal is to simplify the spec by removing the flexibility the spec currently allows
15:52:49 <dom> ... so that mute becomes more useful with better interop
15:53:46 <dom> TimP: if you use stats, everyone is already using polling
15:54:06 <dom> Guido: the goal is to have a smooth migration path, with clarity that it will be deprecated later
15:54:33 <dom> Henrik: I think the boolean is needed for the migration path; isMuted stops the counter increment in Chrome IIRC
15:55:13 <dom> Guido: I'll start a PR to iterate on this
15:55:24 <dom> Youenn: I'll file an issue to get us to converge on muted=no frame
15:55:39 <dom> Topic: -> https://github.com/w3c/mediacapture-output/ Speaker selection
15:55:39 <dom> Subtopic: Issue #142 / PR #143 Why prompt for a subset of stored speakers or speakers setSinkId already accepts?
15:55:39 <dom> [slide 30]
15:58:50 <dom> youenn: this seems fine to me; small caveat: all output devices exposed in enumerateDevices vs only output speaker associated with a microphone in getUserMedia
15:59:19 <dom> ... PR #143 is fuzzy about that - not sure if you mean the restricted or broader scope for getUserMedia
15:59:57 <dom> ... maybe a note to be explicitly this is only for the speaker tied to a microphone exposed via gUM
16:00:11 <dom> Subtopic: Issue #133: The first "audiooutput" MediaDeviceInfo returned from enumerateDevices() is not the default device when the default device is not exposed
16:00:11 <dom> [slide 31]
16:02:46 <dom> [slide 32]
16:06:03 <dom> Youenn: if we already have an audio output entry, it means we're already out of passive fingerprinting - we could expose the "real" deviceId of the default?
16:07:40 <dom> Jan-Ivar: setSinkId("") has different semantics from setSinkId("the-actual-deviceid-of-the-default")
16:07:58 <dom> Youenn: indeed, the latter wouldn't change if the default changes
16:08:19 <dom> ... OK, I'm fine with either proposals, with a bit of a preference with the non-empty string solution
16:09:19 <dom> Guido: UA & System defaults aren't the same
16:10:01 <dom> ... system default maps to what the underlying platform calls system default
16:10:22 <dom> ... default is a different from the specific deviceid currently the default
16:10:35 <dom> s/a different/different semantically/
16:11:00 <dom> ... the UA might have a different default than the OS, that would track a different device than the system
16:11:45 <dom> ... I think we need to be more specific about what we mean by system-default device (the one we use "default" for in Chromium)
16:12:20 <dom> ... I'm partial to proposal B to avoid overloading the meaning of empty string
16:13:32 <dom> Jan-Ivar: the spec only talks about system-default, not about UA-default; I'm not aware of any UA with a default speaker
16:14:31 <dom> Youenn: I agree with Guido there is a difference
16:15:13 <dom> Harald: "default" is a tricky concept; windows had two default devices (one of telephony, the other for general audio)
16:15:34 <dom> ... referring to a UA default might make more sense since system-default isn't a well-defined term
16:15:54 <dom> Jan-Ivar: the empty string is already identified as dynamically following the system-default
16:16:37 <dom> Topic: -> https://github.com/w3c/webrtc-extensions/issues/159 RTCRtpEncodingParameters: scaleResolutionTo
16:16:37 <dom> [slide 35]
16:18:17 <dom> [slide 36]
16:20:56 <dom> Jan-Ivar: this SGTM; I would use our own dictionary, and find a better name than rect
16:21:07 <dom> Henrik: e.g. resolution
16:21:37 <dom> Jan-Ivar: re aspect ratio, what you propose seems to match what we do for constraint, I like that
16:21:57 <dom> ... my only question is if the UA could do it on its own without new API
16:22:35 <dom> Henrik: I don't think it's possible, it's inherently racy and buffers makes it even more uncertain
16:23:16 <dom> Youenn: this is maxWidth and maxHeight really?
16:23:21 <dom> Henrik: yes, we can call it that
16:24:01 <dom> Jan-Ivar: what happens if the aspect ratio set by width & height is different from the source?
16:24:15 <dom> Henrik: it will make it fit in the specified width & height
16:24:53 <dom> Florent: what happens if either width or height isn't specified?
16:25:12 <dom> Henrik: I think we should require them both
16:25:30 <dom> Florent: that might help deal with aspect ratio issues
16:25:48 <dom> Henrik: but that breaks the orientation agnostic approach
16:26:57 <dom> Florent: if you only care about maxHeight (as typical e.g. for a presentation)...
16:27:38 <dom> Elad: windows or tabs can be resized, so we should probably expect that API to be called more than once
16:28:06 <dom> Henrik: the point of the API is to avoid reconfiguration as much as possible, not in all cases
16:29:13 <dom> Florent: scaleResolutionDownBy would be a better fit for that situation
16:29:51 <dom> Henrik: this is mostly about optimizing processing when dropping layers in simulcast
16:30:01 <dom> jan-ivar: what happens when setting both?
16:30:16 <dom> Henrik: we throw an exception
16:31:08 <dom> RESOLVED: proceed with a PR for #159 with revised names
16:31:21 <dom> Topic: -> https://github.com/w3c/webrtc-pc/issues/2987 RTCRtpParameters.codec matching is probably too strict
16:31:21 <dom> [slide 39]
16:34:01 <dom> Florent: there is a provision in the spec about unsetting a codec (pointed to the relevant step in the github issue)
16:34:17 <dom> ... hidden in the long "apply a description" algorithm
16:35:10 <dom> ... using the "codec dictionary match" algorithm (which may need to be improved)
16:35:40 <dom> ... maybe we need to focus it about the other side wants to receive, which as we've grown aware of has a lot of subtleties
16:36:13 <dom> [slide 40]
16:36:46 <dom> Harald: the two codecs in the slide can't match, since one of them say it can only deal with 30 fps
16:37:15 <dom> ... codec matching is defined by SDP O/A, on a per-codec basis
16:37:51 <dom> Jan-Ivar: but there are other examples of fmtp that would be compatible, right?
16:38:15 <dom> Harald: yes, e.g. most h264 profiles would accept baseline
16:38:28 <dom> ... but main and high are different superset of baseline, so shouldn't match
16:38:40 <dom> ... illustrating again this is codec dependent
16:39:07 <dom> Bernard: a non-match should only occur in situations where you need symetry (which most codecs don't require)
16:39:32 <dom> HTA: that's about negotiation - what we're discussing is what we want to send
16:40:10 <dom> Bernard: I thought the original issue was about negotiation; in this is particular example, this is about receiver capabilities, which aren't incompatible as a result, since no symetry is required
16:41:10 <dom> HTA: we need a matching algorithm for negotiation, and a different one for setParameters
16:41:31 <dom> Jan-Ivar: codec-dict-match shouldn't be confused with the negotiation algorithm
16:41:44 <dom> ... we should specify a selection algorithm
16:42:27 <dom> ... the spec allows to clear the codec parameter after negotiation - the UA might still use it as a hint (for then we should specify it for interop)
16:44:18 <dom> Florent: the order in the SDP express a preference, but not a requirement
16:44:54 <dom> Bernard: +1 - the sender can change to a different negotiated codec at any time (e.g. in case of a hardware codec failure)
16:45:49 <dom> HTA: we could argue that if the codec specifies a codec description within the parameters of the negotiated parameters codecs, then it should use that one
16:45:58 <dom> ... if it's a superset, it needs clearing
16:47:19 <dom> ... I don't want our spec to be dealing with codec match across all codecs, but we could have a note of the acceptability
16:47:37 <dom> ... this is usually covered in offer/answer considerations in the relevant RFCs
16:48:20 <dom> Florent: if the developer really want a codec, they can call setParameters again
16:48:45 <dom> ... we probably will learn from developers as adopt it of additional needs
16:49:55 <dom> ... Clearing the codec parameter already signals that it has been ignored, and stats expose what codec is in use
16:52:07 <dom> RRSAgent, draft minutes
16:52:09 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/27-webrtc-minutes.html dom
16:52:42 <dom> HTA: let's continue these clarifications in the issue
16:53:12 <dom> RRSAgent, draft minutes
16:53:13 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/27-webrtc-minutes.html dom
18:30:29 <Zakim> Zakim has left #webrtc