Nvenc encoding problem, '(' in 'high'/"value "high"

MableMunroe commented 1 week ago

Description

Hi there! There's a lot of etiquette surrounding bug reports I'm not super familiar with and I'm not experienced so please excuse me if I do something wrong.

Seems like this problem is happening again. https://github.com/alvr-org/ALVR/issues/2064

Here's some logs 21:24:32.854269188 INFO GPU supports H264 profile. 21:24:32.854335135 INFO GPU supports HEVC profile. 21:24:50.110038032 INFO Server connected 21:24:57.440106778 INFO Initial socket buffer size: send: 87040B, recv: 131072B 21:24:57.478953547 INFO Initial socket buffer size: send: 212992B, recv: 212992B 21:24:57.478976417 INFO Set socket send buffer succeeded: 425984 21:24:57.478981593 INFO Set socket recv buffer succeeded: 425984 21:24:57.480907511 INFO Render Target: 4288 2240 21:24:57.480946149 INFO Refresh Rate: 80 21:24:57.481118259 INFO CEncoder::Run 21:24:57.481181358 INFO CEncoder Listening 21:24:57.482189714 INFO CEncoder client connected, pid 2715, cmdline /home/[user]/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrcompositor 21:24:57.528456740 INFO Using Vulkan device NVIDIA GeForce RTX 3060 21:24:57.857878649 INFO Using device path /dev/dri/renderD128 21:24:57.865223646 INFO FrameRender: Input size 4288x2240 21:24:57.866816048 INFO FrameRender: Output size 4288x2240 21:24:58.323060521 ERROR Encoder: Undefined constant or missing '(' in 'high' 21:24:58.323286876 ERROR Encoder: Unable to parse option value "high" 21:24:58.433278818 INFO Using NvEnc encoder

video looks great for a second and then completely falls apart over time.

Environment

Arch linux,

Hardware

(sorry for the neofetch print, i didnt really know what else to do)

               -`                    MORP@MORPArchDesk 
              .o+`                   ----------------- 
             `ooo/                   OS: Arch Linux x86_64 
            `+oooo:                  Host: Z270P-D3 
           `+oooooo:                 Kernel: 6.10.8-arch1-1 
           -+oooooo+:                Uptime: 11 mins 
         `/:-:++oooo+:               Packages: 1571 (pacman) 
        `/++++/+++++++:              Shell: zsh 5.9 
       `/++++++++++++++:             Resolution: 2560x1440 
      `/+++ooooooooooooo/`           DE: Hyprland 
     ./ooosssso++osssssso+`          WM: sway 
    .oossssso-````/ossssss+`         Theme: Breeze-Dark [GTK2], Breeze [GTK3] 
   -osssssso.      :ssssssso.        Icons: breeze-dark [GTK2/3] 
  :osssssss/        osssso+++.       Terminal: kitty 
 /ossssssss/        +ssssooo/-       CPU: Intel i7-6700 (8) @ 4.000GHz

/ossssso+/:- -:/+osssso+- GPU: NVIDIA GeForce RTX 3060 Lite Hash Rate +sso+:-`.-/+oso: Memory: 6472MiB / 32056MiB ++:. -/+/ . `/

| NVIDIA-SMI 560.35.03 Driver Version: 560.35.03 CUDA Version: 12.6

Audio: audi-i dont know. pipewire.

Installation

ALVR Version: 20.10.0

SteamVR Version: 2.7.4

Install Type: used the tar for linux

Xaphiosis commented 1 week ago

Fixed in nightly, see https://github.com/alvr-org/ALVR/pull/2338 (v20.10.0 was 15 Aug, the PR is 18 Aug). This error doesn't seem to do anything besides complaining that some x264 options don't apply to HEVC. If you're having issues with video falling apart, it's probably not related to this error. It's more likely network, bandwidth (e.g. overwhelming the headset's decoder), and so on, but hard to tell from here.

Suggestions:

try the nightly and see if it works for you
try lower bandwidth (e.g. for x264 I'm using "ConstantMbps": 200 but for HEVC I wouldn't bet on over 150)
try switch to x264
as a last ditch effort, try downgrade to something like 20.8.1 and see whether that produces anything interesting

The-personified-devil commented 1 week ago

x264 would be software encoding, so you probably mean h264. The more likely cause for video quality deteriorating after initially being fine is more likely something with i- and b-frames tho

Xaphiosis commented 1 week ago

Yup, I meant h264, whoops. The question would be why is mine working ok (Ubuntu 22.04, nvidia 550, RTX 3090, ALVR 20.10.0, Pico 4) but his isn't. Hard to tell without more info. Packet loss plus too high resolution/bandwith making it impossible to recover? To nitpick back, ALVR uses P-frames, not B-frames, right? B is bi-directional and when going for low latency you'd not want to get the next frame first...

MableMunroe commented 1 week ago

Hi! First let me just thank you for this work. Absolutely brilliant, and imo, crucial. XR NEEDS to have the ability to run free software, and this is the biggest current use case. So thanks!

First, the behaviour was observed on both h264 and HEVC profiles, obviously AV1 doesn't have hardware encoding on nvdia so I couldn't test it.

Just as a bit of info before I try the nightly and then trying to downgrade, I'm using a Quest 3, which I've used extensively with Virtual Desktop, Remote Display (beta) [meta's utility], and steam link. I've got line of sight to a wifi 6 router, and can consistently pull 200 mbps bitrate without any errors in those solutions, as well as things like game streaming with sunshine using the same drivers, cards, whole setup. Not sure if any of that is actually useful, but there you have it. I recently switched from windows to linux for all of my main rigs, which is why I'm inexperienced with all of this. Virtual Desktop and the other mentioned solutions also work correctly with this setup using two GPUs, rx480 as the Linux main, with dedicated direct passthrough from the rtx 3060 to a windows virtual machine, running the atlasos windows 10. I do not have access to that system anymore for troubleshooting, but just thought it might be useful info.

MableMunroe commented 1 week ago

Good news, switching to nightly (currently v21.0.0-dev01+nightly.2024.09.09 i think) completely solved the problem.

Xaphiosis commented 1 week ago

Many happinesses! Release is coming soonish. Could you close the issue please?

alvr-org / ALVR