关于18.2.3APK版本运行闪退与19.1.1和20.0.0版本使用时串流画面模糊，马赛克的问题

[fouable]

Description

我的Oculus Quest2设备在安装了18.2.3版本之后运行会闪退，无法运行 在安装了19.1.1版本与20.0.0版本的使用过程中，串流使用第三方应用出现了画面马赛克的问题

General Troubleshooting

• [ √] I carefully followed the instructions in the README and successfully completed the setup wizard
• [√ ] I read the ALVR Wikis here and here

Environment

Hardware

Note: for Linux, an upload to the hw-probe database is preferred: hw-probe -all -upload 小米游戏本， Meta Quest 2（系统版本可能较新） CPU: i7 12700 GPU: 3060（移动端） Audio:

Installation

ALVR Version: 18.2.3 19.1.1 20.0.0 SteamVR Version: 最新版本1.26.2 Install Type:

• [√ ] Packaged (exe, deb, rpm, etc)
• [ ] Portable (zip)
• [ ] Source

OS Name and Version (winver on Windows or grep PRETTY_NAME /etc/os-release on most Linux distributions):

win11，可能是最新版

[Vixea]

Hello, could you please rewrite your message in English and I'll be more than happy to help

[fouable]

I found that the 19.1.1 version of the screen is abnormal when using, like a Mosaic

[fouable]

Hello, could you please rewrite your message in English and I'll be more than happy to help

Version 18.2.3 will crash instantly. Later, I wondered if it was because I installed other versions higher than this version that I did not verify for the time being

[fouable]

Hello, could you please rewrite your message in English and I'll be more than happy to help

About the environment: The issue was found on a 1650 desktop and a 3060 laptop, where the SteamVR version is the latest and the VR device is Meta Quest 2

[fouable]

Hello, could you please rewrite your message in English and I'll be more than happy to help

I used the translation software to translate my question. I'm sorry if you seem confused. Thank you very much for your help!

[Vixea]

what about v20?

[fouable]

what about v20?

I cannot give you an accurate answer on version 20. About this version, I was teaching one of my friends to use this pushing tool, and he gave me feedback about the above picture

[Vixea]

could i see a picture on the issue on v19

[fouable]

could i see a picture on the issue on v19

I should think so! But I have other things now, please wait for a moment, I will reinstall the version 19 to get the picture of this problem

[fouable]

could i see a picture on the issue on v19

be done for！

[fouable]

could i see a picture on the issue on v19

I recently had a request to use the Air Link in Quest 2, but maybe my firmware version was too old to use, so I updated my device, and after the update, I can no longer use any apps from unknown sources, including ALVR

[fouable]

could i see a picture on the issue on v19 The firmware version is V54, and in this version, the unknown source menu is hidden and you cannot see any third-party applications

[fouable]

could i see a picture on the issue on v19

I may never be able to run ALVR on my Quest 2 device again

[Vixea]

Did you make sure it didn't get wiped?

[fouable]

Did you make sure it didn't get wiped?

I am sure

[fouable]

Did you make sure it didn't get wiped?

Unless, of course, updating the firmware will automatically uninstall all my apps

[Vixea]

Depends my update to v54 wiped it for me so it's possible it did for you

[fouable]

Depends my update to v54 wiped it for me so it's possible it did for you

But none of my other apps from unknown sources have been seen, and before that, there were more than 20 such apps

[fouable]

Depends my update to v54 wiped it for me so it's possible it did for you

It's probably not wiped. Instead, the hardware vendor turned off the unknown source application display

[fouable]

Depends my update to v54 wiped it for me so it's possible it did for you

Hello, for various reasons, today I recorded the latest version of ALVR running on my device

[fouable]

Depends my update to v54 wiped it for me so it's possible it did for you

[Vixea]

well it looks like its working?

[fouable]

Depends my update to v54 wiped it for me so it's possible it did for you

My ALVR version is 20.1.0, Windows 10 system 1660 graphics card, SteamVR should be the latest version

[fouable]

well it looks like its working?

yes！But it's hard to see

[fouable]

well it looks like its working?

I recorded a video. Do I need to send it to you?

[Vixea]

sure why not

[fouable]

sure why not

Sorry, my video is over 10m, I'll record a new one

[fouable]

sure why not

