Re: MediaStream "ended" event

On 07/27/2012 11:18 PM, Travis Leithead wrote:
> It seems strange to me that a MediaStream has an “ended” event, but no
> corresponding “started” event. The reason I find this strange is that
> MediaStreamTrackList objects support the ability to both add & remove
> tracks. It makes sense that if you get a MediaStream and then
> subsequently remove all the tracks in both the videoTracks and
> audioTracks lists then the “ended” event should fire on the MediaStream.
> But then, if you add a track back later, there’s no “started” event.
>
>  From a design point-of-view, it makes sense that MediaStream objects
> are “started” by the getUserMedia or a remote connection, and can only
> be “ended”. In fact, I like that conceptual model because it avoids a
> lot of unnecessary state (e.g., by having to “end-and-re-start” as I
> noted above).
>
> My suggestion is that we remove the started/ended state from the
> MediaStream object completely, and instead push the concept down to the
> MediaStreamTrack itself. The MediaStream still supplies synchronization
> of tracks, but no longer needs to monitor all the tracks and their
> status. Since MediaStreamTrack objects already fire an onended event
> individually, they require no changes as a result.

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.

>
> In short, my proposal is to remove the “ended” and “onended” attributes
> from the MediaStream object (and their related events).
>

Received on Sunday, 29 July 2012 13:01:20 UTC