- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 15 Apr 2015 09:31:06 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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