Re: MediaStream ended vs inactive

On 2013-06-12 11:38, Robert O'Callahan wrote:
> On Wed, Jun 12, 2013 at 9:03 PM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto: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".
>

Perhaps it's best to keep it as simple as possible. We have moved most 
of the stuff from MediaStream to MediaStreamTrack and the stream state 
is, after all, a convenience thing, so it might be a bad idea to over 
complicate it.

I think Jim's active/inactive proposal is enough. Other information is 
mostly given by the application context; for example in my state 
sequence above, the removestream event tells that this inactive stream 
was removed on the a-side and can be considered permanently ended.

/Adam

Received on Wednesday, 12 June 2013 10:54:24 UTC