Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Higher encoding bitrate #112

Open
knightsun2010 opened this issue Aug 13, 2021 · 24 comments
Open

Higher encoding bitrate #112

knightsun2010 opened this issue Aug 13, 2021 · 24 comments

Comments

@knightsun2010
Copy link

Do you have plan to increase the encoding bitrate? after did a lot of comparisons between different wireless link solutions, I think100Mbps is not good enough. Oculus Airlink also limits 100Mbps bitrate for AMD cards but supports 200Mbps bitrate for Nvidia cards, VD can support150Mbps bitrate and ASVR even support more, so it doesn't look like a technical problem, why relive doesn't support higher bitrate?

@GennadiyAMD
Copy link
Contributor

@knightsun2010 - we found in our experiments that the network becomes a bit problematic about 100Mbps. Games with lots of motion in them (think of a rollercoaster or a car racing game) start looking a little jittery, which becomes progressively worse as the bitrate increased. How much worse depends on your router, its placement and the amount of interference around it and what's worse, more expensive routers often performed worse than some of the cheaper models. Yet, the visual quality at, say, 120Mbps was virtually indistinguishable from 100Mbps in most scenes. It's a balance between smoothness and MPEG artifacts and we felt that 100Mbps was a good compromise between the two. Other than that, there's no other reason for not going higher.

We could increase the limit, but we're concerned that it could be detrimental to some users who use ReLive VR in high noise environments with not so good routers. If you want to maximize image quality, make sure you enable non-linear scaling and if your GPU permits, stay around 1660x1600 to 1800x1800 per eye for encoder resolution for Quest2. Anything Navi should be able to handle this easily. Going above that would not make the image look much crisper. For the original Quest 1440x1440 - 1472x1472 is the optimal resolution.

@knightsun2010
Copy link
Author

@GennadiyAMD thank you for your quick response and detailed explanation, good to know it is easy to increase the bitrate and just need more reasonable reasons.

As more and more users start to use wireless streaming VR devices, most of the users are aware of how important the router is, the user like me who is sensitive of the latency even use dedicate router for VR, please find attached 2 log files which framerate set at 90 and 120 respectively, the average network latency of my devices is around 5ms when setting decoding resolution @1832x1920 bitrate@100Mbps, I think to increase the bitrate is not a problem at all for my system. My router is a very old Apple time capsule which was produced in 2012, recently, more and more wifi6 routers are available in the market and people are willing to pay more for the router for a good VR experience, if the users like VR, they will spend time to troubleshooting their system include setting wifi channel to avoid interference and noise.

And users are more and more familiar with bitrate settings depends on different applications, for motion and racing games, users can set low bitrate, for other applications which are not very latency sensitive like space engine, DeepStates, steaming desktop 3D movies, etc, higher bitrate is necessary. If you are concern about some of the users who will get poor experience because of their router, you can do the same as you did for selecting AVC and HEVC, limit the bitrate at 100Mbps at Radeon Software and enable users to configure higher bitrate through WebGUI. So the users who are more familiar with VR and has the practical ability can configure higher bitrate according to their system and application,

100Mbps is enough for streaming 1080p@60FPS, but for VR like quest2, 50Mbps per eye for 1832x1920@90FPS is far from enough for some applications, the quest2’s pixel number is near 1.7x of 1080p but the bitrate for per frame is only 1/3 of 1080p@60FPS@100Mbps, and with the VR lens, the poor image quality looks like be magnified, now quest2 support even 120FPS, the bitrate for per frame become even lower, I compared the image quality in different framerate include 120FPS, 90FPS, 60FPS and 30FPS, 120FPS is totally unacceptable, 90FPS is better but poor image quality due to low bitrate is easily noticeable, the quality becomes noticeable better and better @60fps and 30FPS.

It seems like it was 2 years ago when you decided to use 100Mbps as the limits, it will be good if you can reconsider it and increase the limits to 300Mbps or more, I believe users are capable to find suitable bitrate by themselves according to their environment and application.

@knightsun2010
Copy link
Author

AMDWirelessVR@90.log
AMDWirelessVR@120.log
@GennadiyAMD add the log files FYI, thanks.

@GennadiyAMD
Copy link
Contributor

@knightsun2010 - sorry for the late answer. Actually, even now you can manually edit the settings.json file and put up to 170Mbps there if your router can handle that. It will cost you a few ms of latency though due to transmission taking a bit longer, extra copying of the buffers, etc.

We'll consider increasing the limit in the UI.

Having said that, there's really not much value in matching the stream resolution to the panel resolution. Because of the lens distortion correction there's scaling even when they match. And with non-linear scaling enabled, the center of the frame would get pixel density close to 1832x1920 at about 1600x1600 and periphery is going to be fuzzy because of the lens aberrations anyway. You'd be paying the price of increased latency with little to no benefit to visual quality.

