-
Notifications
You must be signed in to change notification settings - Fork 214
Description
Encoding thread and Rendering thread appear to be coupled. When you increase Unity rendering framerate ( or leave it unbounded ), the encoding framerate goes up to rendering framerate. When bitrate is controlled with the help of Encoding Parameters (in my experience with com.unity.webrtc framerate cannot be controlled), it is possible to limit bitrate in most cases. We are seeing a strange case where bitrate is bounded with Encoding Parameters, but webrtc traffic is routed in such a way that causes webrtc library to ignore max or average bitrate encoding setting and follow the encoding framerate, which as I mentioned follows the rendering framerate. As a result, I see 130-150 fps in webrtc traffic. This causes the encoder to pump out too much data and the unity web client to be overwhelmed with traffic. The artifacts, referenced in this ticket (#205), are visible as a result of this unbounded bitrate.
The unpopular solution is to limit rendering framerate of Unity to 30 or 60 Hz but it works. Is there a discussion to find a way to decouple encoding thread and render thread to avoid these unfortunate circumstances? Have you ever seen bitrate parameter ignored in some network routing scenarios and not others?
Environment
- OS: Ubuntu 20.04
- Browser chrome
- Unity Version 2020.3.19.f1
- Package version [2.3.3-preview]