- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 14 Jun 2018 20:43:43 +0200
- To: public-webrtc@w3.org
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.
Received on Thursday, 14 June 2018 18:44:10 UTC