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

On 2013-09-27 14:28, Harald Alvestrand 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.

For the fun of it, I sketched on how this could look. Note that it could 
be described in many different ways, e.g. we could have a base class 
that is extended.


interface PlatformMediaStream : EventTarget {
        readonly    attribute DOMString    id;
        sequence<MediaStreamTrack> getAudioTracks ();
        sequence<MediaStreamTrack> getVideoTracks ();
        MediaStreamTrack?          getTrackById (DOMString trackId);
        MediaStream         clone ();
        readonly    attribute boolean      inactive;
                    attribute EventHandler oninactive;
                    attribute EventHandler onaddtrack;
                    attribute EventHandler onremovetrack;
};


[Constructor,
            Constructor (MediaStream stream),
            Constructor (PlatformMediaStream stream),
            Constructor (MediaStreamTrackSequence tracks)]
interface MediaStream : EventTarget {
        readonly    attribute DOMString    id;
        sequence<MediaStreamTrack> getAudioTracks ();
        sequence<MediaStreamTrack> getVideoTracks ();
        MediaStreamTrack?          getTrackById (DOMString trackId);
        MediaStream         clone ();
        void                       addTrack (MediaStreamTrack track);
        void                       removeTrack (MediaStreamTrack track);
        readonly    attribute boolean      inactive;
                    attribute EventHandler oninactive;
};

I did change "ended" to "inactive" since I think that is what we agreed 
on, but I think a MediaStream generated by a call to getUserMedia would 
(if all tracks stop) really be ended - there is no way to revive it.

Stefan

>
> - 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 13:38:31 UTC