Meeting minutes
Recording: https://
Slideset: https://
WebRTC Network of User’s Project 🎞︎
TimPanton: webrtc.nu presentation
… survey shows strong support for use of async funtions
… most devs munge SDP
… 1/3 of respondents don't use datachannels
… many want to do datachannels in workers
… survey was anonymous (collecting ID would need GDPR stuff)
… API regarded as complex or very difficult by most
… survey was focused only on JS APIs, not native
bernard, youenn: SDP munging was the biggest surprise / learning
Tim: we should look to other APIs to see if there are patterns we could adopt
youenn: devtools? WebInspector?
bernard: want to know if there are a few things in SDP munge or many
jan-ivar: not all APIs that avoid SDP munging are implemented in all browser
fippo: 10% of SDP munging is to achieve stereo in Chrome. we don't know who.
fippo: will produce a list of things people can do / are doing with SDP munging.
Tim: should we adopt methods / tricks / constructs from other APIs?
… Maybe, but not urgently.
WebRTC-NV Use Cases 🎞︎
Repository: w3c/
Bernard: Presenting scenarios for CfC
hta: 3.2.1 requirements should be in terms of desired results, not in terms of how to achieve them.
youenn: do we want ability to inject JS in the media pipeline, or is latency too critical?
tim: need API to match up server stuff with client stuff
Bernard presents 3.2.2
youenn: points out that N39 kind of presupposes that we want to use RTP
youenn: not clear whether this is frame level or packet level
hta: that choice may be part of the solution space rather than the requirement space
jan-ivar: could also consider the case of within-browser relay (no js).
pthatcher: running over datachannel gives worry with congestion control.
bernard: people have done over datachannel, with custom code sender-side.
Bernard presents 3.5 Virtual reality gaming
youenn: pre-sending video frames & metadata may be requirements. Reach out to XR?
Harald's presentation on issue #106
hta: original use case was e2ee
hta this is Bernard's summary
Tim: it's not necessary about slowing or speeding things
hta: request from people feeding H264 to a browser using something else than webRTC, that they want to send over RTP
… we can do that without using the encoder
bernard: I heard that use case for traffic cameras
jan-ivar: it's hard to gauge if it can't be done with the existing APIs
youenn: I'm still fuzzy about this UC
… it seems that one node in the network is producing H264 and it gets sent to a browser
… I'm not sure why there should be a browser in the middle between the sender and the RTP
bernard: it's coming over HTTP most of the time
youenn: it's not the typical browser use
… the context would help understanding the UC
hta: the asumption is that the camera is not supported by gUM
jan-ivar: is the UC supporting traffic cameras in the browser?
… how do you feed to the browser?
Tim: it would be nice to have something to prevent re-encoding
… If you have an in-car camera with limited BW to a monitoring station
… and that station is a browser, but you want to share the feed to someone else over webRTC
… rendering + capturing/sending is overkill
jan-ivar: if low latency is the goal (thus sending to RTP), @@@
hta: if you take away h264, there are other solutions
hta: this UC is pre recorded media sent to RTP
youenn: I don't understand why the desired tranceiver would be RTP
… for that UC to be meaningful you need to know why RTP is better
hta: the scenario could be that you already have an RTP cnx
… e.g. live video
… then you want to send pre-recorded video, without the receiving side having to do anything
jan-ivar: you could do this using the video track generator
… you could decode the pre-recorded
… so this (proposal) is an optimization
hta: we can switch to key frames. it's UC dependent whether we want the browser to do it
bernard: there might also be battery-life optimizaiton
youenn: it would be good to comment in the issue if we're targeting optimization
hta: please comment
youenn: should we have an API that controls at the packet-level or an API at the encoder side
… I think we be trying to do both in the same API and it's too difficult
… are there 2 different sets of UCs, e.g. low-latency and other optimizations
Peter: maybe true
youenn: webRTC NV could have those UCs and requirements, do we need packet data API, or frame
Peter: @@@@ audio codecs
youenn: look at what we expose
Encoded media manipulation 🎞︎
hta: I'd like to have a Call for Consensus on the low latency streaming UC
Tim: you need to have a rough flavor of an API
… who are targeted audiences? does that fit naturally with codecs?
… at least describe that is useful
hta: the obvious APIs to fit next to are webRTC APIs and webCodec APIs
jan-ivar: we don't have to agree to incremental APIs
hta: if I have something that is part of solution, we don't need the entire solution before pushing it
jan-ivar: it sounds OK but I don't think we need to commit to this approach
… in advance
youenn: i'd echo what Tim said, we need to understand the big picture of what we're trying to solve
… and I agree it's good to look at webCodec APis
… webRTC encoded transform is fine
… we should design the best API, not the API that needs the less work for the User Agent
Encoded Transform Issues 🎞︎
Repository: w3c/
issue #143/PR 165 🎞︎
Fippo: the proposal is to merge PR 165
hta: I agree
youenn: we discussed rids but not the return value
… the return value is useful to validate the input
… the promise makes sense for the transformer
… I don't have a strong opinion for the sender
fippo: you can wait and read the key frame
youenn: with the promise you can reject asynchronously
… it helps a bit
jan-ivar: the PR removes a lot of the algo. text
youenn: the text detailed all the cases
… if you remove the promise resolution you can simplify a lot
jan-ivar: we may not merge PRs during meetings
youenn: we did not yet agree about the return value
… so we need to decide
bernard: objection to no return value?
youenn: original proposal was a promise
… safari implements the promise undefined
hta: no objection to using that
issue #167 🎞︎
fippo: proposal is to add timing metadata
… currently only things derived from rtp header
bernard: this is an issue, we try to give a direction
youenn: I have not looked beforehand, no input yet
fippo: pls leave feedback on the issue
issue #168 🎞︎
fippo: I'd like to add rtp header metadata
hta: are they read only?
fippo: the PR is only for audio at the moment
… can we merge this PR 154?
Tim: I'll look at the PR
jan-ivar: no consensus yet
fippo: we should not use SSRC
… so proposal to add mid and rid to metadata
ACTION: Fippo to provide a PR
fippo: adding timestamp
fippo: mimeType metadata
… add fmtp line?
bernard: webcodecs has them both in one object
youenn: like the webcodecs way better
fippo: complex to get access to the fmtp line in encoded-transform
fippo: discussing this further.
bernard: describes SVC metadata; webcodecs is "everything from DD", encoded-media has type mismatches, missing info
… suggests using a subdictionary for SVC information in metadata