W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

Re: Proposal: RtpListener for unsignalled ssrcs

From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 13 Feb 2014 14:32:45 -0800
Message-ID: <CAJrXDUGbaCm4jv-3fJaTEY_kLRMy=Xz43ugyRjEaVnGbPwYB6Q@mail.gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Cc: "public-orca@w3.org" <public-orca@w3.org>
One could use it to create an RtpReceiver to get a track to render.  This
is especially useful if we have the RTP header extension that allows the
app to include meta data so the receiver knows what to do with the media,
without the need for signalling ahead of time.  For some use cases, this
lowers the latency between when media is available and when the receiver
receives it, or can avoid clipping.

I'm sure there are other use cases, but this is one that matters to me.
 I've heard a lot of requests for this event, and I'm sure they're not all
my use case.

‚Äč


On Thu, Feb 13, 2014 at 2:07 PM, Emil Ivov <emcho@jitsi.org> wrote:

> 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:33:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC