- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 08 May 2014 09:46:52 +0200
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 05/08/2014 09:43 AM, Stefan Håkansson LK wrote: > On 2014-05-08 08:07, Harald Alvestrand wrote: >> (as contributor) +1 from me. > Ditto. > >> One nit: The following should be legal: >> >> addTrack(track, streamId1) >> addTrack(track, streamId2) >> >> this means that one track should be presented to the receiver as part of >> two streams. > I still think that conveying the MediaStream(s) a track belongs to using > SDP adds unnecessary complexity to the API and the solution. > > But if we should, why not make the second (and optional) argument to > addTrack a list of streamId's instead (I proposed that in [1])? > > If you can call addTrack several times with the same track as first > argument but different streamId's, what should happen at the far end if > you carry out an SDP O/A between the calls? The same thing as happens when you add two different tracks and do an SDP O/A between them: The SDP O/A reflects the state at the moment the CreateOffer / CreateAnswer is called. This is needed to make it possible to polyfill AddStream without adding a bunch of special cases.
Received on Thursday, 8 May 2014 07:47:20 UTC