Not sure if there’s some hidden away method for this somewhere, but it’d be really handy if we could force a minimum bitrate/bandwidth utilisation for the video stream - usually I use around 30-40Mbps with a Quest 1 but once the bitrate drops it can hover around 10Mbps and not come back up even when it has plenty of headroom to.
4 Likes
Hello Ben,
This is actually a problem we are working on. In the meantime you can try using the Foveated Scaling Function to mitigate this problem. Foveated Scaling is covered in section 3.3 of our user guide. On the client the featured is enabled using -f XX command-line option. A typical value of XX is 50 (which means 50% scaling). Give this a try and let us know if this helps with this problem
3 Likes
+1 for forcing a minimum bitrate. Even when streaming from a local LAN with a single client the low bitrate results in a very poor quality feed.
Confirmed that the Foveated scaling function (set at 50%) does not really help the situation or give any significant visual improvement at a streaming bitrate of ~10Mbps.
2 Likes
To be clear, if the bitrate drops to say 10Mbps (instead of more like ~40 per eye), that is a core bug in the bw management logic. Exposing a ‘floor’ would not help, as the logic likely supersedes any minimum value. We have identified an issue where should the server for some reason be unable to match client-requested framerate, it tried to downshift bitrate to accommodate. That logic should be disabled in a next release.
This also was specifically triggering on Quest 2 when you enable 90hz globally, as oculus code tells us the raw ‘UI fps’ rather than the ‘current app fps’. Apps default to 72hz still, so we send the higher rate but can never render out faster than 72, so the server detects and thinks it is overloading client and shifts to lower bitrate. This will be fixed for 72hz in next release, with a future release enabling full 90/120hz mode support in the sample.
This sounds like exactly what I saw, though probably worth noting I’m also only seeing 30Mbps ish in task manager with a Quest one and no FFR, though I suppose 40Mbps per eye may be hit with the Quest 2 at a higher refresh rate perhaps?
So that logic can be connected to a drop in available bandwidth? I seem to recall I achieved it by having two Quest 1s connected to a 20Mhz width 5Ghz wifi channel and then running a speed test on my phone on the same SSID to try and do some extreme tests of how much can be squeezed out of a rather small channel bandwidth.