- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 27 Sep 2013 14:28:10 +0200
- To: public-media-capture@w3.org
Reawakening an old discussion (tracked in bug 22270). The suggestions made are (I think) three different ones: - Create two classes of MediaStream, one which adds tracks under UA control, and one which adds tracks under Javascript control. Only the second has the addTrack and removeTrack methods. getUserMedia and peerconnections produce the first type. - Let addTrack and removeTrack fail when a MediaStream comes from getUserMedia or peerconnections. - No change. Tracks can be added to any MediaStream. Should we make a decision here? On 04/18/2013 11:09 AM, Adam Bergkvist wrote: > On 2013-04-17 12:23, Robert O'Callahan wrote: >> On Wed, Apr 17, 2013 at 10:18 PM, Adam Bergkvist >> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> >> wrote: >> >> Since they're only used to listen to when the UA updates the track >> set they wouldn't be used when it's only the application that >> manages the track set. >> >> This is a bit confusing in the current spec. The description of the >> events say that they are fired whenever a track is added, which is >> misleading since they are not fired in the addTrack()/removeTrack() >> algorithms. It's fixed for the next release. >> >> >> We should also fire them when addTrack()/removeTrack() are called, >> shouldn't we? > > We currently don't do that since these methods directly adds or > removes the track. In the case where it's the UA that modifiess the > track set, the track is added/removed in the same event loop iteration > as the addtrack/removetrack event is fired. > > I don't have a strong preference about this; if we could find similar > behavior in established APIs I would be happy to align. > > /Adam >
Received on Friday, 27 September 2013 12:28:34 UTC