On 10/21/2013 12:03 PM, Sam Dutton wrote:
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.)
True, and I think that's the difference that people need to focus on:
stop() is permanent, .enabled can be switched back and forth.
>> know the difference between pause and a broken connection
Good point.
On 19 October 2013 00:42, Aymeric Vitte <[email protected]
<mailto:[email protected]>> 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
GitHub : https://www.github.com/Ayms
