Re: To Stream or not to Stream

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.

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

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