@knightsun2010
Copy link
Author

@GennadiyAMD thank you for your response and it's really good news.

I tried to configure the bitrate in the settings.json file, but it doesn't work, according to the log file, it still uses 100Mbps, 50Mbps for per eye when I set 120Mbps, I installed the latest 8.1 driver, tested both AVC and HEVC, please find my logs and json file, did I miss anything?
AMDWirelessVR@AVC120Mbps.log
AMDWirelessVR@hevc120Mbps.log
settings.zip

With regard to the resolution, I just set the same value of Oculus Link, have to say AMD did a great job to provide RNDA2 graphics card to the market, I use 6800xt and set the power limit to 270W, increase the clock to 2600Hz@1.03V, it can handle most of the VR game with high resolution, so I didn't spend time on comparing video quality with different resolution, just set the oculus link resolution and it works fine.

@GennadiyAMD
Copy link
Contributor

@knightsun2010 - please try the latest Adrenalin driver (21.9.2) - should work there. Thanks for the feedback and your patience! :)

Btw, we have just posted a v2.0 beta of the client app with microphone support - feel free to give that a try to.

@knightsun2010
Copy link
Author

@GennadiyAMD Thank you for the good news. I just did a quick test but it doesn't work on my PC.
I used DDU and AMDcleanutility to uninstall the previous driver under safe mode and installed 9.2 drivers, when setting bitrate higher than 100Mbps through WebUI, the error message "Property 'VideoBitrate' is not valid" still present, so I manually changed the bitrate in the settings file but it doesn't work either. any comment would be appreciated.

@knightsun2010
Copy link
Author

@GennadiyAMD I did a quick test of the 9.2 drivers, it has the same issue with 9.1 i.e. the peak of power consumption exceed the TDP too frequently, sometimes it exceeds 400w even when I only set the TDP limitation to 271W, I didn't saw it on the 8.2 drivers, it would be good if you can help to check if this is normal or not.

@GennadiyAMD
Copy link
Contributor

@knightsun2010 - confirmed that WebUI is giving the error you described, looks like the change I made has not worked its way to the release - sorry for missing that. But setting it manually in settings.json seems to be working for me with 21.9.2 - just checked, set to 1500000000 in settings.json and the traffic shown by Windows Task Manager is somewhere in the range of 135-145Mbps while streaming and going down to pretty much zero when I disconnect. Check your AMDWirelessVR.log file - the bitrate that was set is reported there, should match what you set in settings.json.

I can't help with power consumption though - all power management is done by different teams, I don't know much about that. It doesn't sound like it's related to streaming though - most power is consumed by 3D rendering, the encoder is fairly lightweight in comparison and that's the only extra block involved in streaming compared to running the same VR content with a wired headset - I can't see the encoder consuming 130W even with peak load.

How are you measuring power consumption? Are you talking about GPU power or total CPU+GPU power?

@knightsun2010
Copy link
Author

@GennadiyAMD Just copied your number 1500000000 and adopted it in my settings.json, the overall bitrate in the log is 50M as
below
2021-09-24 18:02:03.640 4398 [VideoPipeline] Info: Video bitrate (overall) changed to 50.00 Mbps
2021-09-24 18:02:03.640 4398 [VideoPipeline] Info: HEVC Video bitrate changed to 25.00 Mbps for left eye
2021-09-24 18:02:03.640 4398 [VideoPipeline] Info: HEVC Video bitrate changed to 25.00 Mbps for right eye

When using 150000000, the overall bitrate is 100M, I tested it when enabling the WebUI and disable it, both were not working as expected. can you share your settings.json file with me so I can check if it works on my PC?

Understood the power consumption issue is not your work, I was talking about the GPU power only, I am not sure if it is a critical issue but I didn't see such high numbers before, the TDP of 6800xt is much lower than 400W, and I set the limitation as 271W in Radeon Software but I saw it exceed 400W many times through Radeon Software itself or GPUZ. it would be great if you can share this info with the team who is working on it. thanks.

@knightsun2010
Copy link
Author

AMDReliveLog.zip
Please find my log and setting file. Thanks.

@GennadiyAMD
Copy link
Contributor

@knightsun2010 - Here's the settings.json that works for me. The only relevant difference that I see is codec, but I've tried changing it to hevc and monitoring the network utilization in Windows Task Manager - I get close to 150Mbps as expected with either codec.

Which client app are you using? The new 2.0 or the old 1.0.x?

settings.zip

@knightsun2010
Copy link
Author

@GennadiyAMD I tried both 1.0 and 2.0, but in order to do a quick test, I happened to set the eye resolution to 2000 and left encoding resolutions to 0, it showed black screen to me. after I change the resolution, v2.0 works for me now, v1.0 still not work.

