When starting up the broadcast, the quality is often very pixelated and bandwidth usage is low. Over the span of about 25 seconds, the stream settles and finally begins broadcasting at a constant, high-quality level.
* This is with Chrome on Windows.
We've looked into Chrome-related options and I've seen a few posts that mention "bandwidth estimation" and REMB (Receiver Estimated Maximum Bitrate). I read an article that specifically tested changing the sdp offer message on Chrome to use the new algorithm (old REMB vs new Transport Feedback). However, we did not see any changes when performing the same SDP update that worked for them. What we are looking for is an option to force an initial bandwidth level, so the stream goes to full quality more quickly (a few seconds). We've tested some other RTC demos (local, not one-to-many) and those did not have as long of a ramp-up time as Flashphoner. Is there an option either on the server side for WCS or the flashphoner client library to help with this issue?
* This is with Chrome on Windows.
We've looked into Chrome-related options and I've seen a few posts that mention "bandwidth estimation" and REMB (Receiver Estimated Maximum Bitrate). I read an article that specifically tested changing the sdp offer message on Chrome to use the new algorithm (old REMB vs new Transport Feedback). However, we did not see any changes when performing the same SDP update that worked for them. What we are looking for is an option to force an initial bandwidth level, so the stream goes to full quality more quickly (a few seconds). We've tested some other RTC demos (local, not one-to-many) and those did not have as long of a ramp-up time as Flashphoner. Is there an option either on the server side for WCS or the flashphoner client library to help with this issue?