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

Re: To Stream or not to Stream

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 14 Jun 2018 20:43:43 +0200
To: public-webrtc@w3.org
Message-ID: <b5bc902b-a986-0ecd-23f9-fa0dc9e7f416@alvestrand.no>
Den 14. juni 2018 19:44, skrev Peter Thatcher:
> 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_ =

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 18:44:10 UTC

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