On Wed, Jun 12, 2013 at 9:03 PM, Adam Bergkvist <adam.bergkvist@ericsson.com > wrote: > I agree that a final ended state is useful, but it would make more sense > to base it on something else that all tracks being removed or becoming > ended. I'll take a stream received via a PeerConnection as an example. > > dispatched at B-side by the addstream event: active > a-side removes all tracks: inactive > a-side re-adds live tracks: active > a-side ends-all tracks: inactive > a-side does removeStream(): ended > What if the a-side's stream reaches the permanently-ended state? > Perhaps only streams created by getUserMedia() and PeerConnection should > reach the ended state. That may bring us back to [1]. > OK, we could have a separate permanently-ended state, and we could define that state separately for each kind of stream. We could, then, give constructed MediaStreams the sort of API I proposed, and/or some way to explicitly end the stream. But if we do those things, I'm not sure why an author would want to use "inactive" instead of just "ended". Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Wednesday, 12 June 2013 09:38:51 UTC