I noticed the encoding time of v2.0 reduced a lot compared to v1.0, so even I set the bitrate to 170Mbps, the latency is around 60 ms which is totally acceptable for most applications, thank you for your great job.
When I set bitrate@150Mbps, the bandwidth stable at around 130Mbps, When I set bitrate@170Mbps, the bandwidth stable at around 150Mbps, it seems that it always keep 20Mbps for headroom or something else, is it possible to increase the limitation more so we can get higher real stable bandwidth? thanks.

@knightsun2010
Copy link
Author

@GennadiyAMD
Some feedback of using relive v2.0
1 Different behavior when selecting different codec
When setting the encoding codec as AVC, the bitrate is very stable, when I only stream steamvr and steamvr desktop, the bitrate is stable at around 150Mbps, the performance is similar with VD and Airlink(when using Airlink, the bitrate is limited at 100Mbps but the actual transmission in Windows Task Manager is 150Mbps)
When setting the encoding codec as HEVC, the bitrate is very unstable, the bitrate is very low when stream steamvr or the desktop, and some simple scenes in Alyx. The bitrate can increase to even over 200Mbps in some complex environment in Alyx.
The delay of both codecs looks good(around 50ms) but it is easy to notice the image lag, I can see the edge of the screen, the image can’t follow my movement very well. Sometimes the input of the controller is blocked, I can shoot sometimes.
I don’t meet these issues when I using VD or Airlink@ similar settings.
After comparing with VD, I fond
2 decoding time is too high
The average decoding time of relive(both AVC and HEVC) is around 12~13ms, sometimes even increased to over 20ms(HEVC), this may be the reason that caused the image lag, also caused low framerate. FYI VD client’s encoding time is around 6-7ms when using similar settings. I guess increasing the efficiency of using the encoder may be can improve the performace.
Please check the encoding time in the attached log, I copy some of it for your quick reference below.

Most of time the encoder cost around 12-13ms(HEVC)
full 48.09, client 20.19, server 21.33, encoder 4.25, network 6.56, decoder 12.01, fps: 72.33 bandwidth: 111.58 Mbps
full 49.52, client 20.88, server 21.61, encoder 4.28, network 7.03, decoder 13.10, fps: 72.00 bandwidth: 140.93 Mbps
full 50.50, client 21.11, server 22.02, encoder 4.39, network 7.36, decoder 13.88, fps: 72.33 bandwidth: 143.61 Mbps
full 49.68, client 21.22, server 21.77, encoder 4.27, network 6.68, decoder 12.42, fps: 72.33 bandwidth: 106.13 Mbps

Sometimes it increase to around 20ms(HEVC)
full 57.60, client 25.84, server 21.05, encoder 4.59, network 10.70, decoder 24.34, fps: 72.67 bandwidth: 150.27 Mbps
full 56.38, client 26.20, server 21.49, encoder 5.03, network 8.69, decoder 24.64, fps: 72.33 bandwidth: 140.59 Mbps
full 55.93, client 26.47, server 21.70, encoder 4.63, network 7.76, decoder 24.88, fps: 72.33 bandwidth: 157.94 Mbps
full 56.91, client 26.04, server 21.59, encoder 4.78, network 9.28, decoder 24.51, fps: 72.00 bandwidth: 147.83 Mbps
AMDWirelessVRDecode20.zip

@GennadiyAMD
Copy link
Contributor

@knightsun2010 - thanks for the feedback!

Have you limited the frame rate to 72fps somehow? Either through settings.json or on the headset? The following tells me that the headset requests 72fps:
Render Resolution: 2704x2736
Encode Resolution: 1832x1920@72fps
EFC: false
Format: NV12
Bitrate: 170000000 bps
Stereo: yes
SeparateEyeProcessing: yes
Non Linear Scale Supported : yes

But Quest2 should run at 90 or 120fps depending on the setting in the headset settings menu. Do you see 72fps with the old client as well?

Both encode and decode times are proportional to the number of pixels, but are also subject to power management. From that standpoint if frames are submitted at every 14ms, there's no point for the decoder to try to decode faster, so power management software lowers the decoder clocks to conserve battery power and reduce the amount of heat the chip produces. That's the root cause for longer decode time in your case and we need to figure out why this is happening - my Quest2 runs at 120Hz without a problem. Could you please attach your current settings.json?

Bandwidth fluctuations - this is normal for HEVC. h.264 produces a more uniform stream with less peaks. H.264 might be preferable to HEVC at high bit rates.

@knightsun2010
Copy link
Author