https://github.com/alvr-org/ALVR/assets/62919757/256d49ff-e9d2-4a2b-8270-819a9faeb640

[ccloli]

I'm having the same issue since v19, though I resolved it by disabling "Adaptive bitrate", which is the new bitrate algorithm introduced in v19 v17 (sorry I stick to v15.2.1 for a long time so I thought it was added in v19 before). In v20 you can change "Bitrate" -> "Mode" to traditional "Constant" option.

If you're using v20, you can try scaling down your resolution or bitrate, the default medium resolution in v20 is larger than < v19, so it'll eat more performance.

Also if you're using HEVC, no matter which version of ALVR you're using, make sure the bitrate is under 100Mbps, or your Quest's hardware cannot handle it. The bitrate may depends on your resolution and framerate setting, I'm having glitch and freeze issue with 100% resolution on v19 / Low resolution on v20 when setting to 120Hz + HEVC + 100Mbps. So I'm using H264 and I can go up to 300Mbps.

[Vixea]

Some of this information is slightly out of date, but I don't have time right now to correct the out of date bits

[Vixea]

Also the lack of quality smells like out of date configuration of ALVR don't worry I also have been guilty of using out of date information to guide my settings. Could I see your settings.json file?

[ccloli]

Also the lack of quality smells like out of date configuration of ALVR don't worry I also have been guilty of using out of date information to guide my settings. Could I see your settings.json file?

Not the OP and did a quick test just now, but cannot reproduce the issue now. 🤔

The only thing I can see is in v19.1.0, if you enabled Adaptive bitrate, once the game is loading (starting game or loading scenes etc), the video will become blurry for a few seconds. And if you're using HEVC, after game loading, the video quality will become significantly worse, everything is blurry, and never go back to the normal quality.

Here is my config file for v19.1.0.

...though I don't think you need it, cause I don't see the issue in v20.0.0. The blurry problem mentioned before is gone in v20, the video quality is stable before and after game loading (and significately better than v19). And I found the reason I gave up v20 is that the controllers will lose tracking for a while once game loading, but that's another issue.

Instead, in v20.0.0, if I use HEVC with Adaptive bitrate, the video will become glitch and freeze. From the statistics, it's because the client decode takes too much time (around 200ms), maybe it's because the bitrate is too high and Quest cannot handle it.

Here is my config file for v20.0.0.

---

Note again: I'm not the OP, so I recommend @fouable posting your session.json file located under ALVR executable folder (maybe a screenshot of statistic panel to determine what's going on).

@fouable 可以发一下 session.json 文件，位于 ALVR 的可执行文件目录下，方便开发者排查问题。你可能需要压缩为 zip 文件，因为 GitHub 似乎不支持直接上传 json 文件。如果可以的话，也可以发一下出现问题时「状态信息」面板的截图。

[Vixea]

what are you PC's specs?

[ccloli]

what are you PC's specs?

Windows 10 21H2, Ryzen 7 5800X, RTX 3080 (driver 536.40), SteamVR 1.25.8, stream over a wireless router with WiFi-6 160MHz. Quest 2 firmware is v49.

[Vixea]

