Re: Proposal: RtpListener for unsignalled ssrcs

I haven't been following the work here as closely as I would have
liked so I might be missing something obvious. What I don't understand
is: what is an app supposed to do with an RTP event? I would expect it
to be able to either somehow convert it to a new render-able stream or
attach it to an existing one as some sort of a layer.  How would these
work?

On Thu, Feb 13, 2014 at 8:23 PM, Peter Thatcher <pthatcher@google.com> wrote:
> With the move to RtpSender/RtpReceiver, we have one thing we're missing from
> RTP that can't be put in either of them: an event for unsignalled ssrcs.  We
> want such an event, but right now we don't have a clear place to put it.  I
> propose we add a class called RtpListener which, like RtpReceiver, wraps a
> DtlsTransport, and fires events for RTP received.  Unlike RtpReceiver, which
> handles the RTP for a given set of ssrcs, the RtpListener can listen to all
> RTP and fire an event if a packet is already process by an existing
> RtpReceiver.  Here's how I propose RtpListener  should look:
>
>
> [Constructor(RTCDtlsTransport)]
> interface RTCRtpListener {
>   readonly attribute RTCDtlsTransport transport;
>   //  fires RTCRtpUnhandledRtpEvent;
>   attribute EventHandler? onunhandledrtp;
> }
>
> interface RTCRtpUnhandledRtpEvent : Event {
>   readonly attribute unsigned int  ssrc;
>   readonly attribute unsigned byte payloadType;
>   // AKA "AppID" header extension
>   readonly attribute DOMString?    receiverId;
> }
>
>
> That's it :).  It's simple, but it grants a lot more flexibility to the
> application to signal things (or not signal things) how it wants.
>
>



-- 
https://jitsi.org

Received on Thursday, 13 February 2014 22:08:21 UTC