Re: Missing Features: Stream Control

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