- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 26 May 2015 09:20:33 +0000
- To: Harald Alvestrand <harald@alvestrand.no>, Eric Rescorla <ekr@rtfm.com>
- CC: Jan-Ivar Bruaroey <jib@mozilla.com>, Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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() }
Received on Tuesday, 26 May 2015 09:21:00 UTC