- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Fri, 9 Oct 2015 19:33:16 +0000
- To: Peter Thatcher <pthatcher@google.com>, Byron Campen <docfaraday@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Peter Thatcher said: "As for what conferencing services want, the one I'm very familiar with wants a resolution scale. So at least the desire for a fixed resolution isn't universal. And, as I already mentioned, services that do want a fixed resolution can send a fixed resolution from the JS via track controls." [BA] The one I'm familiar with would also prefer resolution scale, because it enables a wide range of scenarios while minimizing API complexity. Attempting to specify resolutions in both the encoder as well as in track controls is very likely to result in conflicts and complex corner conditions. AFAICT, it is quite possible to implement the important use cases without that. Peter also said: "I would point out, though, that the conference server really doesn't need to know anything about the RSIDs. It already knows the sizes of the layers from the media itself and can just use that to choose what to forward. It just needs the RSIDs to know which FEC or RTX stream goes with which layer." [BA] Is there a need to include an RSID attribute within Rtx or FEC parameters, rather than just the SSID?
Received on Friday, 9 October 2015 19:33:47 UTC