W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: Summary of replace track status

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D23E6D2@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:07 UTC