Re: Reusing a transceiver to send a new track with different encodings (WANNA DIE)

comments below.

> On Feb 1, 2019, at 12:52 PM, Amit Hilbuch <amithi@google.com> wrote:
> 
> 1. How often, do you switch the tracks, and why are you switching between simulcast and non-simulcast?

[BA] One scenario I have seen is switching from a p2p conference to a central conference as the number of users grows over a limit (e.g. P2P with 4 users or less, centralized above that).  However this scenario involves creation of new RTCPeerConnection(s) so it does not involve transceiver reuse. 

In my experience, replaceTrack is used for things like switching cameras or moving from sending user video to screen sharing, so it is orthogonal.

> 2. Do you have a large number of transceivers?

Large number of participants != large number of transceivers, necessarily. For example, I have seen very large Online Courses with 1000+ participants where students do not send audio or video unless they are asking a question. The student receives audio/video from the Professor, and maybe the last few students who ask questions, but only a few transceivers are needed at a time. In this scenario the Professor and student questioner transceivers are “recv-only” as seen on another student’s browser and the student’s own transceiver only becomes “send-only” instead of “inactive” when authorized to ask a question.

Received on Friday, 1 February 2019 20:02:07 UTC