- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Aug 2018 07:49:55 +0000
- To: public-webrtc-logs@w3.org
For [2], the priority definition in -transport gives the answer: If both a priority "low" and a priority "high" stream is available, and neither can fit within the bandwidth set by congestion control, one is supposed to send 4 bytes from the "high" priority stream for every byte sent from the "low" priority stream (chunked into packets, of course). Neither stream should be fully dropped, unless it's impossible to produce an useful stream at that bandwidth that satisfies the configuration constraints.. I think the simulcast document needs to have an introduction/terminology section that defines the words used to describe sending, reconfiguring and dropping of simulcast layers. If we can get a straightforward principle established that says "the sender platform keeps a list of simulcast streams, with the most easily sent stream being at the top and the one that requires most resources to send at the bottom; when limitations such as bandwidth restrictions make the bottom stream have no extra value, the platform is allowed to stop sending the stream". Or something like that. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1964#issuecomment-413121285 using your GitHub account
Received on Wednesday, 15 August 2018 07:49:57 UTC