IRC log of webrtc on 2023-12-05

Timestamps are in UTC.

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]
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