without foveated rendering your encoder is not going to be having a fun time until sliced encoding/decoding is implemented(default settings shouldn't be that bad now), 0-0 max_buffering_frames please leave that at default that's all that needs to be said

[ccloli]

without foveated rendering your encoder is not going to be having a fun time until sliced encoding/decoding is implemented(default settings shouldn't be that bad now)

Yep I know that, but I do notice the blurry stuff, so I disabled it and I don't see it kills my GPU or Quest with constant bitrate.

0-0 max_buffering_frames please leave that at default

From the GUI it says 1 frame, but I revert to the default 1.5 frames in v20 and don't see any difference with HEVC. Enabling foveated rendering at the same time doesn't work, too.

Everything works fine even not revert these two settings with H.264 (yes, H.264 works fine with constant bitrate and adaptive bitrate, just the lose tracking issue when PC is under heavy load). Pretty sure it's because Quest is unhappy with HEVC + 120Hz, maybe upgrading to v55 may fix the issue. 🤔

[Vixea]

could you try manually editing it to 1.5 while the server is closed and wdym enabling foveated rendering at the same time doesn't work

[ccloli]

could you try manually editing it to 1.5 while the server is closed

Somewhat it fixed, but it's still glitch when the client connects to the server. From statistic panel, the problem is client side decode. The "fixed" is that once you wait for a few minutes, it will back to normal.

wdym enabling foveated rendering at the same time doesn't work

Enable both foveated rendering and resetting max buffering frames doesn't fix the glitch with HEVC.

I upload the video if you want to see, should be valid for around 7 days. I forgot to record the statistic panel (I do think a transparent statistic panel on client side is a good feature), but I'm sure the glitch is because client side decoder is unhappy. And you can see from the first video, when it connects to the server, the blue "Decode" takes more time than usual.

• Video with game playing, once it connects to the server, the stream is glitch already, and statistic panel shows the decoder takes ~90ms. But the glitch become less, and around 2 minutes, the glitch is gone. Also you can see when the game is loading, the controller is fixed at waist, after a while the controller become trackable.
• Video with reconnection to the server, a reconnection will reproduce the glitch.

---

Updated: Here is the statistic panel's screenshot after the second video. It's clear the glitch is because Quest's decoder cannot handle 120Hz HEVC with high bitrate. From my previous test, once I increase constant bitrate to 100Mbps, it'll start glitching, and it's 300Mbps with adaptive bitrate when it first connects. Lower the maximum bitrate to 100Mbps should fix the issue (another prove is PR #1475 ), but it's not the default option, so...

---

Note again, I'm not the OP and I don't have the issue what OP has for now, but feel free if you want to track this problem. 🤣

[Vixea]

Your decoder latency overstep I think is using an outdated value

[Vixea]

nevermind(decoder latency overstep is up to date), try setting

"ConstantMbps": 300,

under mode to something around 128

[ccloli]

try setting

"ConstantMbps": 300,

under mode to something around 128

And... no, it doesn't work. Switching to constant bitrate and set to 100Mbps is fine, but switching back to adaptive bitrate, it still go up to 300Mbps and start glitching.

Video

But like what I guessed before, if I enabled "Maximum bitrate" and set to 100Mbps, it become normal.

Video

[fouable]

sorry，I couldn't get this file in the last two days

[fouable]

session.zip

[Vixea]

Please set your revolution preset to medium, refresh rate should the preset that's higher than the one that's 60hz anyone works, re-enable foveated rendering reset to default if you still think it's too simmery increase the to by .5 buy don't go above .6, and try avoid video glitch

[fouable]

Please set your revolution preset to medium, refresh rate should the preset that's higher than the one that's 60hz anyone works, re-enable foveated rendering reset to default if you still think it's too simmery increase the to by .5 buy don't go above .6, and try avoid video glitch

Ok, I will test according to the Settings you mentioned later

[ccloli]

Not the developer, you can try the developer's suggestion first. But if it doesn't work for you, from my experience, try switching protocol from UDP to TCP. UDP has been optimized since v19, but everyone's physical network configuration is various, maybe your router is not ready for many large UDP packets.

Also a screenshot of statistics panel, a log file or screenshot of log panel may help to diagnose. And since I talked about wireless router just now, what's your wireless router and are you using WiFi 5 or 6 (802.11 ac/ax)? Are you in a place with many wireless devices taking 5G channel? Or since you mentioned you're using a laptop, are you using the wireless interface as an AP? I heard that the hotspot feature comes with Windows doesn't play a good role with wireless streaming, it may laggy and drop packets.

---

如果开发者的建议不起作用，试试看把传输协议从 UDP 改成 TCP。另外你的无线路由器是什么配置，是否使用的 5G 信道，是否周围有很多无线设备？如果你使用的是无线网卡开启热点来串流的，我听说 Windows 的无线热点功能用作 VR 串流的性能非常差，建议使用一个靠谱的无线路由器

[fouable]

ok，I'll try to change the transport protocol，About channel，It is a mixed channel of 2.4g and 5g， i am a vr application developer, in the company，There are a lot of wireless devices out there，I did not use a wireless card to open the hotspot, is a wireless router，thanks for help

[fouable]

I changed the bit rate mode to a constant, the value is set at a little more than 100, and the screen performance seems normal!

[Vixea]

Ok is the issue your having all resolved?

[fouable]

Ok is the issue your having all resolved?

yes ，But now I have to set the Bitrate above 200M to feel that the picture is good, but my hardware equipment seems to be unable to bear it；