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

Re: Raw data API - 4 - direct RTP access

From: westhawk <thp@westhawk.co.uk>
Date: Thu, 31 May 2018 08:47:47 +0200
Message-Id: <C06FBA3F-C22E-458D-9B3A-9BA0E4D85B46@westhawk.co.uk>
Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, public-webrtc@w3.org
To: Peter Thatcher <pthatcher@google.com>
I think I must have missed something - what Audio use-cases are we addressing - that can’t be done with
the existing (or slightly extended) WebAudio API?


> On 31 May 2018, at 02:48, Peter Thatcher <pthatcher@google.com> wrote:
> First of all, the existing 1.0 API isn't going anywhere, so people that don't want low-level control can keep using it.
> Second, I do think lots of libraries will crop up, just like there have been for every other web API that's ever been, including very low-level ones.  And for simple use cases (especially audio), doing RTP packetization and demux  and RTX isn't *that* hard.   And C++ code that does it already exists and could fairly easily be complied to wasm.  
> Third, I don't think this has anything to do with QUIC vs RTP.  It's more low-level RTP vs. high-level RTP.  
> On Wed, May 30, 2018 at 12:06 PM Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com <mailto:sergio.garcia.murillo@gmail.com>> wrote:
> On 30/05/2018 20:06, Peter Thatcher wrote:
> > What objection do you have in these things being provided by libraries 
> > instead of being baked in the browser?
> Availability, interoperability, browser compatibility, fragmentation and 
> in a lower degree, support and low end devices performance.
> You take it for granted that someone will spend time and resources to 
> create a library to provide a higher level api, deal with the browser 
> differences and provide a good enough api to be used by everyone else. 
> This is quite unlikely, specially if QUIC is supposed to provide the 
> same functionality with a well defined, documented, tested and supported 
> api on browsers from day 0.
> Big players will likely, if they decide to go for QUIC over RTP, 
> implement their own libs, doing custom things, and media server people 
> will have hard time implementing all kind of custom rtx and fec 
> implementations to try to be compatible, or having to implement their 
> own js stacks to be compatible with their own media servers. This will 
> create silos and fragment the market, making it very difficult for 
> small/medium open source media servers projects to survive (or forced to 
> migrate to QUIC).
> Best regards
> Sergio

Received on Thursday, 31 May 2018 06:48:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC