Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

To remove a track, stop/remove the track locally and signal the fact that
the track is stopped to the remote side (in an app specific way).

To add a track, don't modify the existing MediaStream.  Create a new
MediaStream and call createLocalStream with the new MediaStream, and then
signal the MediaStreamDescription for it to the remote side.  If you really
want two MediaStreams to be merged into one MediaStream (the previous one
and the new one), signal that desire to the remote side (in an app specific
way), and the remote JS application can handle merging them.

The key here is that that we need an API for telling the browser how to
send tracks and how to receive tracks, and this provides it.  How those
tracks get arranged into MediaStreams can be done completely  by JS and
app-specific signalling.  In fact, we could model this entirely as
PeerConnection.createLocalTrack and createRemoteTrack instead of
.createLocalStream and createRemoteStream, but we kept is stream-oriented
because it works better with the existing methods in the simple cases.

On Mon, Jun 17, 2013 at 12:42 PM, José Luis Millán <jmillan@aliax.net>wrote:

> Yes, just adding and removing tracks.
>
> Regards
>
>
> 2013/6/17 Peter Thatcher <pthatcher@google.com>
>
>> What do you mean by "change to an existing media stream"?  Do you mean
>> adding and removing tracks?  I don't know of any other changes that can be
>> made to a MediaStream.
>>
>>
>> On Mon, Jun 17, 2013 at 11:52 AM, José Luis Millán <jmillan@aliax.net>wrote:
>>
>>> Hi,
>>>
>>>
>>> 2013/6/17 Peter Thatcher <pthatcher@google.com>
>>>
>>>> In that use case, just call createLocalStream again with the new
>>>> MediaStream from GetUserMedia and get a new LocalMediaStream.  There's no
>>>> need to alter the existing one.
>>>>
>>>>
>>> On the receiver side, I would expect to represent each remote
>>> MediaStream on its own audio+video display element.
>>>
>>> If, as a sender, I create a new LocalStream to represent a change in an
>>> existent media stream source, how will the receiver notice that the NEW
>>> MediaStream does refer to the previous one?
>>>
>>>
>>>
>>>
>>>>
>>>> On Mon, Jun 17, 2013 at 9:34 AM, Iñaki Baz Castillo <ibc@aliax.net>wrote:
>>>>
>>>>> 2013/6/17 Peter Thatcher <pthatcher@google.com>:
>>>>> > But I don't really see a use case where you would need to add tracks
>>>>> to a
>>>>> > MediaStreamTrackDescription, other than when parsing signalling and
>>>>> building
>>>>> > the MediaStreamTrackDescription to send down into createRemoteStream.
>>>>> > Perhaps if we had a use case, we could define such support.  But
>>>>> otherwise,
>>>>> > I'd say it's not allowed.
>>>>>
>>>>> Use case:
>>>>>
>>>>> - Start a session/call with just audio (no video requested to the user
>>>>> via getUserMedia).
>>>>> - Latter the user wants to add video.
>>>>> - For that a new getUserMedia(video: true) is requested.
>>>>> - Extract the video track from the obtained MediaStream and add it to
>>>>> the PC.
>>>>>
>>>>> Hope this is an enough common use case.
>>>>>
>>>>>
>>>>> --
>>>>> Iñaki Baz Castillo
>>>>> <ibc@aliax.net>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>
>>>
>>> --
>>> José Luis Millán
>>>
>>
>>
>
>
> --
> José Luis Millán
>