Re: Raw data API - 6 - Encoders/decoders

On Thu, Jun 14, 2018 at 11:00 AM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> On 14/06/2018 11:55, Peter Thatcher wrote:
>
>
>> Does this API provide any advantage over the ORTC-sytle RTPSender if we
>> just don't want to do any raw processing? Yes, I would even re-implement a
>> standard rtp stack on js than having to use the ORTC sender/receiver stuff.
>>
>
> I'm curious what you think is wrong with the ORTC RtpSender and
> RtpReceiver.  Have you used it?  What was difficult?  You said something
> about them being like SDP m-lines, but I don't see how that's the case.
>
> By the way, regarding ORTC, i found this old thread about what I thought
> it was wrong with ORTC two years ago:
>
> https://lists.w3.org/Archives/Public/public-ortc/2016Apr/0020.html
>
> Don't ask me to try to elaborate the rationale behind it as I have erased
> everything from my memory .. hehehe.. but basically, my complain has always
> been that RTPSender was too complex and too high level to be usable. I was
> also already all-in for splitting the encoders and senders at that time..
> X-)
>

My reply at the time was basically that the WG didn't have interest in
going so low-level at the time.  But perhaps that time has come.


> https://github.com/murillo128/simple-ortc/blob/master/examples.md
>

Looking at that example, you have an interesting idea there.  You basically
have an RTP packetizer separated from an encoder, so you go encoder ->
packetizer -> transport.  That might be an interesting way to go to allow
apps to have the browser do packetization but also do its own if it likes.

But then you'd also need the flip side, a depacketizer/demuxer.  And we
might be going down the road of too many RTP objects. That's kind of the
problem with RTP: it's so complex that you either have a complex config
(like RtpSender), a complex object graph, or punt to the app and let it
figure it out.


> Best regards
>
> Sergio
>