- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 18 Oct 2013 17:31:55 +0000
- To: Aymeric Vitte <vitteaymeric@gmail.com>, Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Takeshi Yoshino <tyoshino@google.com>, Feras Moussa <feras.moussa@hotmail.com>
On 10/18/13 6:57 PM, Aymeric Vitte wrote: > Should this not be synchronized with the Streams API? Please see recent > evolutions [1] and thread [2] (where WebRTC streams are mentioned) I think we're talking about completely different streams, and what Adam is proposing is applicable for MediaStreamTracks in the context of a WebRTC PeerConnection. > > Ccing Webapps and Takeshi/Feras. > > Regarding your proposal I was about to propose to add about the same > thing in Streams: at least a stop method (which would send an EOF) and > maybe a resume method, or something like your pause/unpause. > > For flow control I think I am changing my mind, it looks impossible to > do a precise flow control with js, so probably the API itself should > handle it. > > Regards, > > Aymeric > > [1] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0152.html > [2] http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0049.html > > Le 18/10/2013 18:24, Adam Roach a écrit : >> We've recently had some implementors reach out to ask about how to do >> certain things with the WebRTC interfaces, and I've been pretty well >> unable to turn up anything that makes a lot of sense for most of the >> interesting stream-control interfaces. >> >> Some of this is talked about here, with an implication that the author >> of this wiki page, at least, would be willing to leave some of them >> unspecified for the first version of WebRTC: >> >> http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#Needs_further_discussion.2C_maybe_for_later_versions >> >> Unfortunately, I don't think we can leave stream pause/unpause or >> stream rejection/removal out of the first version of the document. The >> good news is that I think we have all the interfaces necessary to do >> these things; we just need to spell out clear semantics for them. >> >> As a high-level thumbnail sketch, here's what I think makes sense: >> >> 1. To pause a track that you are sending, set enabled=false on a >> MediaStreamTrack that you have added to a PeerConnection. This >> information will cause the PeerConnection to stop sending the >> associated RTP. Maybe this triggers an onnegotiationneeded to set >> the corresponding m-line to recvonly or inactive and maybe it just >> stops sending the stream; I'm not sure which makes more sense. >> * To unpause, set enabled back to true, and the steps are reversed >> * To pause all the MSTs associated with a MediaStream, use >> enabled on the MediaStream itself. >> >> 2. To pause a track that you are receiving, set enabled=false on the >> MediaStreamTrack that you received from the PeerConnection via >> onaddstream. This will cause the MST to stop providing media to >> whatever sink it has been wired to, and trigger an >> onnegotiationneeded event. The subsequent CreateOffer sets the >> corresponding m-line to sendonly or inactive, as appropriate. >> * As above, this operation can also be performed on a >> MediaStream to impact all of its tracks. >> >> 3. To reject a track that has been offered, call stop() on the >> corresponding MediaStreamTrack after it has been received via >> onaddstream, but before calling CreateAnswer. This will cause it >> to be rejected with a port number of zero. >> >> 4. To remove a track from an ongoing session, call stop() on the >> corresponding MediaStreamTrack object. This will (a) immediately >> stop transmitting associated RTP, and (b) trigger an >> onnegotiationneeded event. >> * If both the sending and receiving MST associated with that >> m-line have been stop()ed, then the subsequent CreateOffer >> sets the port on the corresponding m-line to zero. >> * If only one of the two MSTs associated with that m-line has >> been stop()ed, then the subsequent CreateOffer sets the >> corresponding m-line to sendonly, receiveonly, or inactive, as >> appropriate. >> >> Does this make sense to everyone? It seems pretty clean, easy to >> specify, and reasonable to implement. Best of all, we're not changing >> any currently defined interfaces, just providing clear semantics for >> certain operations. >> >> /a >> > > -- > Peersm :http://www.peersm.com > node-Tor :https://www.github.com/Ayms/node-Tor > GitHub :https://www.github.com/Ayms >
Received on Friday, 18 October 2013 17:32:22 UTC