White horizontal stripe across screen while using link

[Panzer_mk2]

Headset seems to work fine stand-alone.  I use the headset with IRacing, and often (not always) get a translucent horizontal stripe across the screen after about 15 minutes or so.  It doesn't feel like the headset is overheating.  This doesn't show up on the screen mirror on PC, or if I "mirror" with the debug tool.  Is this likely a failing display or is there somewhere else I should look?

[benji94]

Great.  Those temps look very good to me.  Just one more thing would be very helpful.  Save a copy of your Oculus log entries for the period that you are in the game for both when the stripe appears and then when it doesn't.  A comparison of those logs could give a really good clue and possibly and error message of some kind that we can then relate to the stripe appearing.  

Especially without the stripe appearing and you don't see the message "encoder backup" but it is logged when it the stripe appears would really tells a lot.

Thanks.  

[Its71]

Alright everyone, now I found not a confirmed fix for everyone but something that officially worked for me (a permanent fix).
This was posted by an oculus support member on another thread

The Fix: Factory reset your headset 

1. Turn off your headset.
2. Hold the power and volume (-) button on your headset down simultaneously until the boot screen loads on your headset.
3. Use the volume buttons on your headset to highlight Factory Reset and press the power button.
4. Use the volume buttons on your headset to highlight Yes and press the power button.
5. After the factory reset is done, setup your headset, and the problem should be fixed.

After dealing with this issue for MONTHS and going through every possible fix to get it working again, this surprisingly was the only thing that worked. I tried restarting it, configuring things in the Oculus Debug Tool, installing other tools, and it never came to me that I should just try fully factory resetting the headset (which worked) so I'm really glad I'm able to play VR again without the white stripe problem, and I'm hoping this works for others as well.

If this does work for you, I want to credit the user who posted this his forum name is "MetaQuestSupport" I'm not sure if this is a user ran by multiple moderators, so unfortunatently I don't know the exact person's name. But this worked for me after every possible thing I could try.

[Ryudar]

I've had the white stripe after about 20 minutes and checked the service file, but encoder backup didn't show up this time.

I've upgrade from a 3070 to a 3090 a few months earlier (white stripe appeared on both), so VRam is no isse.

I'm currently trying this factory reset tip, because that's one thing I haven't tried yet.

[Pokebert]

I have noticed that this is related to the horizontal encoding slices that are visible only through the Link Cable. A very easy stopgap solution would be to offer a toggle in the OculusDebugTool that allows us to turn OFF these encoding slices. Additionally, the encoding slices do not appear with Air Link and thus the issue has almost never occurred wirelessly according to both personal experience and these threads.

[benji94]

I had hoped to be able to start posting the information that I've found on my investigation of this issue yesterday but some of life's hurdles got in the way.

I'm going to post what I've found in installments and so this is the first one:

So let’s tackle this question first:   How, exactly, does Oculus Link software work? 

Here is a link to an article by Oculus developers that explain in detail how Oculus Link works:

How does Oculus Link Work? The Architecture, Pipeline and AADT Explained

Weeding through the technical jargon, it basically boils down to this:  the Quest headset is, for all practical purposes, a display device.  It is accepting a data stream through a USB port and cable that is generated by the GPU and then displaying that data onto its display panels.  The only difference between it and the way a monitor works, albeit an important one, is that the data stream is compressed by the GPU encoder in order to transmit the necessary amount of data for VR and the Quest 2 must then decompress the data stream before displaying it.

So the game app runs on the PC, the PC CPU renders the physics (draws the objects principally) and then sends the frames to the PC GPU which fills in lighting, color, textures and other visuals.  Once each frame is complete, instead of sending the image directly to a connected monitor screen it compresses the frames through the GPU’s encoder, transmits the compressed data stream internally to the PC’s USB controller (via the CPU) which then delivers the data stream to the USB port connected to the Quest 2 by cable.

