- From: Alexandre GOUAILLARD <agouaillard@gmail.com>
- Date: Sun, 25 Feb 2018 05:47:28 +0800
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Harald Alvestrand <harald@alvestrand.no>, public-webrtc <public-webrtc@w3.org>
- Message-ID: <CAHgZEq6NLxh73T+Km8-CesqMTFduL-UisSU4xCoQZdaVu-j9oQ@mail.gmail.com>
+1, and ready to allocate time. On Thu, Feb 22, 2018 at 6:05 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > 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. > > -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ President - CoSMo Software Consulting, Singapore ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard -
Received on Saturday, 24 February 2018 21:47:52 UTC