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

Re: Transport / encoder coupling (Re: Use cases / requirements for raw data access functions)

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Tue, 22 May 2018 00:02:42 +0200
To: public-webrtc@w3.org
Message-ID: <66b3f379-6755-b84c-cf82-24a44cf0cec8@gmail.com>
On 21/05/2018 23:17, Peter Thatcher wrote:
> You just described ORTC, except that you replaced an RtpSender with an 
> RtpTransport, which I think is a good idea.
>
> I think the key questions left are:
>
> - What does the encoder/decoder part of the RtpSender look like?
> - How low-level is the RtpTransport?  Is it "send frame" or "send packet"?

Shouldn't be so difficult to support both. I mean just as a naive 
example, make the encoded providing both a "onframe" event, with the 
full encoded media frame, and a encoder.getRTPSource() that returns an 
RTPSource interface that can be attached to an rtp sender. That is 
(again, just an example/psuedo code)

encoder.addEventListener('onframe',(e)=>{
     quicTransport.send(e.mediaFrame.buffer);
});

rtpSender.attachTo(encoder.getRTPSource())

Also it could be possible to add a RawRTPSource helper object 
implementing the RTPSource interface to allow sending custom/raw rtp packet.

const source = new RawRTPSource(payloadType);

rtpSender.attachTo(source);

encoder.addEventListener('onframe',(e)=>{
    for (const packet of paquetize(e.mediaFrame))
         source.send(packet);
});

Best regards
Sergio
Received on Monday, 21 May 2018 22:02:29 UTC

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