Re: ReplaceTrack vs RTPSender.track = new

I was already convinced we want replaceTrack, but now I am doubly so.

On Wed, Apr 15, 2015 at 1:55 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> In the work in the ORTC CG, we chose to make it a method
> (.setTrack(newTrack)) rather than a writable attribute (.track =
> newTrack).  In fact, we choose to follow the .setFoo pattern rather than
> the .foo= for all things, not just setTrack for the following reasons:
>
> 1.  It allows return values, async and sync.  You might think you don't
> want one now, but you might want to add one later.
> 2.  It allows async errors.
> 3.  It allows for adding additional parameters.  You might think you don't
> want one now, but you might want to add one later.
>
> For those reasons, I also prefer .replaceTrack over setting .track.
>
>
> I also have thoughts over the rest of you error conditions and what we
> should do about them, but I think that's secondary and will leave that
> discussion for another time :).
>
> On Wed, Apr 15, 2015 at 12:31 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>> In mulling over this issue, I've been thinking about failure cases, and
>> about negotiated constraints.
>>
>> Consider this case:
>>
>> A negotiates with B to send video
>> The agreeed capabilities for B is 320x200 max (it's a doorbell, I guess).
>> A sends a track to B with 320x200 format.
>>
>> A does ReplaceTrack with a HD track (currently also being displayed in HD
>> somewhere else).
>>
>> Three possibilities:
>>
>> - A downsamples to 320x200 as (conceptuaully) an internal function of the
>> PeerConnection
>> - A treats B's restrictions as (new) constraints on the track, and all
>> other users switch to 320x200
>> - ReplaceTrack fails
>>
>> Replay the same case where the source of the new track is a VP8-only
>> camera, and B says it can only take H.264 (I guess it's a gateway).
>>
>> Three possibilities:
>>
>> - A transcodes the video internally to PeerConnection
>> - A inserts transcoding at the source
>> - ReplaceTrack fails
>>
>> And of course the weird one:
>>
>> A does ReplaceTrack, trying to replace an audio track with a video track.
>>
>> ANALYSIS:
>>
>> If ReplaceTrack never fails, all possible scenarios must be handled with
>> successful outcomes. That seems like a tall order.
>>
>> If ReplaceTrack can sometimes fail, and we can always report the error
>> synchronously in an exception (IllegalParameter for the last one, I guess),
>> the two solutions are equivalent.
>>
>> If ReplaceTrack can sometimes fail, and we don't want exceptions to be
>> thrown (for instance, we might not be able to instantly decide whether the
>> replacement is possible or not), ReplaceTrack() is superior.
>>
>>
>>
>>
>