FWIW I think there's some confusion for web devs: whether to use MediaStream.stop() or MediaStreamTrack.enabled = false. (And, of course, MediaStream.stop() is 'permanent' -- there's no concept of a pause.) >> know the difference between pause and a broken connection Good point. On 19 October 2013 00:42, Aymeric Vitte <vitteaymeric@gmail.com> wrote: > What I am saying here is that there should be an unique and unified > Streams API supported by all related APIs, each group where it is relevant > should feel concerned instead of thinking another one might be. > > Le 18/10/2013 20:04, Adam Roach a écrit : > > On 10/18/13 12:47, Aymeric Vitte wrote: >> >>> >>> Le 18/10/2013 19:13, Adam Roach a écrit : >>> >>>> To be clear, the .enabled flag and .stop() method are already there, >>>> and they already pause/unpause the stream and tear it down, respectively. >>>> I'm just proposing concrete semantics for how they interact with any >>>> PeerConnection that the track is associated with. >>>> >>> >>> But they are not in the Streams proposal, see my other answer. >>> >>> >> To make my point clearer: this isn't the right mailing list to talk about >> making changes to the API on MediaStream and MediaStreamTrack. If I had >> been proposing to change those APIs, it would have been on the >> public-media-capture list, not the public-webrtc list. >> >> All I was trying to talk about is how the existing API influences the >> behavior of RTCPeerConnection, which is why I was talking about it on this >> list. If you want to propose changes to MediaStream and MediaStreamTrack, >> please take them to public-media-capture. >> >> /a >> > > -- > Peersm : http://www.peersm.com > node-Tor : https://www.github.com/Ayms/**node-Tor<https://www.github.com/Ayms/node-Tor> > GitHub : https://www.github.com/Ayms > > >
Received on Monday, 21 October 2013 10:03:57 UTC