- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Fri, 27 Jul 2012 21:18:46 +0000
- To: "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <9768D477C67135458BF978A45BCF9B38383EAD73@TK5EX14MBXW604.wingroup.windeploy.ntde>
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. In short, my proposal is to remove the "ended" and "onended" attributes from the MediaStream object (and their related events).
Received on Friday, 27 July 2012 21:19:20 UTC