24928 2014-03-04 22:52:40 +0000 the spec defines the addtrack event as part of the MediaStream interface, but never calls out when the event should be fired. 2014-04-04 07:31:27 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified All All RESOLVED WONTFIX P2 normal --- 1 shijuns public-media-capture adam.bergkvist public-media-capture oldest_to_newest 101866 0 shijuns 2014-03-04 22:52:40 +0000 The Media Capture and Streams spec defines the addtrack event as part of the MediaStream interface, but never calls out when the event should be fired. Propose to change the following in Section 4.2.3 When the addTrack() method is invoked, the user agent MUST run the following steps: 1. Let track be the MediaStreamTrack argument and stream this MediaStream object. 2. If stream is finished, throw an INVALID_STATE_ERR exception. 3. If track is already in stream's track set, then abort these steps. 4. Add track to stream's track set. to the following: When the addTrack() method is invoked, the user agent MUST run the following steps: 1. Let track be the MediaStreamTrack argument and stream this MediaStream object. 2. If track is ended, throw an INVALID_STATE_ERR exception. 3. If track is already in stream's track set, then abort these steps. 4. Add track to stream's track set, then queue a task to fire an addtrack event. Note: this will also fix a couple typos in step #2, i.e. from "stream is finished" to "track is ended". 101898 1 adam.bergkvist 2014-03-05 13:52:29 +0000 Hi and thanks for providing feedback on the spec. The question whether the "addtrack" event should be fired as a result of MediaStreamTrack.addTrack() has been brought up a few times before. The event is intended to asynchronously notify the script that the platform has updated the stream's track set. The new track is added to the track set as the event is dispatched. Direct manipulation with addTrack() doesn't need the event since the new track is added synchronously; i.e. you can, e.g., read out the new track set length on the next line of code. Having the event could on the other hand complicate things since by the time the event is dispatched, the track could have been removed already. The question is if the definition of the event should be in this spec or if it should be defined where it's actually used. 102040 2 shijuns 2014-03-07 00:10:22 +0000 It seems okay to remove the addtrack event from the spec as long as the addtrack() call is synchronous. Same to the removetrack event (as mentioned in bug 24930). 102057 3 adam.bergkvist 2014-03-07 09:33:45 +0000 But your comment regarding the stream state check is still valid. That needs to be fixed. I noted that the MediaStrem() constructor, which takes an other MediaStream or a sequence of MediaStreamTracks, ignores ended tracks when constructing the track set of the new stream. Should we do the same here or throw? I think it's could be motivated to throw for addTrack() since you're only adding a single track. The ignore-approach for the constructor acts like a filter for ended tracks since several tracks can be added at once. 102066 4 shijuns 2014-03-07 17:15:13 +0000 Agree, "throw" is more intuitive for addTrack(), but not so for the MediaStream() constructor.