Re: Next steps on RTCRtpSender "doohickey" proposal

On 05/08/2014 09:56 AM, Stefan H�kansson LK wrote:
> On 2014-05-08 09:46, Harald Alvestrand wrote:
>> 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.
> I thought what would happen after the SDP O/A is carried out is that
> there is an addtrack event fired at the remote PC. I just thought it
> would be confusing to get a new event, with the same track, but a new
> stream Id. Maybe I'm wrong.
>
> But now we're going half-way; we build a solution where you can add a
> Track to as many Streams as you want, and have that be reflected at the
> far end, but you can never remove a track from a stream and have that be
> reflected.

I think that's a weakness that needs repairing: We need to have 
onremovetrack because of this case, and once we have onremovetrack, we 
might as well fire it on every "track disappeared" event.

>
>> This is needed to make it possible to polyfill AddStream without adding
>> a bunch of special cases.
> I think the vast majority of apps needing polyfill send only one
> MediaStream, and then there is no need to carry the StreamId over via
> API and SDP.

Apps that are the same on both sides need not worry; they can do 
whatever they want.
Apps that talk to something that is not themselves need to not make 
assumptions about
what the other app will or will not do.

Received on Thursday, 8 May 2014 09:54:56 UTC