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

Re: Raw data API - 4 - direct RTP access

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 30 May 2018 17:48:12 -0700
Message-ID: <CAJrXDUGgkwM9FUFC5QX2QvXM9eN=JVi1ZxSYoFrExtJVW1NP-g@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: public-webrtc@w3.org
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
Received on Thursday, 31 May 2018 00:48:49 UTC

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