Re: Summary of replace track status

On 26/05/15 11:06, Harald Alvestrand wrote:

>> If we're going to bother
>> putting
>> this logic into the PC, wouldn't it mostly cover this case to have it
>> just hold
>> a strong reference to the original track until the renegotiation
>> succeeds and
>> then release it, at which point it will be garbage collected.
>>
>> I recognize that this is somewhat less flexible in the sense that the app
>> doesn't know what's happened and so can't (for instance) change the
>> self-view, but I think that's a price I'm willing to pay for API simplicity.
>
> That would work (as long as the app manages to make sure it has no
> leftover references to the track). But I don't like depending on garbage
> collection for intentional actions. It seems hard to explain that "if
> you switch cameras, the active light on the camera you're switching from
> will remain on for a little while, except if you're running on a
> computer with lots of memory, in which case it might take a bit longer"
> - not sure how quickly stuff is garbage collected these days.
>
> pc.replaceTrack(oldTrack, newTrack).then(function() { oldTrack.stop() }
> somehow seems more explicit to me.

I agree, but I think it should be an operation on the sender:

sender.replaceTrack(newTrack).then(function() { oldTrack.stop() }