- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Tue, 26 May 2015 16:47:47 -0400
- To: Harald Alvestrand <harald@alvestrand.no>, Eric Rescorla <ekr@rtfm.com>
- CC: Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 5/26/15 5:06 AM, Harald Alvestrand wrote:
> Den 25. mai 2015 15:48, skrev Eric Rescorla:
>> 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.
Why depend on garbage collection when a track is already a ref-pointer
to a source?
Cloning is synchronous, so we could implement sender.replaceTrack to
first (private-algorithm-)clone the old track and "swap" to it
internally. The JS can now call stop() on its track all it wants without
it affecting what's sent. This buys replaceTrack some time to finish the
transition, after which it either calls oldTrackClone.stop() on success
(causing the old light to go off immediately if it's the last ref, no
need to wait for garbage collection), or in the case of failure, "swap"
back, at which point the old track either continues uninterrupted, or if
the JS has called .stop() in the interim, now stops.
It's like a "1-second smooth zone" (or stop-free zone). This separates
the resource allocation cleanly.
Harder on the implementer, easier on the JS writer (who no longer needs
to wait for the old track to be "off-air" to stop it).
.: Jan-Ivar :.
Received on Tuesday, 26 May 2015 20:48:18 UTC