16:06:01 <RRSAgent> RRSAgent has joined #webrtc
16:06:01 <RRSAgent> logging to https://www.w3.org/2022/12/07-webrtc-irc
16:06:07 <dom> scribe: hta
16:06:14 <dom> regrets+ Dom
16:08:39 <hta> ... survey shows strong support for use of async funtions
16:09:24 <hta> ... most devs munge SDP
16:10:40 <hta> ... 1/3 of respondents don't use datachannels
16:10:57 <hta> ... many want to do datachannels in workers
16:12:02 <hta> ... survey was anonymous (collecting ID would need GDPR stuff)
16:13:32 <hta> ... API regarded as complex or very difficult by most
16:13:47 <karstenboehm> karstenboehm has left #webrtc
16:15:08 <hta> ... survey was focused only on JS APIs, not native
16:17:04 <hta> bernard, youenn: SDP munging was the biggest surprise / learning
16:17:52 <hta> Tim: we should look to other APIs to see if there are patterns we could adopt
16:20:15 <hta> youenn: devtools? WebInspector?
16:21:12 <hta> bernard: want to know if there are a few things in SDP munge or many
16:21:28 <hta> jan-ivar: not all APIs that avoid SDP munging are implemented in all browser
16:23:39 <hta> fippo: 10% of SDP munging is to achieve stereo in Chrome. we don't know who.
16:25:15 <hta> fippo: will produce a list of things people can do / are doing with SDP munging.
16:26:32 <hta> Tim: should we adopt methods / tricks / constructs from other APIs?
16:27:46 <hta> ... Maybe, but not urgently.
16:29:25 <hta> Bernard: Presenting scenarios for CfC
16:34:19 <hta> hta: 3.2.1 requirements should be in terms of desired results, not in terms of how to achieve them.
16:35:45 <hta> youenn: do we want ability to inject JS in the media pipeline, or is latency too critical?
16:37:13 <hta> tim: need API to match up server stuff with client stuff
16:39:42 <hta> Bernard presents 3.2.2
16:42:04 <hta> youenn: points out that N39 kind of presupposes that we want to use RTP
16:44:27 <hta> youenn: not clear whether this is frame level or packet level
16:44:59 <hta> hta: that choice may be part of the solution space rather than the requirement space
16:45:30 <hta> jan-ivar: could also consider the case of within-browser relay (no js).
16:47:27 <hta> pthatcher: running over datachannel gives worry with congestion control.
16:47:49 <hta> bernard: people have done over datachannel, with custom code sender-side.
16:48:53 <hta> Bernard presents 3.5 Virtual reality gaming
16:49:35 <hta> youenn: pre-sending video frames & metadata may be requirements. Reach out to XR?
16:50:58 <caribou> Harald's presentation on issue 106
16:51:25 <caribou> hta: original use case was e2ee
16:52:29 <caribou> ... slide 28
16:52:45 <caribou> ... this is Bernard's summary
16:53:39 <caribou> Tim: it's not necessary about slowing or speeding things
16:54:01 <caribou> hta: [slide 29]
16:55:01 <caribou> ... request from people feeding H264 to a browser using something else than webRTC, that they want to send over RTP
16:55:30 <caribou> ... we can do that without using the encoder
16:56:07 <caribou> bernard: I heard that use case for traffic cameras
16:57:30 <caribou> jan-ivar: it's hard to gauge if it can't be done with the existing APIs
16:57:57 <caribou> youenn: I'm still fuzzy about this UC
16:58:21 <caribou> ... it seems that one node in the network is producing H264 and it gets sent to a browser
16:58:45 <caribou> ... I'm not sure why there should be a browser in the middle between the sender and the RTP
16:59:08 <caribou> bernard: it's coming over HTTP most of the time
16:59:35 <caribou> youenn: it's not the typical browser use
16:59:50 <caribou> ... the context would help understanding the UC
17:00:11 <caribou> hta: the summption is that the camera is not supported by GUM
17:00:20 <caribou> s/summ/asum/
17:00:31 <caribou> s/GUM/gUM
17:00:49 <caribou> jan-ivar: is the UC supporting traffic cameras in the browser?
17:01:17 <caribou> ... how do you feed to the browser?
17:02:29 <caribou> Tim: it would be nice to have something to prevent re-encoding
17:02:56 <caribou> ... If you have an in-car camera with limited BW to a monitoring station
17:03:25 <caribou> ... and that station is a browser, but you want to share the feed to someone else over webRTC
17:03:48 <caribou> ... rendering + capturing/sending is overkill
17:04:35 <caribou> jan-ivar: if low latency is the goal (thus sending to RTP), @@@
17:05:21 <caribou> hta: if you take away h264, there are other solutions
17:05:35 <caribou> hta: [slide 30]
17:06:38 <caribou> ... this UC is pre recorded media sent to RTP
17:08:12 <caribou> youenn: I don't understand why the desired tranceiver would be RTP
17:08:33 <caribou> ... for that UC to be meaningful you need to know why RTP is better
17:08:55 <caribou> hta: the scenario could be that you already have an RTP cnx
17:09:02 <caribou> ... e.g. live video
17:09:24 <caribou> ... then you want to send pre-recorded video, without the receiving side having to do anything
17:09:43 <caribou> jan-ivar: you could do this using the video track generator
17:09:58 <caribou> ... you could decode the pre-recorded
17:10:14 <caribou> ... so this (proposal) is an optimization
17:11:06 <caribou> hta: we can switch to key frames. it's UC dependent whether we want the browser to do it
17:11:30 <caribou> bernard: there might also be battery-life optimizaiton
17:11:56 <caribou> youenn: it would be good to comment in the issue if we're targeting optimization
17:12:03 <caribou> hta: please comment
17:12:24 <caribou> Peter: [slide 31]
17:14:17 <caribou> youenn: should we have an API that controls at the packet-level or an API at the encoder side
17:14:41 <caribou> ... I think we be trying to do both in the same API and it's too difficult
17:15:02 <caribou> ... are there 2 different sets of UCs, e.g. low-latency and other optimizations
17:15:12 <caribou> Peter: maybe true
17:15:51 <caribou> youenn: webRTC NV could have those UCs and requirements, do we need packet data API, or frame
17:16:18 <caribou> Peter: @@@@ audio codecs
17:16:43 <caribou> youenn: look at what we expose
17:17:18 <caribou> Topic: Encoded media manipulation
17:18:08 <caribou> hta: [slide 35]
17:19:17 <caribou> hta: [slide 36]
17:20:29 <caribou> hta: [slide 37]
17:22:08 <caribou> hta: [slide 38]
17:23:13 <caribou> hta: I'd like to have a Call for Consensus on the low latency streaming UC
17:24:18 <caribou> Tim: you need to have a rough flavor of an API
17:25:01 <caribou> ... who are targeted audiences? does that fit naturally with codecs?
17:25:15 <caribou> ... at least describe that is useful
17:25:41 <caribou> hta: the obvious APIs to fit next to are webRTC APIs and webCodec APIs
17:26:01 <caribou> jan-ivar: we don't have to agree to incremental APIs
17:26:49 <caribou> hta: if I have something that is part of solution, we don't need the entire solution before pushing it
17:27:22 <caribou> jan-ivar: it sounds OK but I don't think we need to commit to this approach
17:27:34 <caribou> ... in advance
17:27:59 <caribou> youenn: i'd echo what Tim said, we need to understand the big picture of what we're trying to solve
17:28:26 <caribou> ... and I agree it's good to look at webCodec APis
17:29:03 <caribou> ... webRTC encoded transform is fine
17:29:27 <caribou> ... we should design the best API, not the API that needs the less work for the User Agent
17:29:44 <caribou> Topic: issue 143/PR 165
17:30:01 <caribou> Fippo: the proposal is to merge PR 165
17:30:19 <caribou> ... [slides 43-44 showing the PR]
17:30:32 <caribou> hta: I agree
17:30:57 <caribou> youenn: we discussed rids but not the return value
17:31:24 <caribou> ... the return value is useful to validate the input
17:32:07 <caribou> ... the promise makes sense for the transformer
17:32:25 <caribou> ... I don't have a strong opinion for the sender
17:32:52 <caribou> fippo: you can wait and read the key frame
17:33:08 <caribou> youenn: with the promise you can reject asynchronously
17:33:14 <caribou> ... it helps a bit
17:33:33 <caribou> jan-ivar: the PR removes a lot of the algo. text
17:34:07 <caribou> youenn: the text detailed all the cases
17:34:24 <caribou> ... if you remove the promise resolution you can simplify a lot
17:34:40 <caribou> jan-ivar: we may not merge PRs during meetings
17:34:58 <caribou> youenn: we did not yet agree about the return value
17:35:11 <caribou> ... so we need to decide
17:35:34 <caribou> bernard: objection to no return value?
17:35:57 <caribou> youenn: original proposal was a promise
17:36:17 <caribou> ... safari implements the promise undefined
17:36:36 <caribou> hta: no objection to using that
17:36:45 <caribou> Topic: issue 167
17:36:55 <caribou> fippo: [slide 45]
17:37:30 <caribou> ... proposal is to add timing metadata
17:37:49 <caribou> ... currently only things derived from rtp header
17:38:43 <caribou> bernard: this is an issue, we try to give a direction
17:39:06 <caribou> youenn: I have not looked beforehand, no input yet
17:39:18 <caribou> fippo: pls leave feedback on the issue
17:39:30 <caribou> Topic: issue 168
17:39:42 <caribou> fippo: [slide 46]
17:40:27 <caribou> ... I'd like to add rtp header metadata
17:40:54 <caribou> hta: are they read only?
17:41:45 <caribou> fippo: [slide 47]
17:42:23 <caribou> ... [slide 48]
17:42:38 <caribou> ... the PR is only for audio at the moment
17:42:47 <caribou> ... can we merge this PR 154?
17:44:14 <caribou> Tim: I'll lokk at the PR
17:44:21 <caribou> s/lokk/look
17:44:51 <caribou> jan-ivar: no consensus yet
17:45:43 <caribou> fippo: [slide 49]
17:46:05 <caribou> ... we should not use SSRC
17:46:24 <caribou> ... so proposal to add mid and rid to metadata
17:49:25 <caribou> Action: Fippo to provide a PR
17:49:46 <caribou> fippo: [slide 50] adding timestamp
17:51:36 <hta> OK.
17:51:52 <hta> scribe: hta
17:52:12 <hta> fippo: [slide 51]
17:52:38 <hta> ... mimeType metadata
17:53:03 <hta> ... add fmtp line?
17:53:20 <hta> bernard: webcodecs has them both in one object
17:54:02 <hta> youenn: like the webcodecs way better
17:55:08 <hta> fippo: complex to get access to the fmtp line in encoded-transform
17:58:35 <hta> fippo: discussing this further.
17:59:27 <hta> bernard: [slide 53]
18:00:43 <hta> ... describes SVC metadata; webcodecs is "everything from DD", encoded-media has type mismatches, missing info
18:02:20 <hta> ... suggests using a subdictionary for SVC information in metadata
18:04:27 <hta> what's the command for generating miutes again?
18:04:40 <caribou> Present: Bernard, Harald, Jan-Ivar, Patrick Rockhill, Peter Thatcher, Philipp Hancke, Tim
18:04:42 <caribou>  Panton, Youenn, Carine, Brian Baldino, Florent Castelli, Palak
18:05:03 <caribou> RRSagent, make log public
18:05:28 <caribou> present+ Youenn, Carine, Brian Baldino, Florent Castelli, Palak
18:05:35 <caribou> RRSAgent, make minutes
18:05:35 <RRSAgent> I have made the request to generate https://www.w3.org/2022/12/07-webrtc-minutes.html caribou
18:07:04 <caribou> i/Harald's presentation on/scribenick: caribou
18:07:07 <caribou> RRSAgent, make minutes
18:07:07 <RRSAgent> I have made the request to generate https://www.w3.org/2022/12/07-webrtc-minutes.html caribou
18:07:48 <caribou> s/Panton, Youenn, Carine, Brian Baldino, Florent Castelli, Palak//
18:07:56 <caribou> s/what's the command for generating miutes again?//
18:08:05 <caribou> RRSAgent, make minutes
18:08:05 <RRSAgent> I have made the request to generate https://www.w3.org/2022/12/07-webrtc-minutes.html caribou
18:08:47 <caribou> RRSAgent, stop