When the Quest 2 receives the data stream it first decompresses the frames which are then sent to the Quest compositor for display.  Before the frames are displayed they are first adjusted for the curvature of the Fresnal lenses (barrel distortion).  There are two other processes that occur at this point.  One is Asynchronous Space Warp (ASW) and the other is Asynchronous Time Warp (ATW).

ASW was introduced by Oculus in 2016 and is an algorithm which calculates the motion between previous frames to predict how the next frame should look.  ASW can be set by the user to either be on or off.  When enabled ASW automatically detects when an app is consistently dropping multiple frames over a short time period and then force the application to run at a ½ framerate (45 fps instead of 90 fps) while synthetically generating every other frame.  When enabled the “fake” frames are passed on to the compositor for display.

ATW “is a technique that warps the rendered image before sending it to the display in order to correct for head motion that occurred after the scene was rendered and thereby reduce the perceived latency”.  (Michael Antonov, Meta Chief Software Architect)

ATW adjusts for any change in headset tracking between the time a frame was rendered and it is ready to be displayed.  It reads the current headset positioning and determines if there has been a change.  If so, it reprojects the previous frame with the current tracking data to compensate for the position change and then forwards the frame for display.  ATW occurs with every frame and is not a process that the user can disable.

A more detailed explanation can be found here:

Asynchronous TimeWarp (ATW) | Oculus Developers

And here:

Asynchronous Timewarp Examined (oculus.com)

Specifically what changes to a rendered frame may occur once received from the GPU, if any? 

The headset receives a compressed data stream of already rendered frames from the PC’s GPU and displays those frames after decompressing them.  So besides transmitting tracking and audio data between the headset and the PC the headset is primarily a display device when used for PCVR apps.  The Quest 2 does have its own GPU to render frames when it is used as a standalone VR headset but its GPU is not in play when connected via Link for PCVR. 

Therefore there is no apparent ability for the headset itself to introduce artifacts into a rendered frame that it receives from the GPU.  Any artifact, like the white horizontal bars or anything else in the frame, must have already been incorporated into the frame at the time of rendering by the PC’s GPU. 

What can cause a frame to be corrupted once it is received by the Quest 2?

Could there be a problem with how the Quest 2 decompresses the received frames from the PC’s GPU that would introduce the white line stripe?  It is unlikely for the following reasons:  if so, the problem would be occurring with a much larger number of users and with a much larger number of games.  In fact, most likely ALL games over wired link and it would be much more consistent instead of random in many cases.  But we are not seeing that.

Could the issue in some way be occurring with the Quest 2 display compositor and/or the result of the ASW or ATW processes.  Again it is very unlikely because if so the problem would be occurring outside of Oculus Link when used in standalone mode.  The display compositor is the same and works the same way with either frames generated through PCVR and received via cable or frames generated when used as standalone VR.

Therefore, the issue must be originating during the rendering of the frames by the PC’s GPU.

[benji94]

Now let’s look at this next question:  What changes were made to Oculus Link software between v23 and v24?

First of all, there was no v24 headset update.  There was a v24 update to the Oculus PC app that was described as an “internal stability update.”  It was followed by the v25 update that was rolled out for both the PC app and the headset.  So what changed between v23 and v25 that may have contributed to the problem?

It turns out there was a bug in the v23 update:  The ‘encode resolution width’ setting in the Oculus Debug Tool (ODT) defaulted to a delivered resolution of ‘2064’ no matter what the user set it to.  This was apparently fixed in v25.  I suspect that this v23 bug is what led to the issue seemingly arising with the v25 update and after.  Instead of a problem with v25, and subsequent versions, the issue didn’t occur because of users inability to change the ‘encode resolution width’ in v23 (and presumably prior versions though I haven’t been able to confirm that) even though they thought they were.

It turns out that the ‘encode resolution width’ setting in the Oculus Debug Tool (ODT) is a setting that has one of the largest impact on PC GPU memory resources.  A number of users have reported the white stripe disappeared for them after making changes to this setting.  More about this setting and why it potentially plays an important part of the problem occurring for some users

