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
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
Should this not be synchronized with the Streams API? Please see recent
evolutions [1] and thread [2] (where WebRTC streams are mentioned)
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
On 10/18/13 11:56, Aymeric Vitte wrote:
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.
To be clear, the .enabled flag and .stop() method
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
Le 18/10/2013 19:31, Stefan Håkansson LK a écrit :
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.
I don't see why, a stream is a stream, this would be strange that a
Streams API
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
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
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
