ReplaceTrack vs RTPSender.track = new

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.

Received on Wednesday, 15 April 2015 07:31:38 UTC