RE: MediaStream "ended" event

> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> 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().

I think what we may end up doing is moving the state from the LocalMediaStream to a LocalMediaStreamTrack in the same way that you mentioned that life cycle handling for media sources was moved from MediaStreams to MediaStreamTracks. In that way things end up consistent, application of state changes are portable to the relevant track they apply to (as tracks get moved around), and MediaStreams continue to act more as containers and synchronizers with perhaps only a few helpers to make the "simple" applications easy to use.

Received on Thursday, 9 August 2012 23:09:21 UTC