W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2018

Re: Summary of "What would you like to see in WebRTC next?"

From: Alexandre GOUAILLARD <agouaillard@gmail.com>
Date: Sun, 25 Feb 2018 05:47:28 +0800
Message-ID: <CAHgZEq6NLxh73T+Km8-CesqMTFduL-UisSU4xCoQZdaVu-j9oQ@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, public-webrtc <public-webrtc@w3.org>
+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

This archive was generated by hypermail 2.3.1 : Saturday, 24 February 2018 21:47:53 UTC