27227 2014-11-03 23:17:47 +0000 New feature: Track swapping 2014-12-15 10:39:30 +0000 1 1 1 Unclassified WebRTC Working Group WebRTC API unspecified PC Linux RESOLVED LATER P2 normal --- 1 harald public-webrtc martin.thomson public-webrtc oldest_to_newest 114457 0 harald 2014-11-03 23:17:47 +0000 Presented in https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf slide 16. This would make RTPsender.track be a mutable attribute, leading to the ability to switch which video is sent with no signalling. Compatible tracks are required, and it means that one loses the ability to correlate sendertrack.id with receivertrack.id - this needs to be explicit in the proposal. More work needed, but there was interest in pursuing this. 114459 1 martin.thomson 2014-11-03 23:25:49 +0000 Note that the mutable attribute was not popular. There was a general preference for a setter. The primary reason being that the replacement might fail. I think that the general sense was that failure was not a problem that browsers need concern themselves with: the track would simply go BYE-BYE (i.e., RTCP BYE) if media could not be provided in a compatible form from the new source. However, it was observed that replacement would not be atomic and that maybe a promise-bearing method was superior. That would allow for the time of replacement to be marked, as well as giving the application a way to learn about errors. 116318 2 dom 2014-12-15 10:39:30 +0000 WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues Please subscribe to the issues you want to keep watching.