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

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 22 Feb 2018 09:05:33 +1100
Message-ID: <CAHp8n2=_N7d2TiOp+BQTpSVsCA2EU54YQua3Bb=SWSBjsfKr6w@mail.gmail.com>
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,
Received on Wednesday, 21 February 2018 22:06:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 February 2018 22:06:20 UTC