15:49:42 <RRSAgent> RRSAgent has joined #webrtc
15:49:46 <RRSAgent> logging to https://www.w3.org/2023/12/05-webrtc-irc
15:49:46 <Zakim> Zakim has joined #webrtc
15:49:58 <dom> Meeting: WebRTC December 5 2023 meeting
15:49:58 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/December_05_2023
15:49:58 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2023Dec/att-0000/WEBRTCWG-2023-12-05.pdf
15:49:58 <dom> Recording: https://youtu.be/-MB6aFAiHkE
15:49:58 <dom> Chairs: HTA, Jan-Ivar, Bernard
16:00:59 <dom> Present+ PeterThatcher, Bernard, Fippo, SunShin, Florent, Dom
16:01:14 <dom> Present+ Sameer, Henrik
16:02:11 <dom> Present+ StefanHolmer
16:02:22 <dom> Present+ Youenn
16:03:08 <dom> Present+ Carine
16:04:21 <dom> Present+ TonyHerre
16:04:50 <dom> Present+ Jan-Ivar
16:05:24 <dom> Recording is starting
16:05:35 <dom> Present+ Guido
16:05:50 <dom> Present+ Harald
16:06:37 <dom> Present+ Randell
16:06:47 <dom> Present+ Shridhar
16:08:03 <dom> Topic: -> https://github.com/w3c/webrtc-encoded-transform/pull/212 WebRTC-Encoded Transform: Describe data attribute PR #212
16:08:03 <dom> [slide 11]
16:10:31 <dom> Fippo: please review so that we can get it merged
16:11:25 <dom> jan-ivar: thanks for the PR, it looks good to me - doesn't add API surface, only describe current one?
16:11:28 <dom> fippo: correct
16:11:46 <dom> jan-ivar: let's review it in the editors meeting before merging
16:12:18 <dom> harald: good to bring attention to this new information during this meeting
16:13:14 <dom> Bernard: this is valuable information, it shouldn't be normative, but it needs to be somewhere
16:13:46 <dom> jan-ivar: anything that stood out as problematic or unusual when writing this up? e.g. did it reveal concerns with packetization of certain codecs
16:13:58 <dom> hta: the AV1 thing was a surprise
16:14:02 <dom> Topic: -> https://github.com/w3c/webrtc-extensions/ WebRTC Extensions
16:14:02 <dom> Subtopic: PR #175: Add RTCIceTransport method to remove pairs
16:14:02 <dom> [slide 12]
16:14:21 <dom> Sameer: we discussed this in TPAC
16:17:53 <dom> Peter: this looks good - 2 minor remarks:
16:18:20 <dom> ... the array argument makes sense if you 90 candidate pairs to remove, but it makes it more complicated to figure the return value
16:18:59 <dom> ... what's the reason for preventing adding back removed candidate pairs?
16:19:22 <dom> Sameer: you could recreate a pair via remoteAddCandidate(), we don't have a mechanism for the app to add one
16:19:36 <dom> Peter: oh, so the idea is the *browser* doesn't add it back, makes sense
16:20:11 <dom> Bernard: canceling nomination: do you mean remove pair before nomination?
16:20:32 <dom> sameer: relates to the event we added which the app can preventDefault()
16:21:40 <dom> henrik: if performance becomes a concern, it's possible to batch internally the removals
16:21:52 <dom> ... the PR LGTM
16:22:03 <dom> ... no strong feeling re array vs array, but either way can be optimized
16:22:24 <dom> jan-ivar: I don't like the array since I don't think it's necessary, Promise.all can do the batching
16:22:38 <dom> ... restartIce() resets things, right?
16:22:40 <dom> Sameer: right
16:23:00 <dom> jan-ivar: overall this feels a bit like a hack around nomination because nomination may be too strict
16:23:24 <dom> ... we could clarify that this is part of the UA-behavior
16:23:48 <dom> ... I want to make sure we don't overstep anything set in the IETF spec
16:24:03 <dom> Peter: ICE implementations are always free to remove candidate pairs
16:24:16 <dom> Sameer: I'll update the PR in that direction before it hopefully gets merged then, thanks
16:24:47 <dom> Subtopic: -> https://github.com/w3c/webrtc-pc/issues/2170 Issue #2170 Data channel default binaryType value is 'blob'
16:24:47 <dom> [slide 13]
16:24:59 <dom> s/Subtopic:/Topic:/
16:25:02 <dom> RRSAgent, draft minutes
16:25:04 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/05-webrtc-minutes.html dom
16:25:51 <dom> RRSAgent, draft minutes
16:25:53 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/05-webrtc-minutes.html dom
16:25:59 <dom> RRSAgent, make log public
16:26:47 <dom> Present+ TimPanton
16:26:56 <dom> Present+ PaulAdenot
16:27:46 <dom> florent: using Blob to send big files, even if implemented, wouldn't work as is
16:28:18 <dom> Randell: having originally designed this, at this point, I agree switching the default makes sense
16:28:32 <dom> ... it's unfortunate the lack of implementation has gained over the spec
16:28:40 <dom> ... it is possible to send large files with blob
16:29:45 <dom> florent: maxMessageSize doesn't make that practical
16:29:58 <dom> Randell: this can be polyfilled on top of datachannel, but this is water under the bridge
16:30:21 <dom> ... we should take this as a warning to avoid these incompatible implementations that last for so long
16:30:49 <dom> florent: blob implementation would be possible, but switching the default would break web-compat
16:31:09 <dom> Bernard: the slide should say "Firefox" rather than "Safari" shipping blob as default
16:32:00 <dom> RESOLVED: change the default for binaryType to arraybuffer
16:32:34 <dom> Topic: -> https://github.com/w3c/mediacapture-extensions/pull/134 Mediacapture Extensions: latency in Audio Stats
16:32:34 <dom> [slide 14]
16:33:42 <dom> [slide 15]
16:34:38 <dom> Harald: is there a way to figure out when resetLatency was called?
16:34:44 <dom> Henrik: the app knows
16:34:49 <dom> Harald: is reset sync?
16:34:54 <dom> Henrik: yes
16:35:10 <dom> Paul: no objection on my end
16:35:14 <dom> RESOLVED: adopt PR
16:35:55 <dom> Topic: -> https://github.com/w3c/webrtc-nv-use-cases/ WebRTC Extended Use Cases: Low Latency Streaming
16:35:55 <dom> Subtopic: Low Latency Broadcast w/fanout PR #123
16:35:55 <dom> [slide 19]
16:36:18 <dom> [slide 20]
16:36:59 <dom> Bernard: the use cases in 3.2.2 have very different requirements
16:37:15 <dom> ... e.g. very low latency is likely only relevant to sporting events
16:37:39 <dom> ... PR #123 attemps to refocus it on very low latency use cases (auctions)
16:38:04 <dom> [slide 21]
16:39:34 <dom> [slide 22]
16:40:07 <dom> Bernard: ^ proposed new text with PR 123 applied
16:40:21 <dom> -> https://pr-preview.s3.amazonaws.com/w3c/webrtc-nv-use-cases/pull/123.html#auction PR 123 preview of auction use case
16:41:19 <dom> jan-ivar: could we remove "millions" from the use case?
16:41:38 <dom> bernard: sure, more likely relevant in the context of a webinar
16:41:46 <dom> jan-ivar: will add to the PR review
16:42:23 <dom> [thumbs up from folks on the call with going forward with the PR]
16:42:30 <dom> Subtopic: Game Streaming
16:42:30 <dom> [slide 23]
16:43:03 <dom> Bernard: performance is a growing issue, esp in the context of 4K
16:43:06 <dom> [slide 24]
16:43:25 <dom> [slide 25]
16:43:58 <dom> bernard: #103 is feedback from youenn - formulating N37 in terms of API requirements
16:44:04 <dom> [slide 26]
16:44:41 <dom> bernard: PR #125 attempts to do that by referring explicitly to control of hardware acceleration
16:44:55 <dom> ... this relates to discussion we had e.g. about events for hardware failure
16:45:10 <dom> Randell: what does "controlling" mean from a stack perspective?
16:45:29 <dom> Bernard: be able to control whether you specifically want hardware acceleration
16:45:46 <dom> ... Web Codecs has a preferHardware switch
16:46:04 <dom> ... We have an issue to raise events when fail over from hardware to software
16:46:30 <dom> Randell: notification seems useful, but that seems different from this specific requirement
16:47:05 <dom> ... the requirement here seems to be on implementation
16:47:12 <dom> Bernard: no, it's an implementation on the API
16:47:32 <dom> ... part of the issue is not knowing why the failover happened doesn't let developers determine whether they can fix the situation
16:47:51 <dom> Randell: the goal seems right, but the wording remains too fuzzy in terms of requirements
16:48:27 <dom> Henrik: "controlling" is the right word - this isn't just "prefering" for a given codec and leaving it to the UA to decide
16:48:53 <dom> ... the app needs to know what's possible and make a decision based on the available hardware
16:49:19 <dom> randell: so exposing more information about current hardware support for streams that are running and potential hw support for streams that are offered
16:49:52 <dom> Bernard: there is also the big mess around receivable / sendable codecs
16:50:13 <dom> hta: control here is a keyword for "can you do this?", "do this and let me know if you can't"
16:51:17 <dom> jan-ivar: hw control is a requirement today, but it may not be the case tomorrow
16:51:33 <dom> ... maybe we can specify the requirements in a way that makes it clear that it requires hw support today
16:51:58 <dom> randell: hw acceleration is mentioned as an example of a solution in the current language
16:52:24 <dom> jan-ivar: there will be concerns in terms of privacy review
16:52:30 <dom> bernard: please suggest changes to the PR
16:53:07 <dom> jan-ivar: how about "...acceleration if necessary"
16:53:10 <dom> henrik: SGTM
16:53:15 <dom> bernard: +1
16:53:33 <dom> Sun: PR #118 touches on other requirements for game streaming
16:53:39 <dom> [sldie 28]
16:53:44 <dom> s/sldi/slid/
16:53:56 <dom> Sun: we propose 2 kind of requirements: "fast recovery"
16:54:00 <dom> [slide 29]
16:54:09 <dom> ... and 2 requirements for "consistent latency"
16:54:15 <dom> [slide 30]
16:54:28 <dom> Sun: we discussed this during TPAC
16:55:23 <dom> Randell: I support this; when we first designed WebRTC, we purposefully didn't specify what happened in terms of decoding on frameloss
16:56:26 <dom> ... Support for non-full I-frame collections is possible as well
16:56:55 <dom> Bernard: is there any API change surfaced to JS needed to support this?
16:57:15 <dom> ... I could see this needed in the context of WebCodecs, but not sure for WebRTC
16:58:05 <dom> Sun: at minimum, the ability to set a flag on whether to enable fast recovery
16:58:05 <dom> Bernard: not just an SDP parameter then?
16:58:17 <dom> Peter: supporting this would require a large change to libwebrtc video jitter buffer - is that realistic?
16:58:32 <dom> ... rtptransport has custom jitter buffer as a use case
16:59:10 <dom> Jan-Ivar: I'm unsure W3C needs to do something, vs having this being negotiated via SDP with user-agent deciding whether to support it
16:59:24 <dom> Randell: it could be done via SDP, but it feels a bit of a hack
17:00:07 <dom> ... re implementation, having done this in the past, it would indeed require changes in the jitter buffer, but it doesn't seem like a major rewrite, more like a small or medium amount of work to continue decoding while waiting for an i-frame (with errors in the buffers)
17:00:59 <dom> Harald: if it doesn't change the bits on the wire, it shouldn't be done via SDP
17:01:06 <dom> ... so in my mind, it does require an API
17:01:39 <dom> Henrik: if this was possible to do, would there be any reason not to have it on all the time? does it add overhead? does it need a control knob?
17:02:33 <dom> Bernard: there are probably applications that wouldn't want do this, e.g. in the context of a legal case
17:03:00 <dom> Dom: maybe we need a use case for the "off" mode before we say we need it
17:03:13 <dom> Sun: please bring more feedback on github
17:03:25 <dom> [slide 31]
17:04:23 <dom> Bernard: if this is about how to do it, it probably needs discussion in IETF given discussions about how well RPSI works
17:04:48 <dom> ... I'm not sure there is a WebRTC API issue vs implementation or IETF
17:05:11 <dom> ... it's most complicated for conferences (compared to the one-to-one game streaming scenario)
17:05:32 <dom> Sun: so I guess we should remove this req based on that feedback
17:05:42 <dom> Bernard: +1 - let's take it up in IETF, it's an important problem
17:05:45 <dom> [slide 32]
17:07:28 <dom> Bernard: which messages are you interested in getting the interval of? PLI? Receiver reports?
17:07:48 <dom> Shridhar: tranport@@@
17:08:11 <dom> HTA: can this be uplifted a bit? what you want is to have a definitive time limit by when you know if a packet was lost
17:08:29 <dom> ... it might be good better to say that rather than speak of specific RTCP messages
17:08:48 <dom> ... this would make a more concrete requirement that allows different implementations
17:08:57 <dom> Sun: we'll update the requirement in that direction
17:09:00 <dom> [slide 33]
17:10:42 <dom> Randell: how much of this is talking about the API vs the implementation?
17:10:47 <dom> Sun: no API change required here
17:10:57 <dom> Randell: so more of a commentary of the implementation in libwebrtc
17:11:07 <dom> ... not really in scope for the WG
17:11:13 <dom> Sun: thanks for the feedback
17:11:26 <dom> Jan-Ivar: there is an API for jitter buffer target
17:11:40 <dom> Randell: that's mostly to have more delay
17:11:48 <dom> jan-ivar: or less, in theory
17:11:57 <dom> Sun: we'll update the PR based on the discussions
17:12:22 <dom> Topic: -> https://github.com/w3c/webrtc-rtptransport RtpTransport
17:12:22 <dom> [slide 37]
17:13:02 <dom> -> https://docs.google.com/document/d/1cousnS2rmHRH7GEMjWfHTisdUxD2FSVHREbgkbZhuCE/edit#heading=h.2vx6woi9m2uv RtpTransport Reminder
17:13:11 <dom> [slide 39]
17:13:27 <dom> [slide 40]
17:14:14 <dom> [slide 41]
17:15:20 <dom> [slide 42]
17:15:46 <dom> [slide 44]
17:16:35 <dom> [slide 45]
17:17:20 <dom> Peter: 3 possible general directions I want to review today
17:17:52 <dom> [slide 46]
17:18:59 <dom> [slide 47]
17:20:53 <dom> [slide 48]
17:21:08 <dom> [slide 49]
17:22:07 <dom> [slide 50]
17:22:37 <dom> [slide 51]
17:23:15 <dom> Harald: another dimension is whether you can talk to existing end points
17:23:48 <dom> ... you can't with the new datachannel - in which case, what's the advantage over using WebTransport or Quic
17:24:08 <dom> ... the piecemeal approach doesn't need to be complex for the simple case - you just let through the things you don't want to modify
17:24:31 <dom> ... as long as you stay within certain parameters, you can talk to people that are not you, which I like
17:24:48 <dom> ... you can talk with endpoints that talk basic SRTP
17:25:08 <dom> ... it provides for incremental deployments and incremental implementations, by focusing on the particular function we care about today
17:25:28 <dom> Peter: you're correct with regard to the new datachannel speaking to existing end points
17:25:47 <dom> ... in terms of Quic - they're not P2P in the browser today; we could fix that
17:26:00 <dom> ... I agree with your points re piecemeal
17:26:35 <dom> Jan-Ivar: in my slides, I'm not proposing an rtp data channel, I agree with the limitations you and Harald have pointed out
17:26:55 <dom> ... I think we should only expose RTP as needed (maybe that points toward piecemeal)
17:27:06 <dom> ... we need to understand better the scope of the problems we want to address
17:27:58 <dom> Peter: so hearing more support for piecemeal (bit by bit adding to the existing API, but with likely a low level API)
17:28:18 <dom> ... I've done some exploration in this space
17:29:39 <dom> Bernard: dall-e did a good job representing the data channel proposal being an isolated island
17:29:46 <dom> ... I would not favor that
17:30:09 <dom> ... re piecemeal customization - if you can get the flexibility without the complexity, this would be ideal
17:30:18 <dom> ... but we have to demonstrate it
17:30:34 <dom> ... the incremental deployability is also appealing
17:31:42 <dom> Youenn: another vote for piecemeal - a web site should be able to override some parts of the pipeline, but with the UA taking over at some point
17:32:12 <dom> ... complexity is an important consideration
17:32:34 <dom> ... we've approached this by exposing injection points into the pipeline, we should continue with that approach
17:33:02 <dom> ... we should compare with the approach we're exploring in encoded-transform or to bring web codecs in
17:33:58 <dom> Henrik: another benefit of piecemeal is in terms of shipping it from an implementation perspective; not enough expertise on RTP to say much more
17:34:16 <dom> Subtopic: Issue #9 Customizing piecemeal
17:34:17 <dom> [slide 53]
17:34:46 <dom> Peter: if we go with piecemeal, this can be done - suggest following the taxonomy in rfc 7656, most importantly RtpStream
17:34:56 <dom> ... building on top of that
17:35:00 <dom> ... will flush this out more
17:35:35 <dom> Bernard: some of this would be around custom FEC/custom RTX scenarios?
17:36:31 <dom> Peter: right; I have explored a number of scenarios with that approach
17:37:02 <dom> Stefan: would you insert packets into these RtpStream objects?
17:37:31 <dom> Peter: capture what has been sent, allow it through if you're not customizing, or modifying it and injecting it back
17:37:46 <dom> ... with lots of implication in terms of congestion control - it gets complex but I think it's feasible
17:38:27 <dom> Harald: once you allow to insert packets then you can generate packets yourself, in either direction
17:39:08 <dom> Peter: absolutely; this is a superset of what I presented to TPAC in that sense
17:40:06 <dom> Jan-Ivar: I'm worried by "full piecemeal customisation" - I don't think we need to go to the extreme low level of exposing everything of the RFC on RTP
17:40:39 <dom> Peter: to be clear, I'm only asserting something is feasible, not any API shape
17:40:55 <dom> ... I'll come back with more specific API proposals, and others can make proposals as well
17:41:34 <dom> Henrik: I get similar vibes to encoded transform from this slide
17:41:50 <dom> ... which has proved a powerful pattern
17:41:57 <dom> Subtopic: Issue #10: SDP Bumper lanes
17:41:58 <dom> [slide 54]
17:42:26 <dom> Peter: if we go with piecemeal, I think we'll end up with lightly enforced bumper lanes
17:43:36 <dom> Bernard: Harald raised a concern with avoiding interferences with the existing peerconnection; this looks to be in the good direction
17:44:06 <dom> Peter: this may depend on whether we allow creating transports outside of a peerconnection
17:44:42 <dom> Harald: I think there should be an API for reserving things, e.g. to reserve an SSRC
17:45:28 <dom> ... the API might expose names (e.g. extensions by URIs) rather than by numbers which avoids the issue of conflicts
17:45:46 <dom> Peter: +1; interesting idea on names vs numeric ids
17:46:16 <dom> Harald: I'm hitting this with fanout land where we're discussing using mime types rather than payload types
17:46:25 <dom> Subtopic: Issue #7: SRTP/cryptex support
17:46:25 <dom> [slide 55]
17:47:31 <dom> Peter: with piecemeal, I think we could just rely on the outcome of the SDP negotiation
17:48:11 <dom> Bernard: we have a cryptex API in webrtc-extensions; if the other side supports cryptex, encrypting everything seems sufficient granularity, don't see value in per-packet control
17:48:18 <dom> Subtopic: Issue #13: Workers
17:48:18 <dom> [slide 56]
17:48:59 <dom> Peter: if there is a e.g. an RtpStream interface, we would need to ensure it is transferable - that sounds doable
17:49:39 <dom> Harald: SGTM; remember that when you transfer, you transfer one end of the tube; what's at the other end stays attached to where it was originally, which may have implication on implementation
17:50:28 <dom> Bernard: we support transferable stream, but would RtpStream be a WHATWG stream?
17:50:58 <dom> ... transfering individual objects may not be the right thing; e.g. for custom NACK needs both dealing with receiving Rtp and sending RTCP
17:51:09 <dom> ... you need a combination of read and write streams
17:51:31 <dom> ... this depends a lot on whether we use WHATWG streams or not
17:51:45 <dom> Peter: we need to figure the specific things that people would want to use in workers
17:51:58 <dom> ... you're right that RTCP is tricky
17:52:06 <dom> Bernard: we also need to figure which workers we need to support, e.g. audio worklets
17:52:42 <dom> Jan-Ivar: time-check?
17:53:11 <dom> Peter: ok - we'll need to look at some of the other issues
17:53:35 <dom> ... re WHATWG streams, I think this can be decided at a later stage once we have figured out the more fundamental question
17:53:58 <dom> Subtopic: WHATWG streams
17:54:04 <dom> [slide 63]
17:54:41 <dom> (issue #8)
17:55:00 <dom> [slide 64]
17:55:52 <dom> [slide 65]
17:58:20 <dom> [slide 66]
17:59:17 <dom> [slide 67]
18:01:24 <dom> Harald: transform has proved a limiting model - a transform is combining a sending and receiving API together
18:01:37 <dom> ... we should try to reduce the coupling between components, not increase it
18:02:41 <dom> Bernard: more work needed on this API; we talked about having a design team to work on this to advance more quickly on this in the general meetings
18:02:55 <dom> ... and advance the explainer and specs into more fleshed out states
18:03:00 <dom> ... next meeting next week
18:03:08 <dom> RRSAgent, draft minutes
18:03:09 <RRSAgent> I have made the request to generate https://www.w3.org/2023/12/05-webrtc-minutes.html dom
19:30:03 <Zakim> Zakim has left #webrtc