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
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC