Re: To Stream or not to Stream

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.
>
>
>
>