15:02:00 <RRSAgent> RRSAgent has joined #webrtc
15:02:04 <RRSAgent> logging to https://www.w3.org/2025/04/22-webrtc-irc
15:02:04 <Zakim> Zakim has joined #webrtc
15:02:04 <dom> RRSAgent, make log public
15:02:05 <dom> Meeting: WebRTC April 2025 meeting
15:02:05 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/April_22_2025
15:02:05 <dom> Slideset: https://docs.google.com/presentation/d/1weRIFjbNC0Nf-8xUIKP1Fs98HHVB-JyaVmxDXg_xVbg/edit#slide=id.g2bb12bc23cb_0_0
15:02:05 <dom> Chairs: Guido, Jan-Ivar, Youenn
15:02:05 <dom> Present+ Guido, Youenn, Sameer, Jan-Ivar, Dom, RichardBarnes,
15:02:05 <dom> Recording is starting
15:02:25 <dom> Meeting: WebRTC April 2025 meeting
15:02:25 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/April_22_2025
15:02:25 <dom> Slideset: https://docs.google.com/presentation/d/1weRIFjbNC0Nf-8xUIKP1Fs98HHVB-JyaVmxDXg_xVbg/edit#slide=id.g2bb12bc23cb_0_0
15:02:25 <dom> Chairs: Guido, Jan-Ivar, Youenn
15:02:27 <dom> Present+ Guido, Youenn, Sameer, Jan-Ivar, Dom, RichardBarnes,
15:02:27 <dom> Recording is starting
15:03:05 <dom> Present+ OlgaSharonova
15:04:17 <dom> Present+ Carine
15:05:59 <dom> Topic: -> https://github.com/w3c/mediacapture-main/ Media Capture and Streams
15:05:59 <dom> Subtopic: Issue #1019 What is the purpose of requiring a successful gUM call before enumerateDevices?
15:05:59 <dom> [slide 11]
15:09:02 <dom> [slide 12]
15:10:59 <dom> Jan-Ivar: the proposal is a bit different from what I expecte
15:11:03 <dom> s/te/ted
15:11:20 <dom> ... it's common to ask for camera & microphone in a lobby UX prior to the meeting
15:11:46 <dom> ... the Zoom flow is a good use case to solve
15:12:02 <dom> ... I'm not sure about tying it to permissions with all browsers supporting one-time permission
15:12:24 <dom> ... some users may prefer to never persist a permission
15:12:34 <dom> Youenn: you're suggesting to relax the room further?
15:12:51 <dom> Jan-Ivar: right - this would solve the zoom flow not just in Chrome but also in Firefox
15:13:40 <dom> ... the issue is to detect a video conferencing web site where mic/camera sharing is kind of expected; less so on other sites
15:13:46 <dom> Present+ ShinJun
15:14:00 <dom> ... e.g. it could be a Web site where mic & camera have been exposed in the past
15:14:12 <dom> ... (or expose both always)
15:15:20 <dom> ... I don't like the dependency on persistent permissions
15:16:47 <dom> Youenn: my goal was trying to solve a specific issue, not opening new privacy holes - we had something like you described before and got push back that this created surprises
15:17:14 <dom> ... this proposal was narrowly focused on improving interop
15:17:58 <dom> Jan-Ivar: what if added "UA may expose camera devices if they can detect cameras have been used in the past"?
15:18:05 <dom> Youenn: I could go with that
15:18:44 <dom> Guido: Youenn's proposal is an improvement; I think exposing cameras would be surprising to end users, but would be OK if it's a MAY
15:19:10 <dom> ... clarification: is it active usage of gUM or a successful gUM call occured?
15:19:41 <dom> Youenn: I meant the latter (with edge cases to take into account as the current spec does)
15:20:50 <dom> Guido: +1 to the change, but let's make sure we leave UA freedom on determining when to persist permissions
15:22:57 <dom> ... let's adopt this and leave time for implementation experience
15:23:15 <dom> Dom: so you would be comfortable with implementing this for gathering implementation experience
15:23:17 <dom> Guido: yes
15:23:43 <dom> Jan-Ivar: we have a compat issue, where the "Zoom" experience behaves differently between browsers with and without persistent permission
15:23:54 <dom> ... that's where my proposal for the "MAY" clause comes from
15:24:06 <dom> ... I'm happy to iterate on more specific language
15:24:33 <dom> Youenn: we can also discuss with the Zoom folks to understand their needs
15:25:47 <dom> Guido: I'm not sure the status of "returning users" differs when there is no permission
15:26:19 <dom> Jan-Ivar: my focus is on the differences between users with persistent and one-time permissions (and reducing them)
15:27:17 <dom> Guido: I think persistent permissions is a signal of trust that we shouldn't try to override
15:28:19 <dom> Jan-Ivar: in order to get a user to give permission to a mic/camera, you need to let the user pick it, but if they can only be listed if permission has been granted, this is a catch-22
15:28:23 <dom> Present+ PatrickRockhill
15:28:53 <dom> Jan-Ivar: we end up getting user reports on subpar experience for the non-persistent permission workflow
15:28:59 <dom> ... hence my desire to improve it
15:29:41 <dom> RESOLVED: #1019 is ready for a PR with a partial solution as per the proposal, with a MAY for additional relaxing and clarification on successful gUM
15:29:47 <dom> Subtopic: Issue #1035 - Support multiple echoCancellation modes
15:29:47 <dom> [slide 13]
15:32:55 <dom> [slide 14]
15:33:39 <dom> Youenn: a prototype would be nice
15:34:07 <dom> ... I think there was discussion about removing some audio sources from echo cancellation
15:34:16 <dom> ... which would require a more complex Web Audio API
15:34:41 <dom> Guido: the problem is that this only work for audio sources within the Web app - it could come from another web app or another application altogether
15:34:54 <dom> ... so it wouldn't solve all the use cases, and would come with more complexity
15:36:48 <dom> ... my main question is whether supporting the use case of cancelling remote participants or all audio sources is worth doing
15:36:54 <dom> Youenn: that seems worth pursuing
15:37:40 <dom> Jan-Ivar: it seems useful
15:38:28 <dom> ... I'll want to consult with more audio folks at Mozilla
15:38:55 <dom> Guido: I'll prepare an initial proposal to iterate on
15:39:09 <dom> Youenn: in mediacapture-extensions
15:39:24 <dom> RESOLVED: Proceed with a mediacapture-extensions pull request to address this use case
15:39:31 <dom> RRSAgent, draft minutes
15:39:32 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/22-webrtc-minutes.html dom
15:39:41 <dom> Subtopic: Issue #1036 - HTMLVideoElement.currentTime is increasing differently on different UAs
15:39:41 <dom> [slide 15]
15:41:58 <dom> Guido: my impression is that this a Chromium bug
15:42:13 <dom> ... I think it's supposed to work the way Safari and Firefox are implementing it
15:42:58 <dom> Youenn: I'll file a bug
15:43:25 <dom> RESOLVED: Firefox and Safari's behavior is correct and the spec doesn't need an update
15:43:43 <dom> Topic: -> https://github.com/w3c/webrtc-encoded-transform WebRTC Encoded Transform
15:43:43 <dom> Subtopic: Issue #230 - Clarification on "not processing video packets" requested
15:43:43 <dom> [slide 19]
15:43:53 <dom> Present+ BrianBaldino
15:45:38 <dom> [slide 20]
15:47:37 <dom> Harald: rejecting as part of the audio receiver is that it will never change
15:48:28 <dom> ... the inactive transceiver is problematic; not sure there is a point in rejecting a request for a key frame
15:48:37 <dom> Youenn: I don't have a use case
15:49:29 <dom> Jan-Ivar: this LGTM
15:49:39 <dom> RESOLVED: proceed with proposal A
15:49:47 <dom> Subtopic: Issue #244 - Add audioLevel to RTCEncodedAudioFrameMetadata
15:49:47 <dom> [slide 21]
15:51:39 <dom> Youenn: SGTM - it would be apply to both Sender and Transceiver
15:51:41 <dom> Guido: right
15:51:52 <dom> RESOLVED: prepare a PR
15:52:11 <dom> Topic: SFrame
15:52:11 <dom> [slide 24]
15:52:16 <dom> Present+ PeterThatcher
15:54:53 <dom> [slide 25]
15:56:53 <dom> Richard: we're interested in SFrameTransform for our WebEx Web client
15:57:34 <dom> Subtopic: -> https://github.com/w3c/webrtc-encoded-transform/issues/214 Issue #214 - Evaluate how to expose SFrame packetization format to RTCScriptTransform and SFrameTransform
15:57:39 <dom> [slide 26]
15:59:48 <dom> Harald: a year ago we had a proposal for adding encoded frames to O/A through a property to indicate the packetization mode to use
16:00:21 <dom> ... if we have a specific packetization mode for SFrame, using that encoding format allows to use a ScriptTransform that is compatible with SFrame
16:00:35 <dom> ... and the native SFrameTransform would work
16:00:45 <dom> Youenn: a single value per transform sounds better than per frame
16:01:37 <dom> Harald: the proposal for multiple payload types in ScriptTransform describes how to deal with this
16:01:44 <dom> Youenn: this sounds promising, we should revive that effort
16:02:36 <dom> Richard: ScriptTransform could impact packetization in many other ways beyond what can be taxonomized
16:03:03 <dom> ... I wonder if the better solution is not to make this possible via ScriptTransform at all, and leave the proper approach to SFrameTransform
16:03:26 <dom> Youenn: having a way to signal the packetization allows for a nicer migration path from ScriptTransform
16:04:14 <dom> Richard: wrt dichotomoy between payload type vs media type, I think both need to be exposed
16:04:34 <dom> ... the transform needs to know both
16:05:05 <dom> Youenn: indeed; right now we're exposing the payload type which is equivalent to the media type; but SFrame changes this
16:05:17 <dom> Richard: +1 to attaching it to the Transform
16:05:55 <dom> Jan-Ivar: supporting of working on SFrame, and to favoring per transform vs per frame
16:06:53 <dom> Youenn: let's try to make Harald's proposal work
16:07:29 <dom> Harald: I've been working on this - it has required major refactoring on the payload code in libwebrtc
16:08:14 <dom> ... I don't think starting with a Boolean would help
16:08:28 <dom> Youenn: maybe an enum we can extend with additional values to support more use cases
16:08:57 <dom> Harald: the list of possible transforms is shorter than the list of codecs
16:09:20 <dom> ... it would express to the media stack the class of frame it should assume for packetization
16:11:01 <dom> -> https://github.com/w3c/webrtc-encoded-transform/pull/186/files Add description of an API for controlling SDP codec negotiation
16:11:26 <dom> RESOLVED: use PR #186 as the starting point for this discussion
16:11:54 <dom> [slide 27]
16:13:26 <dom> Harald: installing an SFrameTransform should obey normal SDP O/A rules
16:13:36 <dom> ... ie if you want to send SFrame, that should be included in your SDP
16:13:46 <dom> ... and if the other side doesn't support receiving it, you should not send it
16:14:03 <dom> ... SFrame would be treated like any other codec
16:14:39 <dom> Youenn: when you remove a codec, the engine will select the next one;  SFrameTransform can be set before or after negotiation
16:15:05 <dom> Harald: we should require that SFrameTransform sets the negotiation needed flag
16:15:34 <dom> Richard: we need to ensure that if an app expects to use SFrame content, it is only sent if it is so
16:16:08 <dom> Jan-Ivar: treating SFrame as a codec for a negociation it makes sense, but you wouldn't want the UA to choose whether it's on or off
16:16:18 <dom> Richard: but that's consistent with requiring re-negotiation
16:16:32 <dom> Youenn: but you'll need to be negotiate both the media type and the sframe payload type
16:16:55 <dom> Harald: on the sender side, we have a similar case with RED
16:17:22 <dom> ... if you negotiate both RED and Opus with RED first in your prioirty list, you get RED-encoded Opus
16:17:35 <dom> ... if it comes second, it's only signaling ability to receive
16:17:55 <dom> ... for SFrame, we would have to say it has to appear before the media type it would be used on
16:18:45 <dom> Youenn: I agree on the sending side; on the receiving side, not sure
16:19:14 <dom> Harald: I'm not sure how to describe the risk of receiving non-encrypted frames
16:19:36 <dom> Richard: this feels symetric though - there are also expectations on what I receive is encrypted
16:20:05 <dom> Jan-Ivar: endpoints in an SFrameTransform are allowed to do a lot kind of things; the new API Harald is proposing would be optional in any case
16:20:32 <dom> Youenn: so we seem to have agreement on the sender side with dropping frames; not clear on the receiving side yet
16:21:00 <dom> ... we could start working on that part, before coming back to the WG with the receiving side
16:21:21 <dom> Richard: I don't think there are any valid use cases for negotiated both encrypted and not encrypted
16:21:45 <dom> s/negotiated/negotiating
16:22:32 <dom> Youenn: both the payload type and media types would need to be negotiated in the current proposal
16:23:00 <dom> ... we could have a new a-line to say we're only interested in sframe (e.g. a=sframe-only)
16:23:12 <dom> s/.../Peter:/
16:23:25 <dom> Richard: this sounds worth raising the topic to AVTCore
16:23:45 <dom> Harald: with the payload type negotiation for Sframe - it's a hop by hop payload type
16:24:43 <dom> ... we need to resurface this discussion
16:26:29 <dom> Richard: with an SFrameTransform, you should only send sframe-encrypted packets / only process sframe-encrypted received packets
16:27:53 <dom> Youenn: ideally we would define SFrameTransform as a subcase of SCriptTransform
16:28:58 <dom> Dom: SFrameTransform gets you more (better packetization, possibly better trust signal) over what's currently possible with ScriptTransform
16:29:10 <dom> Youenn: and possibly we can make these properties also available to ScriptTransform
16:31:56 <dom> Harald: we may want to consider requiring setting an SFrameTransform ahead of negotiation
16:32:16 <dom> Youenn: please bring your ideas to issue #214
16:32:18 <dom> [slide 28]
16:32:54 <dom> Youenn: SFrame can be used per frame or per packet
16:33:15 <dom> ... currently SFrameTransform only works per frame, but there is a value to the per packet approach
16:33:35 <dom> Richard: in WebEx, we do it per media payload for a couple of reasons:
16:33:42 <dom> ... * it's simpler to set up (?)
16:34:15 <dom> ... * esp for videos, it requires getting the whole frame - losing one packet means losing the frame, and frames can only be processed when all packets have been received
16:34:52 <dom> ... the proposal would be to add support for per-packet to ScriptTransform
16:35:40 <dom> [slide 29]
16:38:49 <dom> Jan-Ivar: leaving ScriptTransform aside, couldn't this be handled transparently with SFrameTransform with a constructor switch?
16:39:04 <dom> Youenn: that's the SFrameTransformOptions proposal
16:39:33 <dom> ... this would work from an implementation perspective, but it kind of breaks the model of WebRTC encoded Transform
16:40:10 <dom> Peter: the API might be more complicated - both options may need to be negotiatable
16:40:25 <dom> ... a bit like bundling in WebRTC-pc
16:40:51 <dom> Jan-Ivar: that ties back to my question on whether SDP negotiation is really needed vs making it possible out of band
16:42:08 <dom> Youenn: my question is first and foremost on the model of WebRTC Encoded Transform which a per-packet approach changes, possibly adding more complexity
16:43:48 <dom> Jan-Ivar: we're supportive of supporting per-packet SFrame, possibly through a switch
16:44:01 <dom> ... pending more clarity on the additional complexity
16:44:33 <dom> Harald: I'm not supportive of mixing these things - shoehorning per-packet in particular in the ScriptTransform model
16:44:50 <dom> ... per-packet things should be hammered out in the RTPTransport API
16:45:21 <dom> ... When it comes to the SFrameTransform, I'm not as critical - I don't think a switch is right way; a different SPacketTransform API would work better
16:46:33 <dom> Jan-Ivar: is it not possible to have SPacket feeding input into a ScriptTransform pipeline?
16:46:59 <dom> Youenn: yes, this would work: the depacketizer would decrypt, construct the frame and pass it to ScriptTransform
16:47:37 <dom> Youenn: re SPacketTransform, would this fit into the existing sender transform API, or something completely different?
16:47:58 <dom> Harald: I think the former should work
16:48:12 <dom> Youenn: the two interfaces would share a lot of similar needs / error management
16:48:47 <dom> Jan-Ivar: this feels like something we can bikeshed
16:48:59 <dom> Youenn: probably with a mix-in interface for shared properties and methods
16:50:17 <dom> Youenn: separately, it seems to me it would be much simpler if SFrame packetization was codec specific
16:50:28 <dom> ... I'll raise an issue to continue that discussion
16:50:42 <dom> RRSAgent, draft minutes
16:50:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/22-webrtc-minutes.html dom
18:28:31 <Zakim> Zakim has left #webrtc