Re: Summary of replace track status

Den 25. mai 2015 15:48, skrev Eric Rescorla:
> 
> 
> On Mon, May 25, 2015 at 12:40 AM, Harald Alvestrand
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
> 
>     Den 23. mai 2015 14:43, skrev Eric Rescorla:
>     >
>     >
>     > On Fri, May 22, 2015 at 5:51 PM, Jan-Ivar Bruaroey <jib@mozilla.com <mailto:jib@mozilla.com>
>     > <mailto:jib@mozilla.com <mailto:jib@mozilla.com>>> wrote:
>     >
>     >     On 5/22/15 6:09 PM, Peter Thatcher wrote:
>     >>     Thank you for the example.
>     >>
>     >>     I don't view that as "needs renegotiation" as much as "the
>     >>     RtpSender was configured to send in a codec it's not capable of
>     >>     sending".  Once we, someday, have direct  control of RtpSenders
>     >>     (sans SDP), the browser would basically view this as "JS told me
>     >>     to do something I can't do".
>     >
>     >     Or hopefully "something I can do". I hope getting rid of
>     >     SDP-renegotiation will mean getting rid of the need for it, rather
>     >     than getting rid of what it provides. ;)
>     >
>     >     +1 on replaceTrack not triggering renegotiation, since the whole
>     >     reason for its existence is to avoid renegotiation. Therefore,
>     >     people would probably rather it fail than trigger renegotiation, or
>     >     they would have used addTrack/removeTrack. It's also easy enough to
>     >     fall back to addTrack/removeTrack if so desired.
>     >
>     >
>     > I don't agree with this conclusion. It violates POLA to have it fail
>     > like this and is going to cause random, unpredictable failures in the field.
> 
> 
>     POLA - Principle of Least Astonishment?
> 
> 
> Yes.
> 
>  
> 
>     Thinking about this some more..... if replaceTrack can cause a state
>     that needs something else to happen before we can start sending the new
>     track, and if we want to keep the "smooth transition" between the old
>     track and the new track at the receiver side, it means that after
>     replaceTrack, the PC will have to keep on sending the old track "for a
>     while".
> 
>     Given that the app then has to know whether or not it can safely
>     disconnect the old track, it means that replaceTrack has to return a
>     promise, which would resolve to success at the time the app can stop the
>     old track (if it wants to), because it is no longer going out. What
>     failure cases can exist here is left as an exercise...
> 
> 
> This seems like a pretty big change in the semantics of the API in general,
> and I'm not sure it's necessary for this case.

Query - are you talking about the semantics of ReplaceTrack, or some
larger concept?
We have async actions that return a promise all over the place now,
including several that return a no-argument success. So it's not a new
pattern.

> 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.

Received on Tuesday, 26 May 2015 09:06:57 UTC