16:00:38 <RRSAgent> RRSAgent has joined #webrtc
16:00:42 <RRSAgent> logging to https://www.w3.org/2024/02/20-webrtc-irc
16:00:42 <Zakim> Zakim has joined #webrtc
16:00:52 <dom> Meeting: WebRTC February 2024 meeting
16:00:52 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/February_20_2024
16:00:52 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2024Feb/att-0008/WEBRTCWG-2024-02-20.pdf
16:00:52 <dom> Chairs: HTA, Jan-Ivar, Bernard
16:02:17 <dom> Present+ Bernard, Harald, Peter, Youenn, Fippo, Guido, Jan-Ivar, Carine, Dom, TimP, SunShin
16:03:52 <dom> Recording is starting
16:04:22 <dom> Present+ PatrickRockhill
16:04:54 <dom> Scribe+
16:06:17 <dom> Topic: -> https://github.com/w3c/webrtc-pc/ WebRTC API
16:06:17 <dom> Subtopic: Issues with receive-only codecs #22
16:06:17 <dom> [slide 11]
16:06:40 <dom> Bernard: not a WebRTC issue - it came up in IETF AVTCORE wrt receive-only codecs
16:06:47 <dom> Present+ Elad
16:08:04 <dom> s|#22|https://github.com/aboba/hevc-webrtc/issues/22
16:08:31 <dom> Subtopic: Modify the codec description model to ease describing changes #2925 #2935
16:08:31 <dom> [slide 12]
16:11:17 <dom> [slide 13]
16:12:24 <dom> [slide 14]
16:13:08 <dom> Harald: is this a reasonable direction to go in?
16:13:37 <dom> Bernard: it is; the more I read, the more current situation doesn't make sense, with too much unspecified, so this is a good step forward
16:13:55 <dom> Present+ Florent
16:14:19 <dom> Jan-Ivar: overall it makes sense to add more details to it and it will help having a more neutral baseline
16:14:40 <dom> ... we need to keep track of fingerprinting concerns, but we should be aligning with Media Capabilities in any case
16:14:46 <dom> ... this looks like an improvement to me
16:15:14 <dom> Bernard: Media Capabilities doesn't have any way to look at directionality except encoder/decoder - not sure if it's a good match
16:15:37 <dom> Harald: you have to make two calls to media capabilities to figure what you can send/received
16:16:06 <dom> bernard: so you're confident that encoder/decoder matches send/receive? we should test it too
16:16:25 <dom> Harald: hearing no push back, we'll bring this as candidate to merge at the editors meeting on Thursday
16:16:32 <dom> Subtopic: Should media capabilities influence what is exposed in what is exposed in WebRTC offers and answers #2929
16:16:32 <dom> [slide 15]
16:17:04 <dom> Youenn: more and more codecs get exposed on the Web and in WebRTC
16:17:46 <dom> ... for playback, media capabilities allow to control how much information gets exposed to the web site
16:17:58 <dom> ... for WebRTC, everything gets exposed via getCapabilities or via SDP
16:18:16 <dom> ... this is a fingerprinting issue, but also has an impact on the number of allocated payload types
16:18:47 <dom> Harald: not all codecs get exposed, but they can be discovered through setLocalDescription
16:19:09 <dom> Youenn: getCapabilities was initially designed to expose everything supported, but it would be best to deprecate it
16:19:19 <dom> ... can we move to use media capabilities as a replacement?
16:19:24 <dom> [slide 16]
16:21:32 <dom> Youenn: please chime in in #2929 too
16:22:08 <dom> Bernard: this makes sense for the simpler codecs à la VP8, VP9, AV1, but e.g. HEVC raises weird situations
16:23:05 <dom> ... say I query a common level that can be used for encoding/decoding, how would this impact the whole offer/answer negotiation?
16:23:25 <dom> Youenn: the idea would be that media capabilities would give you WebRTC-specific data that could be plugged into the WebRTC API
16:24:10 <dom> Bernard: but for these send-only or receive-only situations across levels...
16:24:25 <dom> Youenn: SDP can't express all these situations
16:24:38 <dom> ... this wouldn't be an improvement, but it doesn't make things worse
16:24:57 <dom> ... and at least, the web app would know what's not available e.g. on the decoding side
16:25:06 <dom> TimP: I like this - it feels overdue
16:25:25 <dom> ... the UA-to-UA disadvantage doesn't feel too serious
16:25:49 <dom> ... the only issue I have is how precise the query would have to be e.g. on which submode of which profile of a codec
16:26:04 <dom> ... esp since UA are known to lie on some of these questions
16:26:42 <dom> Bernard: indeed, e.g. with H264 and 265
16:26:53 <dom> Youenn: this profile complexity would be in scope indeed
16:27:19 <dom> Harald: it's probably good to link webrtc and media capabilities codec more closely
16:27:41 <dom> ... Youenn has a PR to have media capabilities return a WebRTC shape for doecs when queried
16:27:53 <dom> ... to ensure it is inspectable and usable in WebRTC land
16:28:07 <dom> ... it's good to have the default set of codecs be implementation defined
16:28:27 <dom> ... if we have a codec that is universally supported by a given platform, it doesn't expose much fingerpriting surface to expose it
16:28:32 <dom> s/pri/prin/
16:28:55 <dom> Youenn: I'll revive the Media Capabilities proposal
16:29:25 <dom> Jan-Ivar: I'm also supportive; reducing fingerprinting surface feels good, or at least reducing the list to a default list
16:30:15 <dom> Youenn: I'll work on an API proposal to tie Media Capabilities and WebRTC - not sure yet if it's at the transceiver level, please bring input on the issue
16:30:26 <dom> Harald: the codec model description will help as well for this
16:30:40 <dom> Subtopic: Existing setCodecPreferences NOTE is wrong and should be deleted #2933
16:30:41 <dom> [slide 17]
16:31:57 <dom> Fippo: if no objection, I'll bring a PR and a WPT test
16:32:06 <dom> Bernard: I agree it's extraneous
16:32:14 <dom> Subtopic: setCodecPreferences to deal with both send and recv codecs #2939
16:32:14 <dom> [slide 18]
16:33:31 <dom> [slide 19]
16:35:15 <dom> Bernard: I'm not sure this is entirely right given that it's based on a JSEP paragraph that looks like it may be wrong
16:35:55 <dom> ... sendrecv, sendonly, recvonly are 3 separate sets that setCodecPreferences gives order to
16:36:06 <dom> ... when changing direction, you're shifting to a different set
16:36:30 <dom> ... it's not clear that the preferences can survive such a shift
16:36:38 <dom> Fippo: JSEP is confusing in that area
16:36:51 <dom> ... it only talks about sendrecv, not the two other sets you're alluding to
16:37:06 <dom> ... it may be challenging to change this in terms of web compatibility though
16:37:47 <dom> Jan-Ivar: regardless of what JSEP says, it would be desirable if we kept sCP and direction change orthogonal
16:38:31 <dom> ... this could be addressed by having a super list that is filtered; if the filter ends up with an empty list, I'm a bit wary about throwing, although this does feel like a mistake
16:39:10 <dom> Harald: changing direction after you have configured the codec influences the set of codecs available
16:40:23 <dom> ... if we require at least one sendrecv codec, we are safe, and adding recvonly codecs is also safe
16:40:57 <dom> ... this is a painful aspect of SDP - we should just admit failure on the sendonly case and figure out the least painful approach to deal with - maybe the last option
16:41:21 <dom> Fippo: if we have nothing in common, the regular approach would be to reject the m-line, hence my preference for the 3rd option
16:41:42 <dom> ... should we wait for a JSEP change in this space?
16:41:53 <dom> Bernard: I think we should come up with a proposal for JSEP
16:42:57 <dom> Fippo: OK, will bring this back at the next meeting after more off-line discussions
16:43:08 <dom> Topic: -> https://github.com/w3c/mediacapture-screen-share/ Screen Capture
16:43:08 <dom> [slide 22]
16:43:38 <dom> Bernard: the WPT results for Screen Capture shows little adoption for capture controller
16:44:07 <dom> Jan-Ivar: lots of green (getDisplayMedia works in all browsers), the red parts are for the new capture controller API
16:44:19 <dom> ... some red on iframe delegation, but the big difference is capture controller
16:44:35 <dom> ... it's not controversial, but hasn't been implemented outside of Chrome yet
16:44:47 <dom> ... it's not on FF's short term roadmap
16:44:54 <dom> Youenn: likewise for Safari
16:45:23 <dom> ... we discussed a similar issue in Media WG - moving to CR would still be beneficial
16:45:28 <dom> Jan-Ivar: +1
16:45:55 <dom> Subtopic: Issue triage and milestones
16:45:59 <dom> [slide 24]
16:47:54 <dom> Jan-Ivar: please chime in if you feel the assignment of issues to milestones need adjustment
16:48:04 <dom> Subtopic: Should we have a screenshare extension spec? #297
16:48:07 <dom> [slide 25]
16:50:14 <dom> Youenn: I think it makes sense; in the Media WG, it was advised that an extension spec is more complex and needs more work for editors, but from the point of view for web developers, it clarifies what is mature and what isn't
16:50:40 <dom> ... if it's not useful for developers, then maybe a forever CR would be a better model
16:51:53 <dom> TimP: do we think realistically it will help? are the 12 enhancements really blocking? are the 19 issues solvable in a reasonable timeframe?
16:52:08 <dom> Jan-Ivar: I think it will help because the enhancement are real additional features
16:52:20 <dom> Elad: +1 if it helps with making progress on issues
16:52:52 <dom> TimP: but do we thinkg the 19 CR issues are solvable in a sensible timeframe?
16:53:11 <dom> Jan-Ivar: yes
16:53:23 <dom> Elad: there may also be issues that shouldn't be considered as CR blocking
16:54:14 <dom> Jan-Ivar: getDisplayMedia mostly works, and separating what's additional value would help
16:54:35 <dom> Bernard: +1 that they're addressable, and they would allow to get e.g. more focus on privacy issues
16:54:47 <dom> Jan-Ivar: hearing mostly agreement this would be the right path forward
16:55:23 <dom> Elad: when do we want to lock the list of issues as CR-blocking?
16:55:51 <dom> Jan-Ivar: I think we can start moving issues over to the new repo right away, and move them back if needed
16:56:07 <dom> ... and then we have to do the work to close the 19 issues
16:56:13 <dom> Subtopic: Distinguish cancellations from absent OS permissions #281
16:56:16 <dom> [slide 26]
16:59:21 <dom> Elad: this is a problem worth solving; this sounds like a possible solution, wonder if we could improve it
16:59:38 <dom> ... i.e. the spec isn't explicit on this, would be useful to make it so
17:00:06 <dom> ... also not sure NotFoundError isn't the most explicit expression
17:01:23 <dom> ... e.g. we could define a new error with a more specific type
17:01:23 <dom> Jan-Ivar: in general, there is generally pushback against defining new custom errors
17:01:23 <dom> ... and prefer re-using existing DOM errors even if they're not a perfect fit
17:01:47 <dom> ... I'm not too concerned about this imperfect fit
17:02:23 <dom> Youenn: NotFoundError feels like a reasonable minimal API already in use; in terms of ergonomics, I think it's ok as long as the spec is very explicit about this interpretation of NotFoundError
17:02:50 <dom> Jan-Ivar: +1 to making this explicit in the spec
17:04:21 <dom> Elad: can we make it that NotFoundError be restricted to this? e.g. in a situation where constraints would limit shareable surfaces?
17:04:48 <dom> Jan-Ivar: it sounds like NotFoundError would still be a reasonable fit for that situation, but that feels like an edge case
17:04:56 <dom> Elad: fair, we can leave that question aisde
17:05:00 <dom> s/ais/asi/
17:05:57 <dom> ... could we still allow UA-dependent subclassing?
17:06:36 <dom> Dom: that would lead to non-interoperable behavior
17:07:02 <dom> Youenn: re OS permissions, I'm not sure that's a well-defined concept for the platform
17:07:17 <dom> ... we should check what's being used e.g. in HTML or Permissions
17:07:58 <dom> Jan-Ivar: maybe this is a clarification to bring to mediacapture-main on "no sources of type T are available" with a parenthesis that describes these examples
17:09:04 <dom> s/main/screenshare
17:09:43 <dom> Jan-Ivar: would we want to apply to this mic/cameras? knowing that they could be distinguished from no hardware with enumerateDevices()
17:09:58 <dom> Guido: for OS permissions in camera/mic, we use notallowederror with a different message
17:10:47 <dom> Elad: enumerateDevices() isn't 100% robust to make the distinction given that users can plug/unplug devices
17:11:08 <dom> RESOLVED: Move forward with a PR to clarify that NotFoundError would apply for OS permissions in screen-capture
17:11:22 <dom> Jan-Ivar: I'll file an issue for a follow up discussion on mediacapture-main
17:11:51 <dom> Elad: aligning the two would be best (although not fully required)
17:13:17 <dom> Topic: -> https://github.com/w3c/mediacapture-record/ MediaStream Recording
17:13:17 <dom> [slide 29]
17:13:43 <dom> Bernard: WPT shows tests with limited support
17:14:30 <dom> Youenn: Safari doesn't support webm recording; not sure about mp4
17:14:55 <dom> dom: I don't think there are codecs requirements in recording - if so, codec specific tests should be marked as optional
17:15:29 <dom> [slide 30]
17:16:06 <dom> Jan-Ivar: overall numbers are looking pretty good
17:16:34 <dom> Youenn: not sure why there are codec/format-specific tests e.g. for stop()
17:17:05 <dom> [slide 31]
17:20:01 <dom> Bernard: I support this; WebCodecs is indeed the way forward for many of the requested enhancements for recorder
17:21:35 <dom> [no objection raised to proceeding with that plan]
17:21:43 <dom> [slide 32]
17:22:30 <dom> Bernard: this could simply quote media capabilities spec
17:22:52 <dom> Jan-Ivar: we could return a fixed list as Youenn suggested earlier in the webrtc case
17:23:02 <dom> ... this would solve the privacy issue neatly here
17:23:06 <dom> Bernard: wfm
17:23:08 <dom> Youenn: +1
17:24:20 <dom> Dom: it needs to stay in the spec for web compat, but should be described as returning fixed answers and its usage discouraged
17:24:35 <dom> Topic: Media Capture specs
17:24:35 <dom> Subtopic: Issue triage and milestones of Media Capture and Streams
17:24:35 <dom> [slide 35]
17:25:41 <dom> Jan-Ivar: we would like to see more activity in this spec to accelerate progress towards Rec
17:26:11 <dom> Subtopic: -> https://github.com/w3c/mediacapture-fromelement/issues/65 captureStream on OffscreenCanvas on
17:26:11 <dom> [slide 37]
17:28:55 <dom> Youenn: no objection - but feels like low priority, not sure there is much web developer demand for this
17:29:29 <dom> Harald: offscreencavas has usages, not all of them in workers
17:29:45 <dom> ... this isn't related to mediacapture-main though?
17:30:31 <dom> ... the only relation is the availability on MediaStream on workers
17:31:03 <dom> Jan-Ivar: yes, that's the next issue I wanted to discuss, since answering yes to this would give an answer to this
17:31:17 <dom> Jan-Ivar: not hearing objection, nor much interest either
17:31:37 <dom> Subtopic: -> https://github.com/w3c/mediacapture-extensions/pull/26 Expose MediaStream in Workers
17:31:37 <dom> [slide 38]
17:33:41 <dom> Jan-Ivar: not hearing objection on this either
17:33:47 <dom> Dom: (but not much excitement either)
17:33:56 <dom> Subtopic: -> https://github.com/w3c/mediacapture-main/issues/974 How should MediaStreamTrack interact with BFCache?
17:33:56 <dom> [slide 39]
17:37:27 <dom> Youenn: +1 to this proposal; not just because that's Safari current behavior, but also because it will help with getting web sites handle device failure situations better
17:37:56 <dom> ... would like us to be more proactive on pushing outreach for this
17:38:33 <dom> Harald: I've had a lot of discussions on BF-cache in the context of peerconnection where we're trying to make WebRTC more BF-cache friendly
17:39:00 <dom> ... This sounds nice, but I think I'll want to think this through some more
17:39:13 <dom> Youenn: this is indeed also worth discussing for WebRTC-PC
17:39:53 <dom> Harald: let's keep discussing this in the issue, want to hear from Guido
17:40:11 <dom> Guido: +1
17:40:56 <dom> Youenn: I'll file an issue in webrtc-pc on BF-cache friendliness
17:41:10 <dom> Subtopic: -> https://github.com/w3c/mediacapture-main/pull/988 Add guidance for defining a new source of MediaStreamTrack
17:41:10 <dom> [slide 40]
17:41:46 <dom> Jan-Ivar: this PR adds clarifications to what muted and ended for other sources of tracks
17:44:32 <dom> [slide 41]
17:44:59 <dom> Guido: +1 on the generic guidance; the mic/camera language needs more discussion
17:46:39 <dom> Youenn: proposed language sounds good to me; we should review our source-defining specs to make sure they're consistent with that guidance
17:47:07 <dom> Jan-Ivar: yes, let's file these issues before landing that PR
17:47:40 <dom> ... will get that done before the next Editrs meeting
17:47:48 <dom> RRSAgent, draft minutes
17:47:49 <RRSAgent> I have made the request to generate https://www.w3.org/2024/02/20-webrtc-minutes.html dom
17:49:34 <dom> RRSAgent, make log public
19:27:19 <Zakim> Zakim has left #webrtc