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

On Sun, Sep 29, 2013 at 10:23 PM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> 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.

OK, I think that all works for me.

Thanks for your patient explanations.

Silvia.

Received on Monday, 30 September 2013 05:48:53 UTC