Re: addTrack/removeTrack on gUM streams and PeerConnection remote streams

On 09/27/2013 03:01 PM, Sam Dutton wrote:
>
>     getUserMedia and peerconnections produce the first type
>
>
> so -- JavaScript (from ...?) produces the second?

Yes. In particular, "new MediaStream(....)" produces the second.


Since the new operator is one of the few places in Javascript where type
names matter, we might want to keep the name "MediaStream" for the
modifiable object.

>
>
> On 27 September 2013 13:28, Harald Alvestrand <harald@alvestrand.no
> <mailto:harald@alvestrand.no>> wrote:
>
>     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>
>             <mailto: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
>
>
>
>


-- 
Surveillance is pervasive. Go Dark.