With v23, released in Nov. 2020, the headsets default refresh rate was changed from 72 Hz to 90 Hz.  Also, one of the big improvements released with v23 was the ability for the user to set the bitrate in ODT.  Previously it defaulted to 150 Mbps.  Now the bitrate could be raised to 500 Mbps.  Oculus Link sends frames to the headset via a USB port using a compressed video stream.  Compression of the video stream lowers the quality of the image and can introduce artifacts.  The ability to increase the bitrate allows more data per second to be transmitted and therefore increases the image quality and reduces the potential for artifacts.  V23 also enabled higher framerates for Oculus Link.  Now a framerate from 72 Hz up to 90 Hz could be selected and a rendering resolution slider was available. 

So what changed with v25?  V25 was a large update that was rolled out around of the first week of February 2021.  Many new features were made available, among them:  Messenger, Voice Commands; Guardian 2.0 and Passthrough shortcut; VR profiles; Universal Menu; Oculus Browser; and Bluetooth just to name a few.  Also, the ‘encode resolution width’ setting bug was fixed.

So now a much larger rendering workload was available by the end user to assign to their PC and they did so to get a better looking display.  Not surprisingly however, users began complaining of issues with the v25 update including connection issues, lagging, frame drops, stuttering, and audio issues.  And, of course, the white horizontal line issue first began to occur.  Many users voiced the desire to rollback to v23.

Next up:  Generally, what are possible causes of display artifacts?

[Pokebert]

UPDATE: POSSIBLE WORKAROUND/FIX USING REGISTRY EDITOR

As I theorized above, this issue does NOT occur for those who use Air Link. Air Link uses HEVC and uses 1 slice for its encoding, whereas wired Link uses H.264 and 5 slices for encoding. Whenever the white bar issue occurs, it is very likely the final 5th slice experiencing an error in the encoding. If you pay close attention when this occurs, you will likely notice it only occurs in the bottom slice of the screen.

To use this workaround, open Command Prompt and use the following:

• reg add "HKEY_CURRENT_USER\SOFTWARE\Oculus\RemoteHeadset" /v "numSlices" /t REG_DWORD /d "1" /f

I will be experimenting with this for the next few weeks to make sure  I do not get the white bar issue!

[Pokebert · Accepted solution]

UPDATE: POSSIBLE WORKAROUND/FIX USING REGISTRY EDITOR

As I theorized above, this issue does NOT occur for those who use Air Link. Air Link uses HEVC and uses 1 slice for its encoding, whereas wired Link uses H.264 and 5 slices for encoding. Whenever the white bar issue occurs, it is very likely the final 5th slice experiencing an error in the encoding. If you pay close attention when this occurs, you will likely notice it only occurs in the bottom slice of the screen.

To use this workaround, open Command Prompt and use the following:

• reg add "HKEY_CURRENT_USER\SOFTWARE\Oculus\RemoteHeadset" /v "numSlices" /t REG_DWORD /d "1" /f

I will be experimenting with this for the next few weeks to make sure  I do not get the white bar issue!

Original Post on REVISITED thread:

I have noticed that this is related to the horizontal encoding slices that are visible only through the Link Cable. A very easy stopgap solution would be to offer a toggle in the OculusDebugTool that allows us to turn OFF these encoding slices. Additionally, the encoding slices do not appear with Air Link and thus the issue has almost never occurred wirelessly according to both personal experience and these threads.

[Pokebert]

I think when we get the encoder backup error, it is because NVIDIA’s encoder is having a difficult time keeping up with the multiple slices of encoding! Sliced encoding is done to reduce latency by around 5-10ms. 

Notice how no one ever comes across this issue with Air Link? Yeah, Air Link doesn’t use sliced encoding the same way - it doesn’t split the rendering/encoding into 5 separate slices but just does it all as a single slice. Please see my above comment for a more thorough explanation and possible workaround. 

[AdrianRode]

Guys, what do you think - does changing slices to 1 have any influence on overall performance (fps, stutters, etc.)?