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

Re: To Stream or not to Stream

From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 14 Jun 2018 12:34:40 -0700
Message-ID: <CAJrXDUFe4gS7F9rL43MrAB05tSvZeji3rLOCN9_COSDqySF9dw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
On Thu, Jun 14, 2018 at 6:45 PM Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 14. juni 2018 19:44, skrev Peter Thatcher:
> <snip>
> >
> > OK, that was a fun brainstorming.  The conclusions I would come to at
> > the moment are:
> >
> > 1.  Even if we split out the RtpTransport from the
> > RtpSender/RtpReceiver, it seems to make sense to keep the
> > RtpSender/Receiver around for those apps which don't want to do
> > packetization/demuxing on their own.
>
> To my mind, RTPTransport is a multitrack thing (shipping multiple
> tracks), while RTPSender is a single-track thing.
>

Agreed.  That makes the connection of many RtpSenders/packetizers to one
RtpTransport tricky using WHATWG streams.


>
> >
> > 2.  We need to worry about not just the direction of media flow, but
> > also feedback flow (key frame requests, etc).
>
> Yes. I have looked at the whatwg feedback section several times, and am
> still worried that I don't think I understand it (beyond the simple
> backpressure / buffersize default).
> I'm happy to know that it exists, but I'm not sure how far we can flex it.
>

Backpressure *might* work.  But key frame requests?  I don't know how.


>
> >
> > 3.  A few simple methods to attach objects together might be sufficient
> > to allow apps that don't want to be in the media path not be.  WHATWG
> > streams might be as well if we figure out the feedback flow.
>
> I suspect that we could implement the WHATWG stream interface somewhat
> like this (C++ pseudocode):
>
> Promise whateverComponent::pipeTo(otherComponent) {
>   if (otherComponent.isOfTypeThatIRecognize) {
>      // C++ plumbing, minimal overhead
>      sender_function_ = otherComponent.specialReceiverFunction();
>   } else {
>      sender_function_ =
>         JavaScriptLevelFunction(bufferArgumentGoesHere(),
>             JavaScriptObjectWrapper(otherComponent.receiver())
>   }
>   .....
> }
>
> you get the gist - if we know what the fast path is, we can optimize for
> it in the implementation.
>
>
>
>
Received on Thursday, 14 June 2018 19:35:18 UTC

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