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

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?

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

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.

>
> Thanks,
> Silvia.
>
>

Received on Sunday, 29 September 2013 05:56:01 UTC