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

On 2013-09-29 08:44, Silvia Pfeiffer wrote:
> On Sun, Sep 29, 2013 at 3:55 PM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> On 2013-09-29 07:12, Silvia Pfeiffer wrote:
>>> On Sat, Sep 28, 2013 at 11:35 PM, Harald Alvestrand
>>> <harald@alvestrand.no> wrote:
>>>> On 09/27/2013 11:45 PM, Silvia Pfeiffer wrote:
>>>>>
>>>>>
>>>>> What would be the advantage of treating tracks differently depending on
>>>>> who created them?
>>>>> Silvia.
>>>>>
>>>>>
>>>> This is about streams, not tracks - see the original threads in bug 22270
>>>> for the arguments.
>>>
>>>
>>> If I understand correctly, it's about dis-allowing the adding of
>>> tracks to streams that were created by getUserMedia & PeerConnection,
>>> right?
>>
>> Right.
>>
>>>
>>> I use getUserMedia on several cameras, then create one PeerConnection
>>> with one camera, then add the video tracks from other cameras via
>>> addTrack to that one PeerConnection to multiplex multiple video tracks
>>> over the one PeerConnection.
>>
>> I assume you mean "addStream" since that is what you do on a PeerConnection?
>
> I just checked, you are correct.
>
>
>>> Can we make sure this use case is still possible after the change?
>>
>> That use case would definitely be possible even after the change (if we
>> decide to go ahead). It could be solved in at least two different ways:
>>
>> * Each MediaStream generated by getUserMedia (and containing the
>> MediaStreamTrack of a specific camera) is added to the same PeerConnection
>
> I don't really understand this. When I call getUserMedia, I get a
> MediaStream, potentially with 2 or more MediaStreamTracks (e.g. if
> it's a stereo camera with microphone, I'd get one audio and 2 video
> tracks), correct?

I think we have so far said that getUserMedia delivers at most one audio 
track and one video track, but otherwise correct.

(Personally I think that we could get rid of that limitation, in many 
situations the app would, based on history/SourceId, know what input 
devices it would like to use so I think it could make sense to allow it 
to ask for them in one getUserMedia call - but that is just my personal 
view.)

> Are you suggesting that I'd have to put all cameras
> and all tracks of each camera onto a single PeerConnection? What if I
> wanted to add them onto different PeerConnections, e.g. to connect to
> different peers at the same time?

In this situation you'd have one MediaStream per camera - and are free 
to use them as you like. You can attach all of them to one 
PeerConnection, all or a subset to another PC, a different subset (or 
all) to a third PC etc.

>
>
>> or
>>
>> * The app collects all tracks in a constructed MediaStream and the
>> constructed MediaStream is added to the PeerConnection. Note that the
>> constructed MediaStream could be added to PeerConnection at any time -
>> there is no need to wait for all getUserMedia calls to finalize.
>
> That latter one makes more immediate sense to me. How is it different
> from what we have now?

The only difference is that you need to construct a MediaStream. With 
what we have now, you could add new video tracks to one of the 
MediaStreams generated by a getUserMedia call. With this proposal, such 
a MediaStream would have no addTrack method.

I don't think this is super important, but it makes things a bit clearer 
IMO. Especially for the case of a MediaStream delivered by a PC to the 
remote app. That MediaStream is really controlled by the sending side 
app (which can add/remove tracks) - and it gets a little bit confusing 
IMO if the remote app can also control its content.

>
> Thanks for clarifying!
>
> Cheers,
> Silvia.
>

Received on Sunday, 29 September 2013 12:23:56 UTC