Re: MediaStream "ended" event

On 2012-07-30 21:28, Stefan Hakansson LK wrote:
> On 07/30/2012 07:20 PM, Travis Leithead wrote:
>>> From: Stefan Hakansson LK
>>> [mailto:stefan.lk.hakansson@ericsson.com] To me, the 'ended' on
>>> MediaStream level makes life easier for the application developer.
>>> E.g., if the consent to use input devices is revoked by the user
>>> (I imagine browsers will supply ways to do that), the app would
>>> know that directly (and not have to keep track of that all tracks
>>> included in the MediaStream in question have ended).
>>>
>>> But the problem that comes from being able to remove all tracks,
>>> and then add (at least) one, was one I had not thought of before.
>>> In principle the same problem would surface if all tracks of a
>>> MediaStream ended, and the MediaStream went to state 'ended' as a
>>> result, followed by "add" of a non- ended track.

These are two different cases in the current spec. A MediaStream is only 
defined as ended (or finished as it's called in the spec) if all tracks 
are ended. Removing all tracks will not end the stream. Nor will an 
empty MediaStream created without track-arguments to the MediaStream 
constructor be ended. Then we wouldn't be able to add tracks to it since 
the MediaStreamTrackList.add() algorithm currently prevents adding 
tracks to an ended stream (illegal state).

>> Another alternative is to simply enhance the MediaStream object with
>> a corresponded "started" event for cases where a media stream with no
>> tracks becomes a media stream with at least one live track.
>
> Without thinking very much, that seems like the best solution to me.

When we moved the life cycle handling for media sources from MediaStream 
down to MediaStreamTrack we got a better one-to-one mapping. The old 
scenario where a MediaStream tried to represent the state of a number of 
cameras and microphones altogether was a bit strange. As a result, 
MediaStream has become more of a track container with a state that, 
e.g., makes it easier to know if there are any live tracks in the stream 
and really simple applications don't have to deal with tracks at all. 
With that definition I guess it would be OK to let a MediaStream end and 
restart as tracks end and new live tracks are added.

I'm just thinking about how this works together with LocalMediaStream 
and its stop() method. In that case it feels like the LocalMediaStream 
has some kind of life cycle anyhow where it's created by getUserMedia() 
and destroyed permanently with stop().

/Adam

Received on Thursday, 9 August 2012 13:03:21 UTC