Re: Raw data API - 4 - direct RTP access

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?

Tim.

> 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
> 
>