W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2013

Re: Missing Features: Stream Control

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3AC1B7@ESESSMB209.ericsson.se>
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:21 UTC

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