Re: Raw data API - 4 - direct RTP access

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