- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 22 Feb 2018 09:05:33 +1100
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc <public-webrtc@w3.org>
On Thu, Feb 22, 2018 at 3:23 AM, Harald Alvestrand <harald@alvestrand.no> wrote: > Den 21. feb. 2018 08:21, skrev Peter Thatcher: >> About a month ago, I sent an email to the list asking "What would you >> like to see in WebRTC next?" I'm glad to see there was a lot of input >> from many people. Having read through all the messages, here's my >> summary of the common themes: >> >> 1. Many (most?) expressed a desire for a simple, low-level, decomposed >> APIs. Specifically mentioned quite a few times were separate components for: >> - Connectivity (lower-level ICE) >> - Encode/Decode >> - Encryption >> - Transport (RTP/RTCP extensions or QUIC) >> >> 2. A recurring use case was video conferencing, and with end-to-end >> encryption. >> >> 3. Another recurring use case was control over the network path used >> (wifi/cell/both). >> >> 4. QUIC was mentioned several times, but without any specific use cases. >> >> >> >> I'm glad to see we're all roughly on the same page, and to learn what >> use cases people are most interested in. I think we can accomplish much >> of this with a set of small, composable, low-level extensions specs with >> roughly the break down expressed by the comments: >> >> - ICE (extension spec already started, but could go lower-level) >> - Encoders/Decoders (no spec yet, but I proposed an API at TPAC) >> - WebCrypto (already exists) >> - QUIC (extension spec already started) >> - RTP/RTCP (ORTC is a good start, but could go lower-level) > > I do think there's a number of interesting applications that require > exposing media data to user-controlled code - for instance for media > stream transformations, machine learning - driven approaches to building > assitive features, audio manipulation or even new video codecs. > > Such APIs will inevitably mean that we have to tackle how > MediaStreamTracks interact with the Javascript process model (aka > "workers"). > > I have some ideas on how to do it, and it's certainly allowed within the > charter that's being proposed, but there's lots of working-out to do here. > I think that's a really important piece of work and not to be under-estimated. With all the talk about AI and machine learning, getting access to the data in the A/V & Data streams and being able to analyse and manipulate them fast in a Web browser will have to be an important focus of browser development in the future. Kind Regards, Silvia.
Received on Wednesday, 21 February 2018 22:06:19 UTC