@GennadiyAMD I limited the frame rate at setting.json file, because the encoder time, whatever frame rate I set, it drops to around 70 to 80 frame rate, sometimes even lower, the lowest number I saw is 59 fps. The load of 6800xt is around 50-70%, please find the setting file and logs with 90 and 120 framerate. FYI I use 10.1 drivers now.
logs.zip

@GennadiyAMD
Copy link
Contributor

@knightsun2010 - you're hitting encoder performance limits, this line in the log "[AMFEncoderCoreHevc] Info: SubmitInput() Input Queue Full:3" clearly shows this. Please try lowering the resolution and/or bitrate. When selecting encoder resolution, ensure that it's a multiple of 16 pixels in each dimension (1832 is not a multiple of 16). Try different combinations of lower resolutions and bitrates until you no longer see the "Input Queue full" message in the log.

As I mentioned previously, there's no benefit in trying to match stream resolution to the panel's physical resolution. Even when you do that, there's still scaling involved due to the lens distortion correction. It's even less beneficial when non-linear scaling is enabled - in this case the center of the image would effectively be encoded with pixel density higher than the panel's native. I'd try something like 1728x1728 and perhaps ~150Mbps to start with. Also there's no point in rendering at 2704x2736 when you're encoding even at 1832x1920 as it would get scaled down before encoding anyway. You want the image rendered at about 20% higher resolution than the encoder resolution for the non-linear scaling to work efficiently, going any higher would not give you better image quality, but would produce more heat in the GPU, which in turn could trigger a power management event anywhere in the GPU, including the encoder.

@knightsun2010
Copy link
Author

@GennadiyAMD I am back, how are you doing? I loaned my quest2 to my friends for several months and just received it. I found if I put any number higher than 1920 in encoder resolution, it changes to 9161920(in the log) automatically and the screen is black when connecting steamvr. enter 20002000 in render resolution and left the encoder resolution with 0 also leads to the same problem. I am wondering if you limit the encoder resolution? thanks.

@knightsun2010
Copy link
Author

@GennadiyAMD "you're hitting encoder performance limits", according to the log, the encoder time is far away from the limits, but the decoder time looks like hitting the limits, it's strange because oculus link supports the same resolution with up to 500Mpbs bitrate without same problem, I guess maybe the decoder performs different depends on the streaming stability, the relive performs similarly with air link.

@pendragonmikel
Copy link

@GennadiyAMD Is there any chance that ReLive VR will be update to support higher encoding resolutions? ALVR and Airlink allow you to set higher encoding resolutions, but due to Radeon driver issues, don't seem to work higher than around 100MB bitrate. ReLive VR works at 170, but won't support higher resolution as @knightsun2010 posted above. It would be really great to get ReLive VR to feature parity with the other solutions. I realize that it is free, but so is ALVR.

@KieranHare99
Copy link

@knightsun2010 - we found in our experiments that the network becomes a bit problematic about 100Mbps. Games with lots of motion in them (think of a rollercoaster or a car racing game) start looking a little jittery, which becomes progressively worse as the bitrate increased. How much worse depends on your router, its placement and the amount of interference around it and what's worse, more expensive routers often performed worse than some of the cheaper models. Yet, the visual quality at, say, 120Mbps was virtually indistinguishable from 100Mbps in most scenes. It's a balance between smoothness and MPEG artifacts and we felt that 100Mbps was a good compromise between the two. Other than that, there's no other reason for not going higher.

We could increase the limit, but we're concerned that it could be detrimental to some users who use ReLive VR in high noise environments with not so good routers. If you want to maximize image quality, make sure you enable non-linear scaling and if your GPU permits, stay around 1660x1600 to 1800x1800 per eye for encoder resolution for Quest2. Anything Navi should be able to handle this easily. Going above that would not make the image look much crisper. For the original Quest 1440x1440 - 1472x1472 is the optimal resolution.

Will this encoder issue ever be fixed? Can't go over 100mbps on h264 or h265 in Oculus Link/Air Link/ALVR/Even AMD's VR streaming doesn't go over 100mbps when in 170mbps mode. Must say not supporting VR headsets that depend on encoders is really a kick in the teeth for people.

@bernek9000
Copy link

Here I am standing with my 6800XT at 65-75 Mbps with Quest 2 with the latest drivers. How can this be possible for a card that was a lot of money when they got released.

@kzhuang1
Copy link

This seems to be fixed on AMD's side and the hold-up is mainly waiting for Meta to implement changes on the desktop app
see: GPUOpen-LibrariesAndSDKs/AMF#364

@nyte
Copy link

nyte commented Mar 24, 2023

Don't hold your breath. It's been a year. I hate to break this to everyone but, it isn't getting fixed. Meta too busy creating propaganda in order to influence congress people to pass unfair laws that crush it's competition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants