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

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? 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?


> 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?

Thanks for clarifying!

Cheers,
Silvia.

Received on Sunday, 29 September 2013 06:44:54 UTC