I've found a couple workarounds for various issues listed here.

Crash on loading hub world: Setting launch option vrchat://launch?id= with another world id will load that world rather than the hub world. Been using wrld_8ef393c0-a985-4d7e-90f0-33ab10d41ee3:2822 here for the avatar testing world.

Mouse escape in windowed mode: Just set the -screen-fullscreen 1 -screen-width w -screen-height h launch options with the resolution of your screen as w and h.

Mouse sensitivity maxing out when opening/closing game menu: It's pretty annoying but it's fixed temporarily by switching focus from then back to the game by alt-tabbing or using a volume key so a popup showing the current volume quickly grabs and releases focus.

Game locks on exit: Just keep a command line open with killall VRChat.exe to bop the process after exiting :/

System: Ubuntu 18.04.1 LTS | Intel Pentium G3258 | GeForce GTX 750 Ti | Proton 3.7-7 Beta | VRChat 2018.3.1

I have a problem with VRChat even with Stream Output support, the characters and everything on tutorial works fine but you can't load any map after that, the game just freezes.

Hardware/Software info:
Proton 3.16-1
GTX: 750 2 GB Driver 396.54.09
CPU: Intel Core 2 Quad Q9550
RAM: 7 GB

Here is the proton log file:
steam-438100.log.zip

How have things changed with VRChat 2018.4.3? They just performed an engine upgrade along with upgrading various libraries they use.

@owlboy Not for the better unfortunately. VRChat 2018.4.3 segfaults now before even showing for me.

steam-438100.log

Edit 1: because this maybe related to my old cpu's lack of AVX support. Will update once try it on a supported cpu.

Edit 2: I upgraded to an i7 cpu with AVX support but had the same crashing issue until switching from proton 3.16-6 Beta to 3.16-4. Everything's back to working as well as it did before.

System: Ubuntu 18.04.1 LTS | Intel i7 4790 | GeForce GTX 750 Ti | Nvidia 396.54.09 | Proton 3.16-4 | VRChat 2018.4.4

3.16-6 beta works fine for me at home, the menu and at a 40mb room, but a 220 or so mb would not work, using the tv hangs it, certain characters cause hangs. some of the avatars at 'loli's world' seemed to break it as well (one of the top results for avatar worlds) oh! also -force-d3d11 allegedly helps.
System: Gentoo 17.1 | AMD Ryzen 7 1800X | GeForce GTX 1070 | Nvidia 415.25 | Proton 3.16-6 | VRChat 2018.4.4

I just tested it with 3.16-6 beta and can confirm that it works to some extent now-- Turning on the TV hangs it though. Going through several avatar worlds, the game seems to work just fine. I did notice a lot of hangs-- the hangs would cause some nasty mouse wackyness. Except for the TV, however, none of the hangs lasted more than a few seconds and the game resumed working after that. The exit button does appear to hang the game, but I don't see that as a huge issue (it is the Exit button....)

ohhhh this reminds me of a few things i forgot to mention! yeah you have to externally end the process to exit. having any sort of controller plugged in seems to make the mouse 'stick'. however the hangs kept going for me. all hangs were related to certain avatars or to certain worlds (i reattempted the 220mb one A LOT and it always hanged seemingly permanently) i also have a terminal log, but i feel like there's not much useful info to obtain from it, the hangs don't SEEM to create any output
vrchat-log.txt

VRChat has issues closing properly without hanging in some cases on its own on Windows. So that is not surprising.

Since there isn't an issue for the VRChat VR version, and I believe that they are the same App ID (correct me if I'm wrong), I'm gonna add this here:

Once I got SteamVR working and happy, I was able to play several hours of VRChat in VR with my Vive with almost zero issues. There were 1 or 2 models that didn't render correctly, but that was an issue in desktop as well. Performance is about what I would expect from playing some VR games on Windows ~a year ago (last time I booted into Windows). I DID have Direct Mode working, and everything seemed to "just work" other than the Exit button in VRChat. All of the other bugs I hit seem to be actual bugs in the game itself, and weren't the fault of Proton.

Since my initial report was ~5 months ago, here is a new System Info gist to reflect the software changes that have occurred in that time: System Info. I'll add this to the OP as well.

In desktop mode the map "The Great Pug" crashes after ~10 seconds after you join.
Proton 3.16-6 Beta
sysinfo.txt
steam-438100.zip

I've had that issue with the same map as well. I thought it was an avatar, but the map makes more sense because I kept crashing after turning Safety all the way up to max.

In VR, however, the map seems to be fine.

UPDATE: After posting this, I've tried to go to The Great Pug a few times, and it now crashes the game in VR. I'm not really sure what changed, if anything.

I've put over 100 hours into the game at this point, and can say that it works pretty well. Since my last system specs post, I think I've bumped to Mesa 18.3.x, but that is about the only notable change.

So far the game has been working fine with Proton 3.16-7 Beta.

The only things I've found that consistently crashes me 100% of the time is the ingame embedded web player and some shader-heavy worlds. Any world that has an auto-activated web player will crash me within a minute, hitting the button to turn it on in any world where it must be activated will crash right away. Worlds with lots of really fancy shaders also seem to crash the game, but it could also just be something like shader (re)compilation taking so long that I think the game died.

The game hangs on exit 100% of the time. Sometimes when killing the game (clicking the X until KDE prompts to kill wine), it will completely or partially crash SteamVR. I've noticed this happens more when the game has locked up/crashed; however it handles it perfectly fine sometimes. Restarting SteamVR fixes the issue.

I've also noticed that opening and closing the SteamVR Dashboard overlay too many times too quickly can crash the game as well. I started noticing that with 1.2.10, but that could just be because I've spent many many more hours using 1.2.10 than using any other version.

Other than that, the only crashes I experience are usually things that crash other users as well (IE avatars with just insane shaders, lots of resource-intensive avatars in a small area). If anything I've found that I crash less than some other users who run on Windows, as the game seems to handle extremely resource-intensive avatar shaders "well" (The game drops to 1-2 FPS but keeps rendering which allows me to use the menu to leave the world). It isn't pleasant, but the game does survive.

I've also noticed an issue (although I don't know that I've seen it since Proton 3.16-7 Beta activated) where shaders or something seem to keep running. When avatars have really demanding shaders, if I leave the world to other (empty, decently optimized) worlds, I'll often keep having terrible performance. If I go to a world where I usually get 45 FPS, it will be consistently dropping below 30 despite me being the only person there. Restarting the game (and SteamVR, if SteamVR crashes) will fix this. I'll see if I can reproduce this with Proton 3.16-7 Beta; it may have been fixed.

Overall, I'd say that with decently powerful hardware (see my system specs), the game is absolutely playable and a pretty good experience. It isn't perfect (see above for the issues), but most of the issues are usually avoidable and manageable. I absolutely plan to keep playing the game for the foreseeable future, so long as it stays in the current state (or gets better).

I may have found a fix for the video player crash (also fixes The Great Pug):

Browse to the VRChat folder in steamapps/common.

Browse to VRChat_Data, StreamingAssets, and rename youtube-dl.exe to something other than youtube-dl.exe (for example, youtube-dl.exe.no). This will disable the ingame streaming video player completely, but also fix the crashes. You won't be able to watch videos in maps anymore, but at least the game won't crash.

hmmm.... youtube-dl has a linux version, i wonder if it is possible to redirect it so it uses the native one. considering it's a command line application i imagine the commands are the same on both OSes

youtube-dl requires Microsoft Visual C++ 2010 Redistributable Package (x86) per their homepage.
https://www.microsoft.com/en-US/download/details.aspx?id=5555

https://rg3.github.io/youtube-dl/download.html

@Goofybud16 Can you confirm this is installed and available for youtube-dl?

@Goofybud16 Here is a test world that has a Unity Video Player component in it, but it does not use any VRChat video scripts, so it should not call youtube-dl:

https://vrchat.com/home/world/wrld_f994e95a-8c0e-42b2-b894-f9cf6f1c6387

Upon loading, it should autoplay a video from a direct URL. This video should also loop.

If it could be used to test to see if this world also crashes VRChat under Proton, that might help confirm whether youtube-dl is specifically the issue or if it is the video player alone.

Thanks for continuing to test this.

youtube-dl requires Microsoft Visual C++ 2010 Redistributable Package (x86) per their homepage.
https://www.microsoft.com/en-US/download/details.aspx?id=5555

@Goofybud16 Can you confirm this is installed and available for youtube-dl?

As far as what is installed: I just told Steam to use Proton 3.16-6 Beta (and now it uses 3.16-7 Beta after an auto update). I don't see anything for it in the Program Files or Program Files (x86) folders. Whatever Proton and VRChat installed as part of initial setup is all that is installed. What is the best way to install that/check for it?

@Goofybud16 Here is a test world that has a Unity Video Player component in it, but it does not use any VRChat video scripts, so it should not call youtube-dl:

https://vrchat.com/home/world/wrld_f994e95a-8c0e-42b2-b894-f9cf6f1c6387

Upon loading, it should autoplay a video from a direct URL. This video should also loop.

If it could be used to test to see if this world also crashes VRChat under Proton, that might help confirm whether youtube-dl is specifically the issue or if it is the video player alone.

Without Youtube-dl, that world doesn't crash, however it doesn't play a video either.

With Youtube-dl, the same exact thing happens. The video screen is just blank. In the console, I do get the line

Unloading 1 Unused Serialized files (Serialized files now loaded: 2)
UnloadTime: 1.459000 ms
WindowsVideoMedia error 0x80004001 while reading http://thegreatpug.com/video/other/dev_update-1.mp4

Context: Turning DXVA off
Error details: <Empty>
Track types:


(Filename:  Line: 2456)

Thanks for continuing to test this.

Not a problem. I'm just playing the game, most of the testing I've done comes as a result of trying to do something with friends and having it crash me.

As far as "what is the actual problem with the video subsystem", I suspect something on the VRChat side. The first time I go to The Great Pug after an update to the game/map (with youtube-dl), it works. However, all network connectivity outside of other player's movement and voice stops working. Portals don't load, avatars don't load, the menus are broken, and the game log gets filled with NullReferenceExceptions. Trying to Go Home will result in the game loading nothing forever. The second time I join the world, it will crash almost exactly at the 1 minute mark, hanging and maxing out 1 CPU core. Prior to hanging, the game breaks in pretty much the same way. I've had this in other worlds as well. In worlds without an auto-activated video player, the game seems to work fine until it gets turned on. Once it gets turned on, the game instantly hangs.

@Goofybud16 Here is a build of a very basic Unity scene that has a video player configured as it is in my test world in VRC and is playing the same video. The version of Unity used is the same that VRC currently uses. No VRChat code or youtube-dl is involved in this build.
I tested on Windows 10 in VMware to confirm the build runs and plays the video as expected.

http://thegreatpug.com/share/test_video_player.zip

(This has Windows, and macOS builds in it. But no Linux build as I don't have the package installed in Unity right now)

Re: How to install Microsoft Visual C++ 2010 Redistributable Package (x86) for a Proton install.

I am not sure. I actually don't have a Linux box running Proton, and I have never used Proton myself. I am just interested in VRChat, and it running on other platforms. And am trying to help the best I can.

@Goofybud16 Here is a build of a very basic Unity scene that has a video player configured as it is in my test world in VRC and is playing the same video. The version of Unity used is the same that VRC currently uses. No VRChat code or youtube-dl is involved in this build.
I tested on Windows 10 in VMware to confirm the build runs and plays the video as expected.

http://thegreatpug.com/share/test_video_player.zip

(This has Windows, and macOS builds in it. But no Linux build as I don't have the package installed in Unity right now)

I temporarily replaced VRChat with Test Video Player (to replicate as close as possible the environment in use [same wine prefix]) and while it does load up, the video never plays. The video player just stays solid white. If I run with konsole -e %command% (to get a debug log) there isn't really any useful info in the output.

I suspect the problem is that Proton is missing some Windows Media components (or maybe has a bug in some implementation?), and that causes the video to fail to play, which VRChat does not handle well causing it to lock up as it tries to sync playback or something with a video player that isn't playing.

If we could figure out how to make and exe that is called by vrchat (youtube-dl.exe) to run a native linux application, we could have that just redirect the command to native youtube-dl.
I have tinkered a little bit with that, but unforunately just renaming an sh script to youtube-dl.exe and making it executeable doesn't work.
In my case i tried putting cmd /c start /unix /usr/bin/glxgears in to see if glxgears would run instead of youtube-dl.

On the other hand, looking at the proton logs when running owlboys testworld and the test_video_player shows that "mfplat.dll" is being loaded. "mfplat.dll" is part of the windows media feature pack. I tried replacing the builtin mfplat.dll with a windows native mfplat.dll from the windows media feature pack for windows 7. Unforutnately it fails to load.

Could very well be VRChat embeds some config in their exe? I don't have a windows build environment atm. Testing in proton with a local file I get:

Z:\home\vrvm2\.local\share\Steam\steamapps\common\VRChat\VRChat_Data\Syoutube-dl --print-traffic asdf.mp4
Traceback (most recent call last):
  File "__main__.py", line 19, in <module>
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\__init__.py", line 472, in main
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\__init__.py", line 439, in _real_main
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\YoutubeDL.py", line 416, in __init__
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\YoutubeDL.py", line 2332, in _setup_opener
  File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpcs52imf5\build\youtube_dl\utils.py", line 700, in make_HTTPS_handler
  File "C:\Python\Python34\lib\ssl.py", line 439, in create_default_context
  File "C:\Python\Python34\lib\ssl.py", line 390, in load_default_certs
  File "C:\Python\Python34\lib\ssl.py", line 382, in _load_windows_store_certs
ValueError: Empty certificate data

Semi related, appears to be a bug upstream in Python itself:

if sys.platform == "win32":
    from _ssl import enum_certificates, enum_crls

[...]

def _load_windows_store_certs(self, storename, purpose):
        certs = bytearray()
        for cert, encoding, trust in enum_certificates(storename):
            # CA certs are never PKCS#7 encoded

I'm having an issue where it just kind of lingers at the login screen.
Currently using Proton 4.2-2, has anyone experienced this before?

Oh wait! I left it running in the background and it seems to have done it. I've had this issue once on windows with the latest update so maybe it's a VRChat thing! Nevermind!

Tried it again now after a break, so... I was correct that it did load me into a world but everything else is taking centuries to load, including my avatar, social menu, and eventually the app does crash before loading anything aside from the home world. Logs included:

steam-438100.log

After upgrading to 4-2.2, I haven't had any issues playing VRChat in VR. I haven't tested desktop mode yet.

After upgrading to 4-2.2, I haven't had any issues playing VRChat in VR. I haven't tested desktop mode yet.

That's really good to hear, are the video panel issues also resolved?

This is what I'm looking at atm, for some reason things don't load and inevitably hang. I can say I use VRC on the windows side of my PC and it's quite fast in terms of loading content.

I guess I should clarify that I have seen no new issues in 4.2-2. I have not tested a video panel, I will try that.

Earlier I was able to load into both new worlds and worlds I had already loaded into in addition to loading new and existing avatars.

Update: Tried a world with a video player, immediately crashed me when I had the youtube-dl exe in place.

After upgrading to 4-2.2, I haven't had any issues playing VRChat in VR. I haven't tested desktop mode yet.

That's really good to hear, are the video panel issues also resolved?

This is what I'm looking at atm, for some reason things don't load and inevitably hang. I can say I use VRC on the windows side of my PC and it's quite fast in terms of loading content.

VRChat saves a log in AppData. Maybe that shows something useful (even if I doubt it).

I just tested Desktop and was successfully able to load into a world and talk with someone. It seems to work fine for me.

Try disabling the video player (remove the youtube-dl executable) as your issues sound similar to mine when I had the video player enabled.

If anything, the mouse input issues I've had in the past appear to be fixed (which I believe was actually part of some Wine version between 3.16 and 4.2)

I just tested Desktop and was successfully able to load into a world and talk with someone. It seems to work fine for me.

Try disabling the video player (remove the youtube-dl executable) as your issues sound similar to mine when I had the video player enabled.

Disabled video player and it worked for eliminating the crashing! However, everything was still slow to load so I realized my linux machine was connected to both wifi and ethernet. I disconnected from Wifi and now everything loads as it should. I'm wondering if somehow the game gets confused when two internet connections are present. Either way, this looks fantastic so far. I want to hopefully help see if we can't find a solution for Youtube-DL because if so, for all intents and purposes VRChat has a Linux port.

There is still a good amount of worlds that crash the game. At least on nvidia.

Oh no :O What are some examples of worlds that crash? Maybe I can get some logs and post them

_{Sent with GitHawk}

I suspect the video player related crashes may be related to Windows Media Player issues in Wine. When I was doing testing earlier in the thread, I did notice Windows Media Player errors. I wonder if installing Windows Media Player or DLLs in the Proton instance would fix the crashes related to the video player?

I suspect the video player related crashes may be related to Windows Media Player issues in Wine. When I was doing testing earlier in the thread, I did notice Windows Media Player errors. I wonder if installing Windows Media Player or DLLs in the Proton instance would fix the crashes related to the video player?

@Goofybud16 That’s a really good question! Do you happen to have the windows media player errors on hand? I’m away from my PC atm but I can try to see if I can do anything. :)

_{Sent with GitHawk}

Do you happen to have the windows media player errors on hand? I’m away from my PC atm but I can try to see if I can do anything. :)

https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-468069940

Check the second half of that comment. That was really the only useful log output I got IIRC

Do you happen to have the windows media player errors on hand? I’m away from my PC atm but I can try to see if I can do anything. :) ...

@Goofybud16

Sweet! Thank you so much, did some research and it appears the same error occurred for the game listed here when loaded in Proton:
https://github.com/ValveSoftware/Proton/issues/1102#issuecomment-419660570

Wondering if perhaps their solution may work here as well. May have to contact the person who got it working and get a general idea as to how they did it :)

_{Sent with GitHawk}

I wasn't able to get it to work. Here is what I tried to do:

Copy

mf.dll
mferror.dll
mfplat.dll
mfreadwrite.dll
msmpeg2adec.dll
msmpeg2vdec.dll
sqmapi.dll

from a Windows 7 install from System32 and SysWOW64 to the respective locations in the Wine Prefix.

Export the entire HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation from a Windows install registry to a file called wmf.reg.

Put

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Wine\LicenseInformation]
"msmpeg2adec-AACDecoderV2AddInEnable"=dword:00000001
"msmpeg2adec-AACDecoderV2InSKU"=dword:00000001
"msmpeg2adec-DolbyDigitalDecoderV2AddInEnable"=dword:00000001
"msmpeg2adec-DolbyDigitalDecoderV2InSKU"=dword:00000001
"msmpeg2vdec-H264VideoDecoderV2AddInEnable"=dword:00000001
"msmpeg2vdec-H264VideoDecoderV2InSKU"=dword:00000001
"msmpeg2vdec-MPEG2VideoDecoderV2AddInEnable"=dword:00000001
"msmpeg2vdec-MPEG2VideoDecoderV2InSKU"=dword:00000001

[HKEY_CLASSES_ROOT\CLSID\{271C3902-6095-4c45-A22F-20091816EE9E}]
@="MPEG4 Byte Stream Handler"

[HKEY_CLASSES_ROOT\CLSID\{271C3902-6095-4c45-A22F-20091816EE9E}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}]
@="File Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{48e2ed0f-98c2-4a37-bed5-166312ddd83f}]
@="MFReadWrite Class Factory"

[HKEY_CLASSES_ROOT\CLSID\{48e2ed0f-98c2-4a37-bed5-166312ddd83f}\InprocServer32]
@="mfreadwrite.dll"
"ThreadingModel"="Both"

into a file called mf.reg.

Then, run the following:

export WINEPREFIX=/path/to/SteamLibrary/steamapps/compatdata/438100/pfx
wine start regedit.exe mf.reg
wine64 start regedit.exe mf.reg
wine start regedit.exe wmf.reg
wine64 start regedit.exe wmf.reg
wine regsvr32 msmpeg2vdec.dll
wine regsvr32 msmpeg2adec.dll
wine64 regsvr32 msmpeg2vdec.dll
wine64 regsvr32 msmpeg2adec.dll

This did seem to eliminate the DXVA errors, but the game still doesn't work. When I put a video in the video player in Room of the Rain, it seemed like it wanted to work, but eventually crashed.

The only relevant log section I could see with an error was:

2019.04.07 11:54:39 Log        -  [Network Processing] RPC invoked _SendOnSpawn on SceneEventHandlerAndInstantiator for goofybud


2019.04.07 11:54:39 Exception  -  NullReferenceException: Object reference not set to an instance of an object
VideoSpeaker+PICMIJKCDDD.MoveNext ()
UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress)



2019.04.07 11:54:39 Warning    -  [VRC_TriggerInternal] SpawnVideo (Dynamic Clone 1312513:100003) deferred event Unnamed type OnSpawn because ScreenAnchor to ready

Issues relating to lack of Media Foundation support appears to be tracked here https://github.com/ValveSoftware/Proton/issues/1464 (The issue focused on wmv support, but issues with other video formats are also tracked)

Also, worth noting that the dlls from windows 7 dosn't support all of the MF features required by VRChat, see http://help.vrchat.com/kb/article/21-video-players-arent-working/ (Not sure how many worlds this effects), but is seems proton might not support the newer versions, based on https://github.com/ValveSoftware/Proton/issues/1102#issuecomment-421484508

Really appreciate your insight TheLastRar! Man that’s a shame, so ultimately it comes down to supporting not only Media Foundation but also the latest Media Foundation from Win10.

I have a friend that plays VRChat using windows 7, and most(?) video panels seem work for them, but they have crashed in the "Back to the Future The Ride" map in the past (which says it needs win10).

So the windows 7 version does provide a good amount of support, But yeah, support of the for latest version seems to be required for everything VRChat can do.

Issues relating to lack of Media Foundation support appears to be tracked here #1464 (The issue focused on wmv support, but issues with other video formats are also tracked)

Also, worth noting that the dlls from windows 7 dosn't support all of the MF features required by VRChat, see http://help.vrchat.com/kb/article/21-video-players-arent-working/ (Not sure how many worlds this effects), but is seems proton might not support the newer versions, based on [#1102 (comment)](https://github.com/ValveSoftware/Proton/issues/1102#issuecomment-421484508)

I tried the DLLs from Windows 8.1 originally and they didn't work, so I went back and got the ones from Windows 7, which also didn't appear to work.

I used process explore to see what dlls are loaded by unity to see if any where missed in the workarounds (I used the test scene posted earlier)

These dlls seem Media foundation related, so might be worth looking into (I'm using windows 10, Windows 7 might not have/need all of these)

• MSAudDecMFT.dll
• mfcore.dll
• mferror.dll
• mferror.dll.mui
• mfmp4srcsnk.dll
• mfnetcore.dll
• mfnetsrc.dll
• mfplat.dll
• mfreadwrite.dll
• mfperfhelper.dll
• msacm32.dll
• msmpeg2vdec.dll

Looking further at the test scene, (using a ubuntu VM and wine 4.5)

Adding the following to the mf.reg now has the video player display grey (after 1-2 seconds) instead of white

[HKEY_CLASSES_ROOT\CLSID\{2EEEED04-0908-4cdb-AF8F-AC5B768A34C9}]
@="Drm Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{2EEEED04-0908-4cdb-AF8F-AC5B768A34C9}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{37A61C8B-7F8E-4d08-B12B-248D73E9AB4F}]
@="Secure Http Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{37A61C8B-7F8E-4d08-B12B-248D73E9AB4F}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{44CB442B-9DA9-49df-B3FD-023777B16E50}]
@="Http Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{44CB442B-9DA9-49df-B3FD-023777B16E50}]
@="Http Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{44CB442B-9DA9-49df-B3FD-023777B16E50}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}]
@="File Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{9EC4B4F9-3029-45ad-947B-344DE2A249E2}]
@="Urlmon Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{9EC4B4F9-3029-45ad-947B-344DE2A249E2}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{E9F4EBAB-D97B-463e-A2B1-C54EE3F9414D}]
@="Net Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{E9F4EBAB-D97B-463e-A2B1-C54EE3F9414D}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

The video fails to play further, showing the following error in the console

0050:fixme:urlmon:InternetBindInfo_GetBindString not supported string type 20
0050:fixme:urlmon:ProtocolStream_Seek no cache file, not supported

So it seems that even the windows 7 dlls can run into unimplemented functions

Omg hell yeah!! A grey screen is better than a crash!

_{Sent with GitHawk}

So the crashes when joining maps have been gone for a while now for me.
My game only crashes from vrchat bugs now and somewhat often when a new avatar gets loaded.
Anyone else experiencing this? It feels like my graphics card hangs. The game freezes, and my whole system is EXTREMELY slow, until VRChat, SteamVR and Steam get terminated.
This only happens to me in VR. I have used multiple Nvidia graphics driver versions and use 430 right now, with this happening.

@jug007 It would be interesting to know what avatars cause this. I know that will be hard to track down though. I do know that avatars with high res textures or a lot of large resources cause a hitch still on Windows, so there is a chance it's related to that stress.

If you could collect the Output logs when these crashes happen, they might by chance have an error output in them that would at least point in the right direction.

On Windows they are located here:
C:\Program Files (x86)\Steam\steamapps\common\VRChat

The crashes don't seem to be linked to specific avatars. It seems like the game doesn't "crash" if I have it load one person at a time rather than enabling two people's avatars at once.
Also people changing avatars also doesn't seem to "crash" it. Only enabling avatars of people that are disabled by the safety settings seems to cause this fairly reliably.
Though loading a ton of avatars, because the safety settings allow it also seems to crash the game fairly often.

I think the idea about this being stress related might be somewhat of a thing. Proton seems to amplify already existing bugs in VRChat in some cases. Like VRChat never exiting properly, where as it sometimes exits properly on windows.

Made a thread on the Nvidia forums for the "crashes"/hangs I am experiencing.
https://forums.geforce.com/default/topic/1118701/geforce-drivers/-driver-430-14-system-sometimes-hangs-when-playing-vrchat-with-proton-on-linux-mint-64bit/

Apparently this issue doesn't have much to do with VRChat:
https://devtalk.nvidia.com/default/topic/1051300/linux/inconsistent-but-frequent-freeze-caused-by-steamvr

Updating to 418.52.07 fixed this issue for me.
https://devtalk.nvidia.com/default/topic/1051300/linux/inconsistent-but-frequent-freeze-caused-by-steamvr/post/5342522/#5342522

VRChat avatars with >1 skinned meshes render only the first mesh (the one named "Body" in Unity), and not others

Issue transferred from https://github.com/ValveSoftware/Proton/issues/2764.
@Icekhaos posted on 2019-06-01T20:39:29:

Compatibility Report

• Name of the game with compatibility issues: VRChat
• Steam AppID of the game:438100

System Information

• GPU: RX480
• Driver/LLVM version: Mesa 18.2.8, DRM 3.32.0, LLVM 7.0.0
• Kernel version: 5.2.0-050200rc2-generic
• Link to full system information report as Gist: Gist
• Proton version: 4.2-5

I confirm:

• [Y] that I haven't found an existing compatibility report for this game.
• [Y] that I have checked whether there are updates for my system available.

steam-438100.log

Symptoms

Player models with more than one skinned mesh (confirmed secondhand by an Unity avatar creator) do not render any skinned meshes besides the only one required by the game, that is, the one named "Body".

Here is the list of meshes, the first group (Mishe) is the unoptimized avatar that does not render properly, and the latter one (MisheOptimized) is an optimized avatar that correctly renders.

Here is what Mishe looks like:

Here is what MisheOptimized looks like:

Reproduction

1: Launch VRChat
2: Enter a hub world
3: Wait for an avatar with multiple skinned meshes
4: Compare screenshots

Originally reported by me, thanks for moving.

This happenes on Nvidia if you don't use dxvk (e.g. use just wine instead of proton).

I would definetly take the drivers into scrope, as Vulkan is a fairly new technology and Amd and Nvidia had problems with it in their drivers until just recently (or apparently maybe still).

Actually, if that is cubed shader, you might want to try if the problem occurs with a different shader, as there has been a bug in the AMD graphics drivers in the past where cubed's shader turned invisible (not looking exaclty like these screenshots).

Actually, if that is cubed shader, you might want to try if the problem occurs with a different shader, as there has been a bug in the AMD graphics drivers in the past where cubed's shader turned invisible (not looking exaclty like these screenshots).

I used arktoon shader(That was my unity project, and helped out)
https://gyazo.com/1f798002e30cb0228176b13edd65e317

We originally thought it was the rimlighting or shaders, but he excluded those afaict.

Oh; I have shaders disabled for random people, and those are exhibitng this problem as well. Hope this helps.

I have about 750 hours on VRChat at this point. Other than random graphical corruption issues (which are solved by restarting the game), I haven't noticed any issues like this.

I've got an R9 Fury, and I'm running on Mesa 18.3.4 with Proton 4.2-5 (although I've been playing regularly since Mesa 18.2.x + Proton 3.16 betas).

@Icekhaos Can you try using one of the Mesa PPAs to install a newer version of Mesa (eg 18.3.x or 19.x) and see if that resolves the issue?

Any PPAs you recommend? Does Oibaf's work?

I'd recommend Padoka Stable over Obiaf because Obiaf seems to build git latest mesa instead of stable. Sometimes git latest mesa has bugs that don't make it to a release.

If you have the time, it wouldn't hurt to test both though.

19.0 fixed it. I wonder why that happened though...

19.0 fixed it. I wonder why that happened though...

Likely a bug in Mesa 18.2.x that is fixed in 18.x.3 and newer.

Does anyone know how to get asian characters working?

Does anyone know how to get asian characters working?

I've noticed non-ASCII characters not rendering as well.

I suspect it is a missing font issue because I've heard reports from some of my friends on Windows that they have the same problem.

Cyrillic (Russian) characters are working fine. So there are at least some other fonts that work.

So apparently some of the fonts are "missing":
https://wiki.winehq.org/Font_Replacements
https://bugs.winehq.org/show_bug.cgi?id=13829
https://wiki.winehq.org/Useful_Registry_Keys

According to these resources, wine needs to have font replacements set, for some of the fonts to work.
Proton seems to not have these set. These resources also state the fedora and ubuntu versions of wine, as well as crossover have these replacements in place. So a fairly easy way to test if VRChat is actualy affected by this, would be to run it in wine or crossover and check if japanese characters are showing there.
Apparently you can set these replacements using regedit. To run regedit in proton, just replace its path in the following startup settings: "/mnt/e7b6ce9b-f952-4ee7-9061-34b5f3f5e028/SteamLibrary/steamapps/common/Proton 4.2/proton" waitforexitandrun regedit && echo %command% >/dev/null

I feel like the easiest way to get the right replacements, would be to just copy them from the version of wine that comes from the systems repository.

I've tried to figure out the fonts issue, here's what I learned so far.
VRC uses the fonts BankGothic (nameplates) and Dosis (menus). Which indeed are missing lots of international glyphs. Running notepad with proton in the same environment as the game, you can see this happening.

English: Rome is a beautiful city
Italian: Roma è una bella città
Arabic: روما مدينة جميلة
Chinese (Simplified): 罗马是一座美丽的城市
Chinese (Traditional): 羅馬是一座美麗的城市
Czech: Řím je krásné město
Greek: Ρώμη είναι μια πανέμορφη πόλη
Hebrew: רומא היא עיר יפה
Hindi: रोम एक सुंदर शहर है
German: Rom ist eine schöne Stadt
Japanese: ローマの美しい街です
Korean: 로마는 아름다운 도시입니다
Russian: Рим очень красивый город
Thai: โรมเป็นเมืองที่สวยงาม
Turkish: Roma güzel bir şehir olduğunu
Ukrainian: Рим дуже красиве місто
Vietnamese: Rome là một thành phố xinh đẹp
- by Andrea Denzler for Wine

I found that following the guide on font replacements and the bugreport can resolve the issue in notepad. But the game does not reflect this.

I've tried to link both core fonts (arial, courier, times, etc.) and the fonts used (BankGothic, Dosis) to use TakaoPGothic and DroidSansFallbackFull as fallbacks. Again works fine in notepad to show Japanese text, but no change in the game.

My thinking is that the Unity engine handles fonts differently from regular windows applications. As this https://docs.unity3d.com/Manual/class-Font.html seems to reflect.

For good measure I also tried winetricks corefonts and cjkfonts. So far haven't found a fix.

Re Windows Media Foundation support see #1464

Opened a feature request for the fonts issue.
https://vrchat.canny.io/feature-requests/p/add-font-fallbacks-for-compatiblity
Also the Dosis font is actually available on linux. At least it is in the ubuntu package repository "fonts-dosis".

Does anyone know a way to make Steam not override the youtube-dl.exe with every VRChat update?
Even when root doesn't have rights to modify the file, Steam still overrides it..

Also the Font issue is gone for me. I don't know if it was a Proton update, a VRChat update, or whatever, but I can see japanese names fine now.

It's fixed in Proton 4.11-3. https://github.com/ValveSoftware/Proton/releases/tag/proton-4.11-3

Add missing Chinese, Japanese, and Korean language font.

It looks like though, my method of manually adding it before was possibly incomplete then.

Some world do freeze up when trying to load for me though.
Can you try for example https://www.vrchat.net/home/launch?worldId=wrld_06021428-e14b-4c02-9f57-f5c28f6d6efe

It hangs on a black screen just when loading in the world. Then eventually ubuntu asks me if I want to force kill it.

Hi,

Some world do freeze up when trying to load for me though.
Can you try for example https://www.vrchat.net/home/launch?worldId=wrld_06021428-e14b-4c02-9f57-f5c28f6d6efe

It hangs on a black screen just when loading in the world. Then eventually ubuntu asks me if I want to force kill it.

Does it also hang on an older version of Proton? Or it is a regression of Proton 4.11-3?
Could you test it with an older Proton, such as 4.11-2?
Thanks.

Hey @jzengc I've run through the options available through the steam settings.

• [ ] Proton 3.7-8
• [ ] Proton 3.16-9
• [ ] Proton 4.2-9
• [ ] Proton 4.11-3
• [x] Windows

TL;DR all of them don't work. So it isn't a regression between these.

I did the following:

Pre-populate cache and user login by logging in and attempting to join a cushy instance.

1. Start VRChat (in windowed, desktop mode) and load to the default home world.
2. Open menu and search for "cushy" in the worlds tab. Then join a public instance.
3. Loading screen appears, press "Go" when ready.
4. Now either freezes on black screen or loads into the world.

proton-vrchat-1199-logs.zip

I've attached the VRChat logs of each of these runs, including just the 4 steps (not the cache pre-populating part). For each proton version and windows.
You can find these in:

• Proton: <your-steam-library>/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/AppData/LocalLow/VRChat/VRChat/output_log_<timestamp>.txt
• Windows: C:\Users\<username>\AppData\LocalLow\VRChat\VRChat\output_log_<timestamp>.txt

The logs are not super detailed, but what I found interesting isn't what's there in the proton ones. But what's not there compared to the windows one.

All of the proton logs end at the same point (trimming some whitespace for clarity):

...
2019.09.10 11:57:56 Log - [VRCFlowManagerVRC] Switching active scene:  => megs house
2019.09.10 11:57:56 Log - [VRCFlowManagerVRC] Instantiating VRC_OBJECTS
2019.09.10 11:57:56 Log - [VRCFlowManagerVRC] Hard max is 40

EOF

While the windows version continues like so:

...
2019.09.10 12:07:01 Log - [VRCFlowManagerVRC] Switching active scene:  => megs house
2019.09.10 12:07:01 Log - [VRCFlowManagerVRC] Instantiating VRC_OBJECTS
2019.09.10 12:07:01 Log - [VRCFlowManagerVRC] Hard max is 40
2019.09.10 12:07:02 Log - LoadLevelAsync took 1.531513s
2019.09.10 12:07:02 Log - Loaded asset bundle: megs house
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Room instantiate took 22.35867s
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Spent 0.06311417s initializing VRC Objects and level
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Doing some house-keeping.
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Assigning IDs to scene
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Spent 0.004928589s assigning network IDs.
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Processing scene objects
2019.09.10 12:07:02 Log - [Always] Loading scene's render settings.
2019.09.10 12:07:02 Log - [Always] Creating Scene Dynamic Bone Controller.
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Spent 0.09152603s processing scene objects.
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Fixing materials
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Spent 0.0006790161s fixing materials.
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Finalizing scene
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Spent 0.01531219s finalizing scene.
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Entering world
2019.09.10 12:07:02 Log - [RoomManager] Entering Room: Cushy
2019.09.10 12:07:02 Log - [RoomManager] Joining wrld_06021428-e14b-4c02-9f57-f5c28f6d6efe:82696
2019.09.10 12:07:02 Log - [RoomManager] Joining or Creating Room: Cushy
2019.09.10 12:07:02 Log - [RoomManager] Successfully joined room
2019.09.10 12:07:02 Log - [VRCFlowManagerVRC] Spent 4.959106E-05s entering world.
...

This seems to suggest we're pretty early on in the loading process and it's this LoadLevelAsync function that freezes.

Some world do freeze up when trying to load for me though.
Can you try for example https://www.vrchat.net/home/launch?worldId=wrld_06021428-e14b-4c02-9f57-f5c28f6d6efe

It hangs on a black screen just when loading in the world. Then eventually ubuntu asks me if I want to force kill it.

Have you tried replacing youtube-dl.exe with an empty file? VRChat currently freezes, when a video player gets loaded (like a lot of worlds do). Replacing youtube-dl.exe "fixes" that. Keep in mind that Steam overrides the file on every update; Apparently even if it is read only.

I've not yet @jug007 and I can test later. Bit caught up with other work atm. Perhaps you can test the world I linked and see if the youtube-dl workaround fixes it for you?

@jug007 youtube-dl file was indeed the problem.
Something along these lines let's me load into the world.

#!/usr/bin/env sh
# blank out youtube-dl.exe for VRChat

# Set this to where you've installed VRC.
game_steam_library=${GAME_STEAM_LIBRARY:-"$HOME/.steam/steam"}

ytdl_dir="$game_steam_library/steamapps/common/VRChat/VRChat_Data/StreamingAssets"
mv $ytdl_dir/youtube-dl.exe $ytdl_dir/youtube-dl.exe.bak
echo "" > $ytdl_dir/youtube-dl.exe

I am myself encountering an issue with my mouse. KDE workspaces and some swapping between them can bug out the mouse in a fashion that, when it moves, it will not reset its relative positioning to where it was; this means that, on one frame, it moves, say, 5X and 5Y. If you move the mouse the same amount on the next frame, then, instead of 5:5, it is now 10:10. Move it 25 in the opposite direction, and it becomes -15:-15.

On 4.2, you can reset this by opening and closing the menu. This no longer works in 4.11, but it does go away when the menu is open.

Same mouse issue with Gnome after switching windows in any fashion.
I think when regaining focus VRChat is supposed to "capture" the mouse so it will actually be centred. Moving up or to the sides enough after losing focus once, will move you outside the VRChat window. While normally that should only be possible when you have the menu open.

Hey @jzengc I've run through the options available through the steam settings.

* [ ]  Proton 3.7-8

* [ ]  Proton 3.16-9

* [ ]  Proton 4.2-9

* [ ]  Proton 4.11-3

* [x]  Windows

Thanks for testing! I can reproduce this bug, too.
It should be an issue of Python 3.4 on Wine at first. It can be reproduced by running this .py script on Python 3.4 with Wine:
No, this is another Wine issue.

import ssl

ssl.create_default_context(ssl.Purpose.SERVER_AUTH)

I will take a look at it.

Hi there, I am having an issue on VRChat (my microphone while working with other games, is not listed in settings).

My experience with GitHub is limited and I don't want to risk making a thread if this is a sort of 'unofficial' support page (similarly I don't want to post on this thread and it be off-topic, so I'm sorry if it is).

here is a screenshot of the two options I have for my microphone, neither of which work;

https://imgur.com/a/jCNJFSt

If anyone can point me in the right direction, or even offer some practical advice on how to fix such issue I would be very grateful.

@jzengc

Thanks for testing! I can reproduce this bug, too.
~It should be an issue of Python 3.4 on Wine at first. It can be reproduced by running this .py script on Python 3.4 with Wine:~
No, this is another Wine issue.

The script you ran doesn't look like anything that would be specific to python. Although youtube-dl is built from that. As I doubt python has a custom SSL implementation and probably defers to openssl. Maybe it's an issue with something like obtaining root CA certificates from the emulated environment? Although I'd expect that sort of issue to cause trouble all over the place.

@tunanachos, the screenshot you linked shows the options are both "Pulseaudio".
Pulseaudio in a sense is a very general purpose mixer running on your host machine.

Have you tried configuring pulseaudio to use your mic? Using for example Ubuntu's sound options if you're on Ubuntu. Or a utility like pavucontrol?
Note: pulseaudio is also the only available option for me, in spite of having a couple of different mics. And I too need to set them in some pulseaudio control panel.

On a recent OS reinstall, I'm getting:

Failed to initialize graphics.
Make sure you have DirectX 11 installed, have up to date
drivers for your graphics card and have not disabled
3D acceleration in display settings.
InitializeEngineGraphics failed

I wonder if this is a recent change or me just missing some dependency.

Edit I tried the previous OS again with the same VRChat and proton version, which runs fine. Wonder what the problem is. I've tried having steam reinstall the game and proton without success.

Edit2: Aaand that dependency turned out to be vulkan.

sudo apt install libvulkan1 mesa-vulkan-drivers vulkan-utils

@tunanachos, the screenshot you linked shows the options are both "Pulseaudio".
Pulseaudio in a sense is a very general purpose mixer running on your host machine.

Have you tried configuring pulseaudio to use your mic? Using for example Ubuntu's sound options if you're on Ubuntu. Or a utility like pavucontrol?
Note: pulseaudio is also the only available option for me, in spite of having a couple of different mics. And I too need to set them in some pulseaudio control panel.

Hi there, @Beanow thanks for taking time to help me and reply.

If you look closely they are both 'different' (at least, there are two different options)

While checking PulseAudio I can see my microphone bounce up and down when I talk, so why VRChat isn't picking it up is beyond me (as mentioned, other games don't have this issue; CS:S, CS:GO, TF2 etc)

Is there a path or somewhere the microphone inputs are set for this game? It's hopeless being able to use this without communication lol :-)

Thanks again for your time and reply, hopefully it'll be solved soon.

@tunanachos I have the same two options. The difference is that one of them is "Default", meaning it will use "Windows" default recording device. Which will point to pulseaudio as it's the only device.
Then there's just Pulseaudio, which is to manually select it (regardless of "Windows" recording device settings).

The only additional routing of audio it does is the in-game settings. You can try cranking up your mic volume everywhere and messing with the mute / push-to-talk V button.

I see, thank-you for clarifying that for me.

While I do enjoy having Linux as my OS almost always it goes over my head when trying to understand it's workings so I'm grateful.

I will give it another go, admittedly I've only played it for an hour or two and it would be hilarious if this whole time I wasn't doing something right.

I'll give it a go soon, turn everything up and see if I can't deafen a few people while asking if my microphone is working or not >:-)

@tunanachos to be safe, you can look for the VRChat mic indicator lighting up first :smile:

Just quickly, should it be red or translucent when you're talking? I press V (I think) and it turns red, I try and talk but nobody seems to hear me. (this is going from memory, I wan't to make sure I wasn't muting myself the entire time lol).

When red it's muted. When translucent the mic should be open. When speaking you can see the translucent one get more opaque when there's enough sound for voice activation.

Muted

Open, no voice activation

Open, voice activated

Okay, so I'm really quite sure something weird is going on..

I jumped on and went to a hub? There were a group of people not doing much, I asked them "Can anyone hear me?" several times with the volume on the pavcontrol and in-game on microphone up to 100% and got no answer.

however when they were talking to themselves (and they seemed pleasant enough) they complained "Why can I hear myself??" several times when I was pushing down V to talk at the same time.

I don't know why, how or why again, but I really think for some reason it's picking up and using my output and my input? It's the only thing I can think as to why that would be happening....

Well, so far I don't think it's a problem with Proton + VRChat compatibility. Just a matter of getting your Pulseaudio configuration right.

The other games you mentioned CS:S, CS:GO, TF2 have a native Linux build from what I can tell. So their configuration is probably easier. Unless you're running their windows versions through Proton for some reason.

Perhaps you can test your setup some more, or try running the windows version of Audacity using Wine and/or Proton to get a better idea of what's going on. But to avoid spamming everyone else in this thread, please try to isolate whether the problem is with Proton :]

That's a fair point to make and I'm totally not disagreeing it could be something with me.. It's just I've never had this issue before - in fact I recall playing MW2 and the voice working, I'm sure I've played other non-linux games (either through wine or with Steam+Proton) and not had the same issue.

With that said and at risk of repeating myself I absolutely agree there is something I could be doing wrong.. I'm just lost as to what and how to address the issue.

I am sorry to both you and anyone else suffering email notification spam - didn't even cross my mind until you mentioned it.

With all that said, is there anywhere I could post elsewhere I might be able to get help? As I originally said I don't want to post in the wrong place or waste peoples time, just want to have fun but I'm totally lost on where or how to start :-)

Thanks and sorry again. I won't reply or post again unless it's something more pertinent.

Seems the Open Beta [for Unity 2018] instantly crashes upon startup.

Renders a few frames and then crashes.

Managed to capture the game log and a Proton log.

output_log_8-55-55_PM.txt

steam-438100.log

Not sure if it's a VRC issue [it is the beta, although the beta should be the release... soon], a Proton issue, SteamVR, etc. Seems to explode when the game log is writing SteamVR stuff.

Okay, so I'm really quite sure something weird is going on..

I jumped on and went to a hub? There were a group of people not doing much, I asked them "Can anyone hear me?" several times with the volume on the pavcontrol and in-game on microphone up to 100% and got no answer.

however when they were talking to themselves (and they seemed pleasant enough) they complained "Why can I hear myself??" several times when I was pushing down V to talk at the same time.

I don't know why, how or why again, but I really think for some reason it's picking up and using my output and my input? It's the only thing I can think as to why that would be happening....

There is also a bug in vrchat that makes avatars repeat your microphone input. No idea how they got that happening, but if people say "why can i hear myself" it could be that. Pulseaudio doesn't just use your output as input if you don't tell it to. Or rather it cannot even do that until you enable that.

Just tested the open beta again, and wanted to report that it works now. The game successfully loads into a world.

So there is a new mmd dance map called "MMD DANCE STAGE（PV） 0․3A" that crashes the client when you try to play a promotional video. It doesn't seem to use youtube-dl.exe but just an internal video. Because of this the client still crashes, even with youtube-dl.exe removed.
Normally it writes an error message about Media Foundation missing to the proton log.
I have tried <Workaround removed by moderator>, but that only makes it crash in a different way..

Edit: Just made a bug report. Maybe they will do something eventually ¯_(ツ)_/¯
https://vrchat.canny.io/bug-reports/p/client-closes-with-missing-media-foundation

I also just stumbled across two other issues.
The world "Just moved in" has pens, which seem to work for everyone, but me.
There appears to be a video memory leak present. https://vrchat.canny.io/bug-reports/p/video-memory-leak

Does the vrchat camera not save the images for anyone else?

Does the vrchat camera not save the images for anyone else?

They should be in ~/.local/share/Steam/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/My Pictures/VRChat

@XLPhere I would think that youtube-dl works.
What crashes the client isn't youtube-dl, but trying to play videos. Fortunately almost all videos are accessed through youtube-dl, rather than being integrated into the world.

@jug007 well i have a world, which crashes after a few seconds - renaming youtube-dl.exe prevents the crashing, but then there is no music playing in the background though, like it does on windows -so it looks like an issue with youtube-dl, or am i getting something wrong there?
(EDIT: I just read a bit more in the thread and i saw that it seems to be missing functionality of the windows media foundation on wine? Is there already a ticket open on wine for those features, so we might get support soon?)

@XLPhere there is plenty of tickets for that. Someone at codeweavers is currently doing some work on that as far as I know, but I don't think it will be anywhere close to finished soon, as this has been an issue for years.

I can confirm that I have the same issue with avatars failing to load in certain cases, and issues with the video player; but despite not doing any workarounds for it I have no video player related crashes or lighting bugs in any world.

Haven't noticed broken lighting (Nvidia 440.82).
Videoplayers are known to not work, but like dotWAVE the game has not been crashing for me anymore.
Avatars failing to load and general slow loading has been a thing for me since the UDON update.
The avatar thing doesn't happen for me on Windows, but is definetly tied to the update.

I may have potentially found a solution for the errored-out models.

For one, the "zero-modification fix" is just re-join the world again. If you go to the worlds tab, you can find the instance you're in, and hit "Go." Every time I've done that, the avatars that failed to load the first time loaded successfully. That's, at the very least, a temporary, if inconvenient, fix. Once an avatar has been downloaded and stored in the cache, it loads correctly 100% of the time in my experience.

Recently, while debugging some other stuff, I did the following in my VRChat Proton environment:

https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-606068829 (used Winetricks to install vcrun2015 and vcrun2017)
followed by
https://github.com/ValveSoftware/Proton/issues/3706#issuecomment-606307808 (extracting some dlls from a vc_redist runtime into the Windows directory)

Since then, I don't think I've seen any error avatars that failed to load-- and, generally speaking, things seemed to be running all-around better. I haven't had issues with worlds hanging for 5-30 seconds when I try to load in before they would actually download, haven't had avatars hanging on load, haven't had new avatars erroring out when trying to download....

Since those issues don't occur 100% of the time anyways, it could just be I've been lucky and haven't visited enough/cbusy enough worlds yet, or possibly some other changes I made at the same time did it.

Not entirely sure why that fixes it, but I do know that VRChat ships some runtime libraries with it, and I believe using winetricks vcrun[2015,2017] applies some DLL overrides, and that may be what fixes it.

I tried the solution above by running the following commands.
protontricks 438100 vcrun2015
protontricks 438100 --force vcrun2017
cd /home/$USER/.steam/steam/steamapps/compatdata/438100/pfx/drive_c/windows/system32/
wget "https://aka.ms/vs/16/release/vc_redist.x64.exe"
cabextract vc_redist.x64.exe
cabextract a10

Seems to greatly reduce the rate in which avatars spawn as errors (And some avatars that never worked before even after reloading the world... do now), but doesn't completely solve it.
Reloading the current world seems to most of the time successfully load the rest of the avatars though breaks can still happen when people switch avatars.

Lighting bug still present in some worlds for me.

After further playtime, I can confirm the same results. Error avatars vastly reduced, but still present occasionally.

Still, it makes the game much more playable, I can load a world of 30+ avatars now and usually they all load successfully. I went from like 1 in 3 avatars erroring out to probably closer to 1 in 30 or 1 in 60.

As for the lighting bug, are we talking about the one that looks like this?

Whatever it is, it's something related to how the game implements bloom. It only appears in worlds that use bloom, and if you can turn bloom off in the world, it fixes the problem. I'm not sure what causes it, and it hasn't always been an issue, but it has been an issue for a little while. I think I've seen it all the way back to maybe October or November, but I don't remember seeing it too much before that [although I may just have not run into worlds that caused it].

I've never seen this bug. Are you on AMD or Nvidia?

I have seen this lighting bug a lot too (just a few days ago too), playing on AMD. Haven't tried turning off bloom in the worlds yet but Japan Shrine was also the first map where I saw this issue occur. In VR view it's flickering a lot and pretty bad to look at.

Otherwise the only issues I had was error avatars and no video playback as well, as reported by others already. Though I never had problems with worlds crashing because of youtube-dl. Youtube-dl always worked flawlessly for me, (checked using a small wrapper logging invocation) it was just playing back which was the issue.

The errored models might actually be a windows problem being made worse through proton, Recently I have found that all the models in the first large public world I join load fine, but then get a 30% error rate in every world after. I found some (I assume windows users) posting about the same issue.
https://steamcommunity.com/app/438100/discussions/5/1643171537287950325/
https://www.reddit.com/r/VRchat/comments/bujbdj/help_metal_error_robots_as_avatars/
https://vrchat.canny.io/bug-reports/p/some-avatars-just-become-error-avatars
Can also confirm that the VR view seems to be flickering alot now, though I think the same is happening in the normal SteamVR home world so it might be steamvr related.

The lighting bug is definitely not a DXVK issue, tried using dxvk on the same hardware while duel booting windows (Dropping the 32bit dxvk ddl's into the vrchat exe folder) and the lighting bugs did not persist (Also seemed to make the game in general run smoother).
Maybe its a problem with amdgpu's implementation of vulkan?

The lighting bug is definately a mesa/AMD issue, it isn't present on Nvidia.
Are you using anything like ACO or other mesa patches?

In my case, I'm running all stock Debian Testing packages. The only change I've made is I grabbed a more recent copy of linux-firmware from upstream, since Debian's package is coming on a year out-of-date.

I just tested with RADV_PERFTEST=aco and the "Summer Solitude" map, and it still has the exact same issue.

I've found both shaders on avatars and objects in worlds can trigger it. I can provide a link to one of the avatar shaders that causes the issue if it'll help.

I tried the solution above by running the following commands.
protontricks 438100 vcrun2015
protontricks 438100 --force vcrun2017
cd /home/$USER/.steam/steam/steamapps/compatdata/438100/pfx/drive_c/windows/system32/
wget "https://aka.ms/vs/16/release/vc_redist.x64.exe"
cabextract vc_redist.x64.exe
cabextract a10

Are there any extra steps to using fix? When I the vcrun2015 and --force vcrun2017 an installer appears, but when I click "install" I get error "0x80070666 Another version is installed".

I also tried deleting the prefix, running the game once and then running those commands again, but I still get the same error.

I thought if I interrupt the first time setup it might prevent Steam from automatically installing "Microsoft VC redist package". If I close the progress window while it's running first time setup and try protontricks again, instead I get error:

/home/theo/.cache/protontricks/proton/Proton 5.0/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message ""

Any thoughts?

I am using mesa-git and the aco compiler, though if I remember correctly I had the same lighting problem back with standard mesa no aco...
Also the commands
protontricks 438100 vcrun2015
protontricks 438100 --force vcrun2017
Worked back in the proton-08 beta but not in the release, now does give the error "Another version is installed" though when I first run vrchat with the released proton 5.8 it said it was installing vcrun... so maybe those dependencies are automatically installed now.

it said it was installing vcrun... so maybe those dependencies are automatically installed now.

Could be, although the avatars problem persists. Even if I run the wget and cabextract commands alone I get a lot of errored avatars.

To add to this issue, I also get the lighting problem being discussed. With a 5700XT on kernel 5.7.5, mesa 20.1.1-2 and aco enabled.

I believe VRC does include versions of VCRUN.

The protontricks/winetricks commands still set some DLL Overrides that aren't set by default.

Whatever the graphics/bloom bug is, Half-Life: Alyx - Final Hours seems to reproduce it on the Y and X in the title screen [where there's the "BEGIN" button].

In certain maps I get strange looking colours. Attached screenshot:

The world I took this screenshot in was called I think Meroom. I also had the problem in Murder 2.

Installed versions:
local/mesa 20.1.4-1
local/linux-zen 5.7.10.zen1-1

Proton 5.0-9.

using the ACO compiler.

Also to add, the latest VRChat release has a fix that disabled video playback in worlds for Proton users: https://docs.vrchat.com/docs/latest-release so renaming youtube-dl should not be necessary anymore.

The latest vrchat fix seems to be made with outdated information, ever since we got partial windows-mf support in proton the video players didn't seem to cause instability/crashing (renaming youtube-dl was old news before this update). I do worry that this will "fix" will cause problems after we get full windows-mf support with evr biult into proton. Can confirm that avatars still sometimes fail to load in after the latest update. I do appreciate that the devs are attempting to give us linux users some support tho, hopefully this means a linux port or proper proton support is on its way.

the video players didn't seem to cause instability/crashing

IIRC, a while ago, VRChat pushed an update that was supposed to address crashing on platforms without proper Media Foundation support.
The crash also effected some versions of Windows 10 and Windows 7 [specifically, I believe it was the N versions].

That seemed to fix it for the most part, although there was still occasionally crashes until the latest update. The latest update seems to have been made with the thought being "it doesn't work anyways-- just turn the entire system off for now." I'm assuming that it's trivial to turn it back on at a later date if Proton gets Media Foundation support that is functional enough to make VRC work properly.

linux port

The way they worded that update gives me hope.

We don't officially support Linux as a platform just yet, but we hope this will hold you over 🐧

The way they worded that update gives me hope.

It would be so great if it was native. I don't have much hope because there was a canny post a while ago that Tupper made suggesting they would one day try to switch to Vulkan. Eventually he closed it because it was impractical.

https://vrchat.canny.io/feature-requests/p/vulkan-support

Using Vulkan would offer very few benefits for a huge amount of work, including (but not limited to) the requirement of re-uploading every single bit of content that has ever existed on VRChat.

I'm guessing for similar reasons it would also make switching to opengl impractical so being forced to stay with directx means never any native port.

I mean, a Linux port bundled with dxvk would be fine and easy to do. I run the game on my windows duel boot using dxvk, purely out of spite for DirectX

The latest vrchat fix seems to be made with outdated information, ever since we got partial windows-mf support in proton the video players didn't seem to cause instability/crashing (renaming youtube-dl was old news before this update). I do worry that this will "fix" will cause problems after we get full windows-mf support with evr biult into proton. Can confirm that avatars still sometimes fail to load in after the latest update. I do appreciate that the devs are attempting to give us linux users some support tho, hopefully this means a linux port or proper proton support is on its way.

I based disabling the Stream Player around recent reports from Linux users in the community and confirming by directly testing VRChat in Proton itself in Linux (I installed Pop OS onto a spare ssd specifically for the purpose). My testing actually shows that Youtube-DL operates properly through Proton, successfully returning the URL needed to play a video, the video players themselves are what fails. The Unity Video player fails gracefully, simply not playing the video. Meanwhile, the stream player (based on Unity plugin AVPro) crashes VRChat due to the failure, thus I opted to add a check that disables it when running through Proton. This effectively makes it easy for me to know when I can re-enable it, as when Windows MF starts working in Proton, the Unity Player will start working, and thus I'll know to test if the stream player also started working.

I have looked far into the youtube-dl issue; running it with the same Proton context as VRChat gives me an error, which I presume is the one stopping VRChat; I'd have to re-do the entire thing to actually figure out what it is. A more proper method is probably to not crash when it is encountered (ie check for the youtube-dl console output).

On the other hand, if one were to rebuild youtube-dl somehow (i tried to do this but could not for the life of me figure out how) it could be made to work without requiring MF, and it would also completely bypass the issue you were having on a few W7 machines.

There is some chatter on youtube-dl's Github about Python 3 wrappers, and if you wanna go the distance, maybe packing the executable in-house would help.

That, or figure out how to tell the .exe in Proton to call native youtube-dl.

I, frankly, have no idea what you are talking about. Youtube-DL does not utilize Windows Media Foundation, as it does not play videos, it merely resolves the true URL of the video and downloads it. The download functionality is not even used in VRChat. VRChat simply passes the result URL to either the Unity Video Player or the AVPro Video Player. Again, in my testing, this operation is performed without a hitch: a result URL is generated and passed back to VRChat, with the VRChat debug logs showing the result. Errors show up at the point that the Unity Video Player or the AVPro Video Player attempt to use the URL to play a video, with AVPro generating a crashing exception that I ultimately was unable to try-catch.

Also, VRChat is designed around the fact that Youtube-DL can be unreliable. If Youtube-DL has a problem, Youtube-DL should crash, and the video players will not be get a url, which they have a case programmed for that simply skips even initializing in the first place. Thus, if Youtube-DL was crashing, VRChat would not. This is why deleting Youtube-DL would appear to stop the crashes on Linux: its absence results in no url, which results in the video players never initializing in the first place.

@Icekhaos Youtube-DL is definitely not the issue, I made a small wrapper which I had running instead of the bundled Youtube-DL to see what the input and output was, there were no issues there at all and it was functionally working fine. I also tried injecting different options to download different encodings / video sizes which didn't change anything. The only thing I noticed was that Youtube-DL wasn't called with youtube-dl.exe as argv[0], but youtube-dl doesn't seem to care about that. I also manually built youtube-dl as exe with a newer python 3.7 version, which also did not change anything.

The only problem there is is the video playback. (which is probably MF related) Though for myself I had never actually the game crash, I suppose it's just some rare worlds which use that other video player that crashes the game which MehStrongBadMeh mentioned. When I played I just had the video never load.

Has anyone tried the video player with GE proton? it has a couple of MF patches which might help

No dice, from my testing.

I did test a couple months ago and it didn't work, however that was only in desktop as for some reason I can't seem to launch any VR game in GE proton, game just closes straight after launch and steam says its "Validating".

In relation to the bloom/lighting bug, DXVK 1.7.2's changelog notes:

Added workarounds for rendering issues on AMD drivers in some Unity Engine games.

I wonder if this fixes the bug?

Doesn't seem to have made a difference sadly.

Incidentally I'm running with:

~/.local/share/Steam/steamapps/common/Proton\ 4.2/proton

not 5.0 as it seems to crash it.

This issue sounds familiar.

Can someone try with d3d11.enableRtOutputNanFixup = True in dxvk.conf ?

Tried dxvk.conf in the installation directory with d3d11.enableRtOutputNanFixup = True

Can confirm it fixes the bright light issue in worlds with bloom. Thanks.

It hasn't helped with the weird colours issue.

Just confirmed that d3d11.enableRtOutputNanFixup = True in dxvk.conf, placed alongside the VRChat executable, does seem to fix the bloom bug.

Tested with Proton 5.13-2.
Mesa info:
Device: AMD Radeon RX 5700 XT (NAVI10, DRM 3.39.0, 5.9.0-1-amd64, LLVM 11.0.0) (0x731f)
Version: 20.2.2

Also seems that the broken colors in Midnight Rooftop are fixed, but that could be from upgrading my Mesa, upgrading Proton, or the nanfix line.

Hi There,

I'd like to file the following report/issue for this game.

System Information

• CPU: AMD Ryzen 9 5950X 16-Core
• GPU: Radeon RX 580 Series
• Driver/LLVM version: Mesa 20.2.2 - Kisak-mesa PPA
• Kernel version: 5.9.8-xanmod1
• Proton version: 5.13-2
• OS: Ubuntu 20.04.1 LTS

2020.11.17 04:46:56 Error      -  Error fetching favorite worlds: Response was null.
handshake_failure(40)


2020.11.17 04:46:56 Error      -  [Always] The response was null. State: Error
Exception: BestHTTP.SecureProtocol.Org.BouncyCastle.Crypto.Tls.TlsFatalAlert: handshake_failure(40)
  at BestHTTP.SecureProtocol.Org.BouncyCastle.Crypto.Tls.TlsProtocol.SafeReadRecord () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.SecureProtocol.Org.BouncyCastle.Crypto.Tls.TlsProtocol.BlockForHandshake () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.Connect () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.ThreadFunc () [0x00000] in <00000000000000000000000000000000>:0 
  at System.Console+InternalCancelHandler.Invoke () [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0 
Exception: BestHTTP.SecureProtocol.Org.BouncyCastle.Crypto.Tls.TlsFatalAlert: handshake_failure(40)
  at BestHTTP.SecureProtocol.Org.BouncyCastle.Crypto.Tls.TlsProtocol.SafeReadRecord () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.SecureProtocol.Org.BouncyCastle.Crypto.Tls.TlsProtocol.BlockForHandshake () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.Connect () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.ThreadFunc () [0x00000] in <00000000000000000000000000000000>:0 
  at System.Console+InternalCancelHandler.Invoke () [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0  
Network Reachability: Reachable via Local Area Network.

I'm unclear as to what's happening here. To reproduce, simply log in as normal, wonder around or stay where you are for a while and eventually the websocket's will start closing. The signs to look out for is the menu no longer refreshing worlds, social, etc and no longer being able to jump worlds. You'll also appear as offline in-game for some.

As far as I know, my system is fully updated as I've recently ran sudo apt update; sudo apt upgrade while writing this post. Any help would be greatly appreciated.

I think I've seen that offline issue happen for Windows users as well.

Recently, Lipsync stopped working for me. It seems to be an error loading the OVRLipSync.dll, and the game log reports:

Plugins: Failed to load 'Z:/opt/steamapps/steamapps/common/VRChat/VRChat_Data/Plugins/OVRLipSync.dll' with error 'No access to memory location.'

Checking the Proton Log [PROTON_LOG=1], it seems to be loading every DLL correctly. It does seem to get hung up on an exception, code c0000005,

4295.203:00c4:00c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\MSVCP140.dll" at 00000000511F0000: native
4295.204:00c4:00c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\dbghelp.dll" at 0000000066200000: builtin
4295.204:00c4:00c8:trace:loaddll:build_module Loaded L"Z:\\opt\\steamapps\\steamapps\\common\\VRChat\\VRChat_Data\\Plugins\\OVRLipSync.dll" at 000000004F560000: native
4295.204:00c4:00c8:trace:seh:dispatch_exception code=c0000005 flags=0 addr=000000007BC314B4 ip=7bc314b4 tid=00c8
4295.204:00c4:00c8:trace:seh:dispatch_exception  info[0]=0000000000000000
4295.204:00c4:00c8:trace:seh:dispatch_exception  info[1]=0000000000000000
4295.204:00c4:00c8:trace:seh:dispatch_exception  rax=0000000000000000 rbx=00000000c0000135 rcx=000000000021da20 rdx=000000000021e6b0
4295.204:00c4:00c8:trace:seh:dispatch_exception  rsi=000000001af605b8 rdi=0000000000000800 rbp=000000000021ddf8 rsp=000000000021d9e0
4295.204:00c4:00c8:trace:seh:dispatch_exception   r8=000000000021ddf8  r9=000000000021de40 r10=0000000000000000 r11=0000000000000000
4295.204:00c4:00c8:trace:seh:dispatch_exception  r12=00000000187261c0 r13=000000000021de10 r14=000000000021de20 r15=000000000021ddf8

I've tried re-installing the game, as well as completely deleting and re-creating the Wine prefix, and it didn't help. The game was previously working fine on Proton 5.13-2.

I did notice, at one point while playing, lip-sync was working for me, but broken for other people, irrespective of their avatars. After the next launch of the game, it just won't work at all.

I'm having the same issue re: lipsync, with the latest version.

I've noticed one or two avatars seem to do okay, but I think they're just using jawflap animations.

I'm having the same issue re: lipsync, with the latest version.

I've noticed one or two avatars seem to do okay, but I think they're just using jawflap animations.

If anyone else runs into this problem, the issue is OVRLipSync.dll

Head to
steamapps/common/VRChat/VRChat_Data/Plugins/

and replace OVRLipSync.dll with the one found here:

https://github.com/peabnuts123/unity-oculus-leapmotion-driving/tree/master/Assets/Plugins/Oculus/LipSync/Plugins/Win64

Start up vrchat and everything should be working!

Thanks for the workaround! The size difference is pretty enormous:

That caught my eye as well.

@ComputerMaster1st I had the same issue (at least, I think the same?) after 20 minutes or so of gameplay: avatars would stop loading, trying to hop worlds would despawn everyone else but not load me in, etc. Disabling IPv6 fixed it, at least so far (for me anyway).

@ComputerMaster1st I had the same issue (at least, I think the same?) after 20 minutes or so of gameplay: avatars would stop loading, trying to hop worlds would despawn everyone else but not load me in, etc. Disabling IPv6 fixed it, at least so far (for me anyway).

alas, this only partially solved my issues

@ComputerMaster1st I had the same issue (at least, I think the same?) after 20 minutes or so of gameplay: avatars would stop loading, trying to hop worlds would despawn everyone else but not load me in, etc. Disabling IPv6 fixed it, at least so far (for me anyway).

alas, this only partially solved my issues

What else are you seeing?

Edit: Disabled ipv6 on both of my vr rigs. The avatar despawn issue still exists on both.

What else are you seeing?

Hi There,

From everything I've been seeing so far and what I'm aware of, avatars do indeed stop loading and sometimes when jumping to a different world, you're stuck in the "disconnecting" phase. Meaning, you're stuck in the world you want to leave but everyone has disappeared and you have no controls. To make avatars load, you'd have to jump into the social tab and wait for it to refresh. That seems to be a temp. fix to get avatars loading again. However, it has to be done like every few minutes.

Now, as for the networking side, that's a VRChat issue and not really proton's issue (except for the TLS Fatal Error: Handshake error (40), I'm not sure if it's because linux is more strict on security now). What I've heard is the sockets are borked on their side which is causing overseas players to constantly disconnect and reconnect every 5-10 minutes. Sometimes they might not reconnect at all and they won't know about it until they try something that involves contacting their API over websockets.

It sounds like they've got a "keep-alive" parameter set too low or something. I have no clue. It'll probably be some time till they fix this.

I've looked a bit into the OVRLipSync.dll issue and it turned out that it fails to initialize due to GetMaximumProcessorGroupCountnot being implemented in Proton. After applying the related patch from wine-staging to Proton 5.13.2, it started working again.

@Icekhaos Youtube-DL is definitely not the issue, I made a small wrapper which I had running instead of the bundled Youtube-DL to see what the input and output was, there were no issues there at all and it was functionally working fine. I also tried injecting different options to download different encodings / video sizes which didn't change anything. The only thing I noticed was that Youtube-DL wasn't called with youtube-dl.exe as argv[0], but youtube-dl doesn't seem to care about that. I also manually built youtube-dl as exe with a newer python 3.7 version, which also did not change anything.

The only problem there is is the video playback. (which is probably MF related) Though for myself I had never actually the game crash, I suppose it's just some rare worlds which use that other video player that crashes the game which MehStrongBadMeh mentioned. When I played I just had the video never load.

Thanks for going through all the trouble! I'm curious, were you able to confirm that "injecting different options" produced the expected encoding? I tried doing the same, but changes to the url didn't produce the expected outcomes.

I don't have the time nor programming expertise to dive in, unfortunately, but I have a theory the unity player is choking on the encoding of the video it's receiving from youtube.

Was going through logs trying to debug other issues and came across the failure point for playing video, thought I'd post it here to get more eyes. Youtube-dl seems to be doing it's job correctly as far as I can tell, but SyncVideoPlayer is choking.

[...]

Thanks for going through all the trouble! I'm curious, were you able to confirm that "injecting different options" produced the expected encoding? I tried doing the same, but changes to the url didn't produce the expected outcomes.

[...]

@earldbjr Check --list-formats on youtube-dl, not all videos have the same available formats though and on youtube you will probably only get one or two available video formats.

If you can get some particular video encoding to work inside VRChat by maybe replacing the video output completely to some local test file or something running on localhost, it would probably be possible to transcode streams with ffmpeg / gstreamer / etc. on the fly to something working, with some additional introduced delay. I wouldn't bet on it working, but I read that other games, especially with Proton GE releases, could read some codecs.

From everything I've been seeing so far and what I'm aware of, avatars do indeed stop loading and sometimes when jumping to a different world, you're stuck in the "disconnecting" phase. Meaning, you're stuck in the world you want to leave but everyone has disappeared and you have no controls. To make avatars load, you'd have to jump into the social tab and wait for it to refresh. That seems to be a temp. fix to get avatars loading again. However, it has to be done like every few minutes.

Seems to be the same issue I've been having. Bizarrely, it seems to be pretty dependent on my IO (when vrchat is run with gamemode, it gets worse, but the situation gets overall better with the deadline scheduler). Maybe it kicks in with some deadlock internally?

In any case, I haven't seen any friends having the same issue but I've heard similar issues referenced online for windows users, it just seems to be more of a problem here.

2020.12.13 22:42:28 Log        -  Websockets API lost connection: Socket closed
2020.12.13 22:42:28 Log        -  Websockets API lost connection: Websocket exploded! An error has occurred in closing the connection. : WebSocketSharp.ErrorEventArgs

Seeing a lot of these, not sure if it's significant.

Similarly:

2020.12.11 19:45:50 Error      -  Error fetching favorite avatar groups: Response was null.
Connection timed out!


2020.12.11 19:45:50 Error      -  [Always] The response was null. State: ConnectionTimedOut
Exception: System.TimeoutException: Connection timed out!
  at BestHTTP.PlatformSupport.TcpClient.General.TcpClient.Connect (System.Net.IPEndPoint remoteEP) [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.PlatformSupport.TcpClient.General.TcpClient.Connect (System.Net.IPAddress[] ipAddresses, System.Int32 port) [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.PlatformSupport.TcpClient.General.TcpClient.Connect (System.String hostname, System.Int32 port) [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.Connect () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.ThreadFunc () [0x00000] in <00000000000000000000000000000000>:0 
  at OVR.OpenVR.IVRCompositor+_CompositorBringToFront.Invoke () [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0 
Exception: System.TimeoutException: Connection timed out!
  at BestHTTP.PlatformSupport.TcpClient.General.TcpClient.Connect (System.Net.IPEndPoint remoteEP) [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.PlatformSupport.TcpClient.General.TcpClient.Connect (System.Net.IPAddress[] ipAddresses, System.Int32 port) [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.PlatformSupport.TcpClient.General.TcpClient.Connect (System.String hostname, System.Int32 port) [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.Connect () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPConnection.ThreadFunc () [0x00000] in <00000000000000000000000000000000>:0 
  at OVR.OpenVR.IVRCompositor+_CompositorBringToFront.Invoke () [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0  
Network Reachability: Reachable via Local Area Network.


2020.12.11 19:45:50 Log        -  [Always] Could not fetch avatars with error - Response was null.
Connection timed out!


2020.12.11 19:45:50 Warning    -  Failed to fetch Mine avatars - Response was null.
Connection timed out!

Also, perhaps someone else can make use of this, I threw together a script to at least sorta let you see media, just by launching whatever's shows up as not playing in the logs. Requires vlc and python3-vlc.

#!/usr/bin/env python3
import time
import os
import vlc
import subprocess
import sys
from pathlib import Path


def follow(thefile):
    '''generator function that yields new lines in a file
    '''
    # seek the end of the file
    thefile.seek(0, os.SEEK_END)

    # start infinite loop
    count = 0
    while True:
        # read last line of file
        line = thefile.readline()        # sleep if file hasn't been updated
        if not line:
            count += 1
            time.sleep(0.1)
            if count >= 50:
                count = 0
                yield ""
            continue

        yield line

if __name__ == '__main__':
    instance = vlc.Instance()
    player = instance.media_player_new()

    vrchat = None
    if len(sys.argv) > 1:
        print("Launching: {}".format(" ".join(sys.argv)))
        vrchat = subprocess.Popen(sys.argv[1:])
        # Wait for VRChat
        print("Waiting for VRChat to launch...")
        time.sleep(10)

    print("Looking over logs")
    files = sorted(Path("/home/USER/.steam/steam/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/AppData/LocalLow/VRChat/VRChat").iterdir(), key=os.path.getmtime, reverse=True)
    logfilepath = next(fi for fi in files if "output_log_" in fi.name)
    print("Following a file: {}".format(logfilepath.name))
    logfile = open(logfilepath.resolve(), "r")
    loglines = follow(logfile)    # iterate over the generator

    for line in loglines:
        #print(line)
        if vrchat is not None and vrchat.poll() is not None:
            quit()
        if 'Finished entering world.' in line and player.is_playing():
            print("Switching worlds, stopping player")
            player.stop()
        if 'WindowsVideoMedia error' in line:
            if player.is_playing():
                player.stop()
            url = line[line.index("while reading ") + len("while reading "):].strip()
            print("Found media, launching: vlc {}".format(url))
            media = instance.media_new(url)
            player.set_media(media)
            player.play()

Doesn't seem to work when run like script.py %command% as I'd intended, but you can launch it independently.
Make sure to run it after VRChat is already running.

https://github.com/doitsujin/dxvk/pull/1872 this should fix the bloom issue.

I have run into the weird colors issue that someone else was having. This time on the loading scren, and after no visible changes.
RX480, Kubuntu 20.10, stock drivers (Mesa 20.2.6), kernel 5.9.6.

On the latest Proton, the video player seems to be starting to be functional on some worlds.

The screen at least lights up grey in Room of the Rain, but the video still fails to play.

On the latest Proton, the video player seems to be starting to be functional on some worlds.

The screen at least lights up grey in Room of the Rain, but the video still fails to play.

First half of your post got me excited... then the second half lol.
Are all screens behaving differently?

Isn't the video player still disabled for Proton users in the client anyway? I don't think it's possible to test it out until the restriction gets removed by the devs.

https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-667321515

https://docs.vrchat.com/docs/vrchat-202031#changes

From the way the dev worded it, both the video and stream players crash due to a half implemented windows media foundation in wine The video player is still enabled and crashes gracefully, its just the stream player that is disabled because it wasn't crashing gracefully / causing all of vrchat to crash, And once the video players work we should let the dev know so he can try enabling the stream players. For now i think we just have to wait for more complete windows mf support in upstream wine.

Hey @kisak-valve,

d3d11.enableRtOutputNanFixup has been enabled by default in DXVK 1.8 (https://github.com/doitsujin/dxvk/commit/1478011822435e5f52addebf4e1c0b6e4bc6c6bc) and should be included in a future Proton release. No further action is required on the Mesa front. The AMD RADV / Mesa drivers labels can most likely be removed or can once 1.8 is available in Proton. I leave it at your discretion.

Thanks.

Further update:

I tested with Proton-GE-6.1 and Proton-GE-6.4, they did not fix the video player. Out-of-the-box, the most I'd get was a "Video player error"

I tested with Proton 5.13, and used <Workaround removed by moderator>. I didn't get "Video Player Error" anymore, but I still got "Failed to load video." Maybe that's due to the video player being forcefully disabled on Proton unconditionally? I don't know how you'd bypass that, though.

I also tried a different world or two, and tried one that said it supported the "New VRC video player" and the "Old VRC video player"-- neither worked. The "new" player was solid white, the old player was solid black.

I also upgraded youtube-dl to the latest exe, and confirmed that the video player still did not work; however youtube-dl definitely worked with the URL I provided it when run from cmd within the Proton environment.

Replying to https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-804540318

With the Dev saying "Meanwhile, the stream player (based on Unity plugin AVPro) crashes VRChat due to the failure, thus I opted to add a check that disables it when running through Proton. This effectively makes it easy for me to know when I can re-enable it, as when Windows MF starts working in Proton, the Unity Player will start working, and thus I'll know to test if the stream player also started working." essentially, the video player is still enabled as it crashes properly, where as the AVPro based stream player causes the entire game to crash.... so its only live streams disabled on proton, When Proton completes its Windows MF implementation the videos should start working. We can then ask for the dev to test the stream player.

Hello @Goofybud16, the workaround you mentioned is legally problematic and has been removed.

Oh, Sorry! I didn't realize that was the case; I'll keep that in mind going forwards.

@MehStrongBadMeh
Stream player disabled in the short run was a good choice but now that various solutions are becoming available as Proton develops will we be receiving a method to toggle the function back on manually in the upcoming 2019 LTS update?

@SpookySkeletons I haven't heard any methods yet of making Windows MF work. Not clear why I am re-enabling the Stream Player when the Unity Player still doesn't work.

@MehStrongBadMeh Was hoping there would be some use in giving the user the option (off by default) to enable the stream player so we can experiment with other options than mainline proton releases until the official work is done.

There's a world called "Pool parlor | 8 ball pool" It has a video player that works on quest, given that quest users probably don't have an implementation of windows mf, Maybe this world has a video player with a different backend and might work on Linux too (Assuming the desktop version uses the same backend as the quest version). I don't currently have a Linux machine set up to test it though.

The VRChat Unity player and Stream player both work on Quest (though youtube-dl is unavailable). This is because they both utilize the Android MediaCodec API. The backend utilized by the video players per platform is determined by Unity, VRChat worlds cannot change that.

I haven't been able to launch VRChat in VR mode with proton newer than 5.13.

Launching in non-VR mode works with latest proton experimental, but VR mode crashes immediately after launch (after game window appears)

steam-438100.log.gz

https://gist.github.com/yshui/0d628de7ba87acb024f7379325bf0685

trying to launch the game in via steam makes it crash instantly at the beginning there really should be a native linux client as it should be possible

@sparky4 @yshui Is it still crashing right after launch for you with 6.3-6c or the newest experimental (currently experimental-6.3-20210825)? Also, what SteamVR version are you using?

I just learnt from https://github.com/ValveSoftware/Proton/issues/3408#issuecomment-910436626, that steamvr 1.14 doesn't work with proton 6.3. And indeed VRChat started to work after I stopped using steamvr [linux_1.14].

@sparky4 Maybe you are using 1.14 as well?

I tested VRChat in desktop mode using Proton version 6.3-6. For me at least, the crash that (if I recall correctly) I used to get on application start when running a Proton version above 5.13-6 does not occur; normal VRChat gameplay was possible using version 6.3-6. I'm guessing the "Need Retest" label was applied because a fix that could fix the crash regression was applied? If so, that fix seems to have worked (though additional confirmation from others would be useful).

With that said, I wasn't able to get any in-world video players to work as expected (namely, to play any videos), so it appears that the issue relating to youtube-dl might still be present.

As of the latest update, the game seems to be continuously crashing. Not sure why.

Tried re-installing the game, restarting PC, re-applying the LipSync DLL fix from above.

It works for a few moments, then crashes.

Doing a little bit of debugging and system observation, it seems like even just sitting at the "Go" screen, VRAM usage increases continuously.

When the game finally crashes, the Proton log says

A crash has been intercepted by the crash handler. For call stack and other details, see the latest crash report generated in:
 * C:/users/steamuser/Temp/VRChat/VRChat/Crashes
1673.391:012c:0238:err:virtual:try_map_free_area mmap() error Cannot allocate memory, range 0x7e470000-0x7e471000, unix_prot 0x1.
1673.391:012c:0238:err:virtual:alloc_area_in_reserved_or_between_callback Could not map in reserved area.
1673.391:012c:0238:trace:seh:handle_syscall_fault code=c00000fd flags=0 addr=0x7f6eca701ee8 ip=7f6eca701ee8 tid=0238
1673.391:012c:0238:trace:seh:handle_syscall_fault  info[0]=0000000000000001
1673.391:012c:0238:trace:seh:handle_syscall_fault  info[1]=0000000125af1b70
1673.391:012c:0238:trace:seh:handle_syscall_fault  rax=0000000125af1b90 rbx=00007f6eca8545c0 rcx=0000000000000000 rdx=0000000125af41c0
1673.391:012c:0238:trace:seh:handle_syscall_fault  rsi=00007f6eca821a53 rdi=0000000125af1a90 rbp=0000000125af4120 rsp=0000000125af1a70
1673.391:012c:0238:trace:seh:handle_syscall_fault   r8=0000000000000001  r9=0000000000000072 r10=0000000000000000 r11=0000000000000000
1673.391:012c:0238:trace:seh:handle_syscall_fault  r12=00007f6eca8545c0 r13=00007f6eca821a53 r14=0000000125af41c0 r15=00000000fbad2887
1673.391:012c:0238:trace:seh:handle_syscall_fault returning to user mode ip=000000007bc0c2f4 ret=c00000fd
1673.391:012c:0238:err:winstation:map_shared_memory_section failed to map view of section L"__wine_desktop_mappings\\WinSta0\\Default": c00000fd

steam-438100.tar.gz

Tested various Proton builds between 5.0 and Experimental, did not seem to fix the issue.

EDIT: I've noticed a trend: VRAM usage (measured by RADEONTOP) gets to ~8000MB used, game crashes, then drops down to 3600MB afterwards... Watching VRAM usage, it caps around 65% (so not out of VRAM) and system RAM has 27.53GB free (not out of system RAM)... But, 8000MiB - 3600MiB = 4400MiB. 2^32 bytes is 4294967296 or +/- 4295 MiB... Throw in a little overhead for submitting frames and such... Is the game hitting a 32-bit limit somehow? It's a 64-bit executable.... Also, since the memory usage continuously increases while just sitting (even at the login screen!) is there maybe a memory leak of some kind? I checked with Beat Saber in the same version of Proton and it didn't seem to have any issues...

I tried in Desktop mode, and the game seems to run fine. I was able to go from ~3000MiB VRAM used up to 8300MiB VRAM used with no problems by loading into some larger worlds. The problem seems to be isolated to running the game in SteamVR mode.

Unsure what exactly it is that I did, but I no longer seem to be able to reproduce the crashing.

Did a lot more testing, including re-installing SteamVR, and now the game is behaving properly. The VRAM usage, when loading into an intensive world in VR now goes up normally, then stops as it should, and does not continuously climb like it was last night. Haven't rebooted the system or changed anything significant beyond mucking around with Steam and Proton (IE re-installing Proton, re-installing SteamVR, moving between different library folders...) None of which seems it should matter, but something seems to have corrected the issue.

@Goofybud16 I heard that there is a bug in VRChat effecting all users that consumes VRAM until a crash. Apparently it's linked to video player emissions in worlds.

If you're watching a video in a world, disable video light emission if you can.

As of the latest update, the game seems to be continuously crashing. Not sure why.

Tried re-installing the game, restarting PC, re-applying the LipSync DLL fix from above.

It works for a few moments, then crashes.

Having the exact same issue. Tried with most versions of Proton (including the latest GE), uninstalling/reinstalling and rebooting but no luck. Desktop mode runs fine; only the VR mode is affected.

Unsure what exactly it is that I did, but I no longer seem to be able to reproduce the crashing.

Did a lot more testing, including re-installing SteamVR, and now the game is behaving properly. The VRAM usage, when loading into an intensive world in VR now goes up normally, then stops as it should, and does not continuously climb like it was last night. Haven't rebooted the system or changed anything significant beyond mucking around with Steam and Proton (IE re-installing Proton, re-installing SteamVR, moving between different library folders...) None of which seems it should matter, but something seems to have corrected the issue.

I've not tried moving the libraries to different locations. But your comment is definitely a ray of hope for me. Thank you! @Goofybud16

@Goofybud16 I heard that there is a bug in VRChat effecting all users that consumes VRAM until a crash. Apparently it's linked to video player emissions in worlds.

If you're watching a video in a world, disable video light emission if you can.

The VRAM issue I was having would kill me even sitting at the login screen. As in fresh install of the game, before even signing in once, it was crashing.

I've not tried moving the libraries to different locations. But your comment is definitely a ray of hope for me. Thank you!

Good to know I'm not the only one; I thought I was going crazy after it just resolved itself magically. I would advise, if you haven't, uninstalling SteamVR and VRChat, completely removing the folders for them in steamapps, and reinstalling them. That's my best guess as to what I did that fixed it, since I completely wiped Proton 6.3 off my system and re-installed; switched versions... Nothing else seemed to fix it. That's just my best guess though, I was taking random shots in the dark and then found "hey it works now" and didn't question it too much.

I'm experiencing this problem too. VRChat apparently fixed their VRAM bug I mentioned so I guess it is unrelated.

Uninstalling and reinstalling SteamVR and VRChat didn't help. I also tested with both SteamVR beta and non-beta and had the same problem. VRAM usage increases until around 80% and the game crashes.

I've not tried moving the libraries to different locations. But your comment is definitely a ray of hope for me. Thank you!

Good to know I'm not the only one; I thought I was going crazy after it just resolved itself magically. I would advise, if you haven't, uninstalling SteamVR and VRChat, completely removing the folders for them in steamapps, and reinstalling them. That's my best guess as to what I did that fixed it, since I completely wiped Proton 6.3 off my system and re-installed; switched versions... Nothing else seemed to fix it. That's just my best guess though, I was taking random shots in the dark and then found "hey it works now" and didn't question it too much.

Holy fudge it actually started to work again.
Basically I uninstalled both SteamVR and VRChat and reinstalled them fresh but this time into a different location. I had VRChat installed in my external HDD /media/storage/SteamLibrary/steamapps/compatdata/438100 before, but after uninstalling I've decided to reinstall VRChat back into my local SSD again to /home/kawanerio/.steam/debian-installation/steamapps/compatdata/438100.
Other than that I didn't have to change much (well, obviously SteamVR on linux_v1.14 build and VRChat on Proton 5.13-6). Heck, I didn't even have to reboot. It just magically started to work again.
Thank you so very much for your solution. I get to live yet another day on the other side. @Goofybud16

I found an old install on external NTFS drive with VRChat build 1128. I ran it through the terminal and the bug isn't there. If I run build 1132 which is the most current on Steam, the bug happens.

I've tried uninstalling it and reinstalling it in different places (including said external drive) but sadly the bug doesn't go away for me. @Goofybud16 @KawaneRio are you both using build 1132?

I've tried uninstalling it and reinstalling it in different places (including said external drive) but sadly the bug doesn't go away for me. @Goofybud16 @KawaneRio are you both using build 1132?

Yes, I'm on build 1132. The latest distributed by Steam.

Build 1133 just launched. Did a brief test and it seems to still work; the prior issue did not reoccur on my system after updating.

Well this is strange now.

If I run VRChat 1133 in the command line there is no problem. The VRAM doesn't fill up. But if I launch it from Steam it has the bug and crashes. On build 1132 I'm pretty sure the bug happened if I ran it from the command line or from Steam.

I ran it from the command line using the same prefix that Steam generated itself to get this result (the one in compatdata).

Unfortunately while running in the command line my controllers and bindings don't work (index controller, the fingers don't move and bindings to mute or toggle gesture don't work) so it isn't a good workaround for now.

Yeah I was on Build 1132 yesterday and on Build 1133 today. @duckbytes
I do have an unfortunate news as well. After I got that working yesterday, I slept, woke up, and now it has the same bug again. Whilst, thanks to Goofybud16, I know the solution to my problem now (uninstall/reinstall to different library), I tried fixing it without uninstalling and reinstalling everything all over again...but with no luck. So I had to uninstall both SteamVR and VRChat again, and had to reinstall SteamVR and VRChat, again, and, thankfully, VRChat was working again.
That was the backstory and now here's the unfortunate news: VRChat is indeed crashing again for me. It's 22:30 in JST now and I have to sit another 30 min (with my terrible internet speed) and work with reinstalling VRChat again. にゃー・・・・・・
And the worst part is that I didn't do anything! Well, I did swap out that OVRLipSync.dll in /home/kawanerio/.steam/debian-installation/steamapps/common/VRChat/VRChat_Data/Plugins/x86_64/OVRLipSync.dll with the 9.0MiB one, but other then that, nothing!

I believe I had this issue occur again today. I went to launch the game and got the Steam "update pending" dialog; the game launched and crashed.

I updated to SteamVR 1.20.1 Beta, and the game seems to have begun running normally.

I think I am seeing this issue as well; radeontop reports GTT usage constantly growing until it hits 100%, even at the login screen.

It seems to manage to recover a little memory, dropping to ~98% a couple times before climbing again, but then crashes for good. (VRAM stays at around 60% the whole time.)

I tried uninstalling and reinstalling SteamVR and VRChat, with no success.

I think I am seeing this issue as well; radeontop reports GTT usage constantly growing until it hits 100%, even at the login screen.

It seems to manage to recover a little memory, dropping to ~98% a couple times before climbing again, but then crashes for good. (VRAM stays at around 60% the whole time.)

I tried uninstalling and reinstalling SteamVR and VRChat, with no success.

When you uninstalled SteamVR, did you ensure that the SteamVR folder was completely removed from the steamapps/common folder?

Also, did you try switching on to/off of the SteamVR Beta channel?

I think I started seeing maybe the same crash. But after a couple crashes, the behavior now evolved into a hang, i.e. the Unity crash window didn't show up.

Basically the game just freezes after me sitting in the "Go" screen for a while. VRAM usage did go up, but it didn't reach 100% at the time of the hang (it was ~8.5G/16G).

In the proton log:

282651.192:0104:0248:trace:seh:dispatch_exception code=c0000005 flags=0 addr=00007F9CD3C18CE0 ip=00007F9CD3C18CE0 tid=0248
282651.192:0104:0248:trace:seh:dispatch_exception  info[0]=0000000000000000
282651.192:0104:0248:trace:seh:dispatch_exception  info[1]=0000000000000000
282651.192:0104:0248:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised
282651.192:0104:0248:trace:seh:dispatch_exception  rax=000000000000002b rbx=0000000076b166b0 rcx=0000000000000023 rdx=0000000000000000
282651.192:0104:0248:trace:seh:dispatch_exception  rsi=00000000015fd9c0 rdi=0000000076b166b0 rbp=0000000076b163a0 rsp=0000000076b139c0
282651.192:0104:0248:trace:seh:dispatch_exception   r8=0000000000000000  r9=000000003c7d1d06 r10=000000003c7d1d01 r11=0000000000000293
282651.192:0104:0248:trace:seh:dispatch_exception  r12=00000000d3c49430 r13=000000003c7d646d r14=000000000000002b r15=0000000000000003
282651.192:0104:0248:trace:seh:call_vectored_handlers calling handler at 0000000072141C50 code=c0000005 flags=0
282651.192:0104:0248:trace:seh:call_vectored_handlers handler at 0000000072141C50 returned 0
282651.192:0104:0248:trace:seh:call_vectored_handlers calling handler at 00000002EDF7FE50 code=c0000005 flags=0
282651.192:0104:0248:trace:seh:call_vectored_handlers handler at 00000002EDF7FE50 returned 0
282651.192:0104:0248:trace:seh:call_vectored_handlers calling handler at 000000007B00C660 code=c0000005 flags=0
282651.192:0104:0248:trace:seh:call_vectored_handlers handler at 000000007B00C660 returned 0
282651.192:0104:0248:err:virtual:virtual_setup_exception stack overflow 5328 bytes in thread 0248 addr 0x7f9cd3c18d67 stack 0x76b0fb30 (0x76b10000-0x76b12000-0x76c10000)

Looks like this is still a crash, it's just the crash window failed to show up. If this is the same crash, then the VRAM usage is probably a red herring?

Something that may or may not help; I'm not sure.

I've noticed sometimes the game will crash at the "Go" screen, but if I restart SteamVR it seems to work properly.

Is it maybe an issue with leaving SteamVR running for too long with no game running?

I have SteamVR Home disabled (just use the big empty background + the Dashboard when a game exits), does anyone else who has this issue also have SteamVR Home disabled?

Is it maybe an issue with leaving SteamVR running for too long with no game running?

I started VRChat right after I started SteamVR, so probably not?

With the latest update, this issue has recurred again. Going to see if I can't find a specific action that resolves it.

I have attempted:

• System restart
• Rename dxvk cache file (and, when it didn't resolve the issue, put it back afterwards)
• Rename mesa_shader_cache (and, when it didn't resolve the issue, put it back afterwards)
• Completely uninstalling VRChat (ensuring that the VRChat directory in steamapps/common was completely removed; as was compatdata/438100)
• Re-enabling Vulkan Async Reprojection in SteamVR (Re-disabled afterwards)
• Completely un-install SteamVR and re-install SteamVR
• Switch from SteamVR Beta back to SteamVR Release Branch
• Re-start Steam
• Uninstall VRChat and SteamVR; re-start Steam; re-install both to the default library
• Moved them both back to my SSD game library
• Launch the game in Desktop mode (works)
• Launch with no controllers connected
• Re-enable SteamVR Home
• Putting the VR headset on my head so as to trigger the proximity sensor
• Ensuring my Vive Trackers are not powered on when starting SteamVR (most previous attempts they were on prior to starting the game)
• Adjust date + time forwards 1 day (since before it seemed like "wait until the next day" would magically resolve it) -- of note; restoring system time back 1 day seems to freeze radeontop
• Switch back to SteamVR Beta

None of that worked; and honestly, a lot of it was just blind shots in the dark and hoping that maybe something would work. I'll try again tomorrow and see if I can't get it to work; assuming the game doesn't just magically start to work again as it has in the past.

I'm wondering if this might be a problem with VRChat itself. I've been running it in a Windows VM with my 5700XT passed through.

It works ok for a while but eventually it'll almost lock up the VM and I have to force shut it down. "Almost" lock it up because it is still running. The Windows desktop and game becomes incredibly slow to the point you can't interact with anything, but is still just about moving.

I'm not sure if it's because of VRAM use. I do have a VRAM monitor on OVRToolkit which I haven't noticed any high values, but I don't think it's accurate. I've heard about AMD cards not reporting VRAM use properly and since OVRToolkit often shows my VRAM use as 2% while in VRChat, I don't believe it's showing the correct value.

This problem also comes on the tail of a bug VRChat fixed recently where VRAM was being consumed to full when a world had video emission. I only heard about this from friends though, I can't find a bug report about it.

This problem also comes on the tail of a bug VRChat fixed recently where VRAM was being consumed to full when a world had video emission. I only heard about this from friends though, I can't find a bug report about it.

I believe that was related to this changelog:

Updated VRChat to Unity 2019.4.30f1. This upgrade is minor, and is aimed at addressing some known issues; content uploaded on 2019 does not need to be updated. This Unity upgrade fixes some issues, namely a VRAM bug with Realtime GI as well as the "Unity crashes with multiple monitors with different scaling values" issue

https://store.steampowered.com/news/app/438100/view/2881730560232097345

That is the release where this issue first occurred.

On the first day of the last engine update this issue was a problem for me. For unknown reasons, the next day, the issue resolved itself. What really throws me off with this issue is that it seems to come and go. Sometimes I'd start the game and it'd crash after a few minutes (indicating this issue), and then on the next restart, it'd be fine. I did manage to play at least a little bit just about every day, though, so the game was definitely working fine most of the time.

With the latest VRC update (which bumped Unity versions again to 2019.4.31f1) the issue seems to be even worse than before; as before it still seemed to work in some cases; whereas now it seems to be broken 100% of the time.

I wonder, if anyone still has the old build before this issue occurred, do they use the same OpenVR_API DLL? I tried and failed to track down an older one; but in removing some Plugin DLLs (to attempt to isolate if it was a seemingly unrelated Unity plugin causing issues), I found that the game has the issue even just sitting at the very first "Loading" screen. Whatever this problem is, it seems to be pretty core to the game or the game's rendering pipeline. (Removed the video player related DLLs to force the game to get stuck that early in startup)

For now, though, I think I've given up on trying to fix it; it's possibly a game bug. I tried Proton Experimental, that didn't seem to improve it. Hopefully the next update will resolve the issue.

I've opened an issue on the VRChat Client Bug Report form; hopefully it'll get a better response than "Sorry, we don't support anything but Windows." https://feedback.vrchat.com/bug-reports/p/game-crashes-after-a-short-period-when-playing-via-steam-play

I wonder, if anyone still has the old build before this issue occurred, do they use the same OpenVR_API DLL?

I haven't played for a bit (got tired of always having to fix something), my openvr_api.dll is 586.8kB and was downloaded on 2/9/21, if that helps.

my openvr_api.dll is 586.8kB and was downloaded on 2/9/21, if that helps.

Looks like the fresh latest version is 586.8KiB as well. Just in case (minor changes, same size of .dll, but new version), the MD5 of the current version is e85622ffa2fc95b618f86a5b8e2d15b8, does that match yours?

Yep, identical MD5. Well, at least that's one thing we can rule out.

Went into vrchat to see if I could reproduce the issue and it's working out of the box for me right now. Weirdly I got a steamvr 203 error while shaders were compiling, but otherwise it just worked. I ran around the home world for a bit, then went to the Japan shrine world and walked around there for a while.

System ram 11.8GB used out of 31.3.
Vram 5GB used of 11

Kubuntu
5.11.0-37-generic
Nvidia 2080ti on driver 470.63.01
Proton 5.13-6
Non-beta SteamVR

I just tested it again and it still has the issue; even sitting at the login screen.

For anyone else with the game having the consuming VRAM issue, are you on AMD or NVidia? I'm on a Radeon 6700XT with Mesa 21.2.2.

I forgot to mention it took an excessive amount of time building shaders (talking like 20 minutes on an i9 9900), so I left for breakfast. I came back and it had been idle on the login screen for most of an hour before I did the walk around.

@Goofybud16 I have 6800XT with Mesa

@Goofybud16 I have 6800XT with Mesa

@yshui Can you grab the output of

vulkaninfo | grep Mesa
or, if that fails,
glxinfo | grep Mesa

Since it seems to work on NVidia and break on AMD, I adjusted my game command line as follows (requires Konsole to be installed; you may have to adjust it for your preferred terminal emulator):

konsole --hold -e /bin/bash -c "RADV_DEBUG=errors %command%"

I then got a lot of

../src/amd/vulkan/radv_descriptor_set.c:556: VK_ERROR_OUT_OF_POOL_MEMORY

lines in the Konsole window (as the VRAM seemed to leak alongside the messages).

I tried some various other RADV_DEBUG flags as well, but none seemed to make much difference to the VRAM leak.

Hello @Goofybud16, it should be noted that VK_ERROR_OUT_OF_POOL_MEMORY can happen a bunch during normal operation of any game that touches Vulkan and that shouldn't be used as a hint by itself.

Noted.

I may have found a clue...

If I set the launch options to

RADV_PERFTEST=nosam %command%

VRAM usage no longer grows, instead GTT grows like Tangent128 had seen:

I think I am seeing this issue as well; radeontop reports GTT usage constantly growing until it hits 100%, even at the login screen.

If I set it to

RADV_PERFTEST=sam %command%

(which is the default on my system) it restores the original behavior of eating VRAM and crashing.

I tried to dig through Mesa sources a bit, but definitely am in over my head a little bit; however my best guess is that somehow the game is leaking command buffers...

Turning on RADV_DEBUG=allbos, the FPS of the game will continuously drop the longer it runs; as does the rate of VRAM/GTT being leaked.

Turning on RADV_DEBUG=noibs, the rate of the leak seems to be greatly reduced, however the game seems to also crash at a lower VRAM usage.

What's the best way to get a useful recording of this? Just PROTON_LOG=1, or is there a better way?

Has anyone tested VRChat with AMDVLK?

I rolled back to Mesa 20.3.5 and the issue still occurs, GTT fills up slowly (but not completely) followed by a game crash.

Has anyone tested VRChat with AMDVLK?

Hmm, during my short test, AMDVLK worked fine. Can someone confirm my results?

To test, you need to install amdvlk, version at least 2021.Q3.4. Then start steam with AMD_VULKAN_ICD=AMDVLK steam, then start VRChat from there.

(Although this could be a workaround, AMDVLK's performance is really terrible here)

Hmm, during my short test, AMDVLK worked fine. Can someone confirm my results?

I'll try to as soon as I get my system straightened out-- looks like Debian is currently in a strange transitional period where testing has Mesa 20.3.5 (doesn't play nice with the 6700XT) and Unstable has 21.2.3 on amd64 and 21.2.2 on i386 (which means either I have a buggy graphical environment or can't have both my DE and Steam installed [requires 32-bit Mesa] until they sort out 21.2.3 on i386/I figure out exactly the packages I need to roll back to go back to 21.2.2).

Surprisingly, VRChat is working fine for me.
It seems that in my environment, VRChat only freezes few minutes in only when I swap out that OVRLipSync.dll in /home/kawanerio/.steam/debian-installation/steamapps/common/VRChat/VRChat_Data/Plugins/x86_64/OVRLipSync.dll with the modified dll; but actually ran fine after re-swapping the OVRLipSync.dll with the original one VRChat shipped it with.

I am on the latest UbuntuStudio LTS (Ubuntu 20.04.3 LTS x86_64; 5.4.0-84-lowlatency) with AMDCPU (AMD Ryzen 5 3600) and AMDGPU (AMD Radeon RX 580 8GB), running SteamVR on [linux_v1.14] and VRChat with Proton 5.13-6 (with WINEDEBUG="+timestamp,+pid,+tid,+seh,+debugstr,+module" %command% for launch option).
Oh, and I launch CoreCtrl before playing the game. CoreCtrl is set to Advanced Performance with Virtual Reality Power Profile.
I also have four monitors connected to my PC, all set to 60Hz if that means anything.

It should also be noted that I had to uninstall both SteamVR and VRChat from my external HDD and then reinstalled VRChat back into my home SSD before I got it to work again. LipSyncs don't work, but hey. "It's a small price to pay for salvation":innocent:

Sorry I can't be of any help here.

Sorry I can't be of any help here.

Actually, this was extremely helpful.
I tested with SteamVR 1.14.16 (the linux_1.14 branch) + Proton 5.13-6 and the memory leak seems to have stopped.
I've also fully updated my system to Mesa 21.2.3.

I updated back to SteamVR 1.19.7, and the memory leak still seemed to have stopped.
Rolling forwards to Proton 6.3-7, the memory leak came back.
Rolling back to Proton 5.13-6, the memory leak returned.

So it seems that something between Proton 5.13-6 and Proton 6.3-7 (which has persisted into Proton Experimental as of today, Oct 7 2021) is related to or the cause of the memory leak. That leak is also possibly related specifically to RADV, and other drivers (that probably behave differently or hit a different code path) don't hit this bug.

@yshui, can you test this as well? Roll back to Proton 5.13-6 and see if it resolves the crash when using RADV.

I did some further testing and found that if I removed the OVRLipSync DLL, then the game would work on Proton 6.3-6. Unsure why exactly (maybe a race condition or something?)

@Goofybud16 did you repeat your test several times with each setup?

@Goofybud16 did you repeat your test several times with each setup?

I tested swapping to the old DLL that worked with old Proton versions (and re-introduced the bug on 5.13, same as KawaneRio saw) then put the new one (that doesn't work on 5.13) back, and the game worked again.

I then rolled forwards to the latest Proton (6.3), which caused the issue to return even with the new DLL (I believe it added the missing function call that broke the DLL before), and then renamed the dll (changed the file extension) and that caused the game to begin behaving itself again.

While I don't expect that the OVRLipSync DLL is the direct cause of the issue (because it worked fine until the last few updates) I do suspect that it may be somehow altering a race condition or something within driver or game code (and this may also be why AMDVLK and NVidia don't exhibit the behavior; slightly different timing)

With the new VRChat open beta (VRChat 2021.4.1 build 1137) running in VR mode hangs at a black screen on the desktop view and the "Next Up" screen in VR. Starting the client in desktop mode loads correctly. Tested with Proton 6.3-7, 6.16-GE-1, and Experimental. Both normal SteamVR 1.19 and beta (1.20.3) have this issue. At one point a crash reporting window appeared and seemed to send a report.

I reproduce the same behavior as the public branch of VRChat on the Open Beta. OVRLipSync DLL loads = game leaks VRAM/GTT, crashes after a period of time. OVRLipSync DLL fails to load and it gets to the "Go" screen and waits as it should. Tested on Proton 6.3-7 + SteamVR 1.19.7.

@mpnordland, what are your system specs? CPU, GPU, and Distro

@Goofybud16 Here's my specs. After installing some updates (including a kernel update) and rebooting I was able to get the Open Beta to run successfully in VR as well.

OS: Arch Linux x86_64
Kernel: 5.14.8-arch1-1
Resolution: 3840x2160
DE: GNOME 40.5
CPU: AMD Ryzen 9 5950X (32) @ 3.400GHz
GPU: NVIDIA GeForce GTX 1070
Memory: 64229MiB

I just tried with 5.13-6 and that fixes it for me too. Played a couple of hours on it and no crashes.

Hmm, I think you are on to something @Goofybud16 .

Yes, deleting OVRLispSync.dll does seem to correlate with the game working properly. I tested proton 6.3-7 back-and-forth several times. Deleting OVRLispSync.dll does seem to make the game work, and putting it back makes the game crash again. (I was simply waiting at the "Go" screen, maybe the game still crashes when in world. I need to do more testing)

Would be nice if more people can confirm this.

I can confirm that removing OVRLipSync.dll stops the memory leak for me too on proton experimental.

Shame I can't see anyone talking now.

From the sounds of things, it sounds like this only happens on DXVK + RADV.

What would be the best way to record the differences? Since just adding and removing that DLL allows reproducing the issue on-demand, it seems like it should be possible to record twice and then diff the calls made. See if maybe it's the game itself (a race condition or something internal causing the game to misbehave) or maybe a bug in DXVK/RADV? We've gotta hope the devs will fix the game if it's a game bug, but it's conceivable that if we could trace down an issue in DXVK/RADV, it would be fixable.

@Goofybud16 did you manage to try AMDVLK?

@Goofybud16 did you manage to try AMDVLK?

I just did. Turns out, you can use the Ubuntu 20.04 and 18.04 AMDVLK debs on Debian Testing, which simplified things a lot.

SteamVR definitely does not seem to like AMDVLK in the slightest; as even though it reports 6.4-6.5ms frame times, the "frame timing graph" is solid pink and it stutters like crazy, despite the game holding 100+FPS as reported by DXVK_HUD. That's likely an issue for the SteamVR-On-Linux repository, though.

I was, however, able to verify that the game does not leak VRAM on AMDVLK v-2021.Q3.7 with lip sync working in VR mode.

DXVK_HUD=FULL reports as follows:

just sitting in the default VRChat Homeworld.

That, to me, indicates that there's either possibly some race condition somewhere, or maybe a bug in RADV?

@Goofybud16 Thanks!

Really interesting. I can't imagine how lip sync and mesa could have this kind of problem when put together :thinking:

Should we report this to mesa?

Edit: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5538

Interestingly I have had the same overall behavior but it fills my system ram and not my vram (Arch, 5700xt). I also didn't find this thread until just now and have been investigating in parallel. I found this after I deleted the lipsync dll, thinking I broke it by replacing it with the updated version. Very very frustrating experience.

Interestingly I have had the same overall behavior but it fills my system ram and not my vram (Arch, 5700xt). I also didn't find this thread until just now and have been investigating in parallel. I found this after I deleted the lipsync dll, thinking I broke it by replacing it with the updated version. Very very frustrating experience.

VRAM vs System RAM depends on if your system has Smart Access Memory enabled. I have resizable BAR enabled, so RADV defaults to SAM=on. In that condition, it will eat VRAM. If I force it off using the environment variable, it will fill GTT (as seen in radeontop) which is in System RAM.
Doing some digging in the Mesa sourcecode, to the best of my ability, it looks like the difference is mostly where Vulkan command buffers are stored, but I could be completely incorrect on that statement. That leads me to believe that command buffers are being leaked, but I'm not sure why the lipsync DLL would make it start leaking command buffers as soon as the game renders frames, before it's even handled voices. That also makes me wonder if it's a VRC bug (does the game itself leak DX11 structures that translate to command buffers through DXVK?), a DXVK bug (DXVK itself is leaking the command buffers), or a RADV bug (RADV is leaking VRAM). I'm not really sure how to determine that, which is why I haven't created a bug report to DXVK or Mesa, because I'm not quite sure who actually has the code that causes the leak.

Just tested with the latest game update, the issue is still present.
Mesa 21.2.5.

From the sounds of things, it sounds like this only happens on DXVK + RADV.

I have the exact same issue with NVIDIA by the way.

That is, the issue that VRChat won't start into VR mode anymore since the most recent VRChat update from last Tuesday, just a black screen.

Small update:

Going back to Proton 5.0 or 5.13 allows getting back into VR again (although rather unreliably, sometimes it doesn't work and ends with the same frozen screen). This brings back the issue though that quite often worlds won't load or other connection issues (basically their web sockets timing out and not reconnecting automatically).

I've noticed that it seems like the game might have some strange persistent VRAM leak. I've noticed that after going to large worlds with a lot of people, when I go to another world afterwards, my VRAM will still stay maxed out (and seeming to overflow into GTT), and the next world will run poorly (especially poorly if I enable a mirror). Restarting the game and visiting the second instance, it seems to run fine (and VRAM utilization massively drops as soon as the game exits.)

When playing with friends on Windows, even if they go to the same worlds at around the same time as I do, they do not have this issue.

Is it possible that maybe the game does something unusual to deallocate VRAM, and that isn't working? Or possibly it's the same bug that is causing the initial crash due to the game for some reason rapidly allocating and de-allocating VRAM for some process related to lip sync.

I did some further investigation (since the connection issues on Proton 5.x are really terrible, plus the OVRLipSync.dll hack didn't work anymore for some reason):

As others had suggested here, I deleted the OVRLipSync.dll file, and now VRChat is working in VR again (as in, no frozen window when VRChat is starting). Although since I'm on NVIDIA, I doubt this is a Mesa-exclusive issue.

Here's my Proton log (6.3-7) running VRChat in VR mode with OVRLipSync.dll in place:
https://gist.github.com/DASPRiD/0da8086390f6bc0fe87802a50997f9bf

Proton Experimental updated, I added back in the original OVRLipSync.dll that shipped with the game, and now I'm holding steady at ~6862-6863MB VRAM usage (and 2408 MB GTT) while loaded into the default home world with working lip sync.

Can anybody else reproduce this with the latest Proton Experimental?

Can anybody else reproduce this with the latest Proton Experimental?

Are you running experimental on no beta or on bleeding-edge?

It seems to be fixed for me too on Experimental.

Can confirm as well, nice!

Me, watching at others having a working LipSync in VRChat while I just stick to my Proton 5.13-6 with a working VRChat:

inxi -Gz

Graphics:
  Device-1: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] 
  driver: amdgpu v: 5.11.32.21.40 
  Display: x11 server: X.Org 1.20.11 driver: amdgpu,ati 
  unloaded: fbdev,modesetting,vesa tty: N/A 
  OpenGL: renderer: Radeon RX 580 Series (POLARIS10 DRM 3.43.0 
  5.11.0-40-lowlatency LLVM 12.0.1) 
  v: 4.6 Mesa 21.3.0-devel 

@KawaneRio have you tried SteamVR stable or beta? The 1.14 branch is super old now.

I'm on the beta but didn't test on 1.14.

Steam beta Update, on SteamVR beta 1.21.2... holy tupper, VRChat not only launched with the latest Proton Experimental, but the Lipsync is ACTUALLY WORKING!!
Whoever's behind this Proton/SteamVR is doing God's work. Thank you so much...:sob:

With the latest VRChat, it seems that the video player will crash the game when in a world with a video playing in some cases. The old fix of removing read, write, and execute permissions on yt-dlp.exe in the folder steamapps/compatdata/438100/pfx/drive_c/users/steamuser/AppData/LocalLow/VRChat/VRChat/Tools/ seems to fix the issue for now, though.

Oh weird, I removed the disabler I had on the AVPro video player because my latest testing regarding video players on Proton suggested it was no longer causing crashes. Unfortunately, both still don't work, even with a variety of alternative methods attempted. Given that there are apparently some scenarios where AVPro player still causes crashes in Proton, I will re-apply the disabler in the next update, until Valve is able to fix the compatibility issues with video players.

Some worlds (eg Room of the Rain) seemed to be fine, even when trying to play a video. (It didn't work, but didn't crash either)

If it's useful, this was the specific world that caused a (repeated) crash, although I'm not sure what the URL was in the player: https://vrchat.com/home/world/wrld_860bdea8-0499-4c16-8170-5683a3a3ab8a (I suspect it was one of the playlists included in the world itself)

Keep in mind that there are two video players useable in VRChat worlds:

• Unity Video Player: The video player built in to Unity, uses the Windows Media Foundation (WMF) library on Windows (and Proton). Doesn't work in Proton
• AVPro "Stream" Player: A powerful video player asset capable of playing streams, as well as regular videos. Some worlds only use the stream player, because it can handle both. Uses WMF by default on Windows/Proton, though it is also capable of using the old DirectShow and newer WinRT libraries. None of them work in Proton (tried them all). Appeared it wasn't crashing VRChat anymore in my testing, though it is likely still causing crashes for some people, as you mentioned.

As I mentioned, I will be reinstating the code that disables AVPro "stream" player if Proton is detected, that will stop the crashing.

Oh weird, I removed the disabler I had on the AVPro video player because my latest testing regarding video players on Proton suggested it was no longer causing crashes. Unfortunately, both still don't work, even with a variety of alternative methods attempted. Given that there are apparently some scenarios where AVPro player still causes crashes in Proton, I will re-apply the disabler in the next update, until Valve is able to fix the compatibility issues with video players.

For testing purposes, how does one remove the disabler?

This post is kinda off topic, but...
are there any video players supported for Linux users in VRChat? The only ones I've seen are the ones where the video is embedded to the World so that it doesn't use any of the WMF to begin with, usually seen around Quest-user aimed worlds (example: Daily Quest Radio Gymnastics).

There are two problems that render both video players unusable in VRChat on Proton:

• Lack of WMF codecs: can be manually solved on the user's end by adding the codecs themselves, albeit doing this is questionable from a licensing perspective, depending on the codecs installed
• Proton incompatibility with loading videos from URLs: This cannot be worked around, Proton does not presently work with loading a video from a URL. Likely requires work on Valve's end to fix.

There are no video players in Windows builds of VRChat that don't use WMF, they all use WMF to play the videos, it is literally the codecs needed to play them. Worlds cannot do anything about that.
The Oculus Quest runs Android and uses the Android MediaCodec API and is not relevant to this conversation.
A native Linux build would allow VRChat to use the native Linux Codec Interface, fixing these video problems. But all existing worlds and avatars would be incompatible with the Linux build, so that is presently not an option.

For testing purposes, how does one remove the disabler?

I hard-coded it in. I removed that hard coding in the latest update. I could add it back with some kind of switch. But I have never disabled the standard Unity Video Player only the AVPro "Stream" player. I, frankly, am realizing there is no pleasing people in regards to that. If I hard disable AVPro, everyone will act like I disabled all video players. If I add a switch, everyone will complain the switch makes the game crash.

But all existing worlds and avatars would be incompatible with the Linux build, so that is presently not an option.

Just curious but could something like https://github.com/Joshua-Ashton/dxvk-native be used to make a native version that can still display worlds and avatars?

Realise it might not be too much different from running in proton right now. On the other hand if it means videos could be made to work it might attract future SteamDeck users and get a jump start on the (only rumoured) Valve standalone HMD using SteamOS.

Thanks for your work so far.

Just curious but could something like https://github.com/Joshua-Ashton/dxvk-native be used to make a native version that can still display worlds and avatars?

I doubt it, looks like it would need to be implemented at the engine-level. Which, in this case, would require modifying the source code of Unity itself, something that is not presently feasible. That is clever thinking though.

But all existing worlds and avatars would be incompatible with the Linux build, so that is presently not an option.

Am I assuming correctly that this wouldn't be an issue if the Windows version would be using Vulkan instead of Direct3D? (and obviously all worlds compiled for it).

Am I assuming correctly that this wouldn't be an issue if the Windows version would be using Vulkan instead of Direct3D? (and obviously all worlds compiled for it).

From what I have heard, probably no. There are still differences between a Windows asset bundle and a Linux asset bundle, even if they are both using the same rendering API.

Am I assuming correctly that this wouldn't be an issue if the Windows version would be using Vulkan instead of Direct3D? (and obviously all worlds compiled for it).

From what I have heard, probably no. There are still differences between a Windows asset bundle and a Linux asset bundle, even if they are both using the same rendering API.

Ironically, I can prove this is true. I was trying my hand at uploading an avatar from unity 2018 on Linux once and didn't have the Windows build target set up correctly, but I didn't realize it at the time. I was laughing when I saw neither the PC or Quest icon light up and realized that I probably uploaded the world's first Linux-only VRChat avatar 😂

So yes, definitely different at the core.

There are two problems that render both video players unusable in VRChat on Proton:

* Lack of WMF codecs: can be manually solved on the user's end by adding the codecs themselves, albeit doing this is questionable from a licensing perspective, depending on the codecs installed

I wonder if this could be mitigated by letting the video player use e.g. libvpx instead of WMF, or potentially use libvpx as fallback when Proton is detected, as recommended in the Proton dev talk (considering that YouTube videos all use VP9 or AV1 by now anyway):

https://youtu.be/AF_AY--EEJc?t=136

* Proton incompatibility with loading videos from URLs: This cannot be worked around, Proton does not presently work with loading a video from a URL. Likely requires work on Valve's end to fix.

What exactly is the issue here? Isn't VRChat just using youtube-dl to download the video and then play it on-the-fly while it is being written to the disk?

Edit: I was wrong, see below.
initially I thought the issue was with youtbe-dl (now yt-dlp) simply path failing but that's not the case.

The issue is the path to yt-dlp.exe not working on linux for the vast majority

That is blatantly false. The yt-dlp.exe works properly on every distro of Linux I have tested it on. The problem is that Unity is unable handle the web URL yt-dlp throws back when in a Proton context. Unity normally directly plays the video url straight from the web, but that does not work in Proton.

you're absolutely right, I'm sorry, allow me to retract that. Previously, it seemed like video players were simply not firing because it would fail to query yt-dlp, and that's no longer the case.

2021.12.07 23:38:35 Log - NativeProcess.HasExited: process exited with code 0, took 11554 ms. Command line: C:/users/steamuser/AppData/LocalLow/VRChat/VRChat\Tools/yt-dlp.exe (...)

2021.12.07 23:38:35 Log - [Video Playback] URL 'https://www.twitch.tv/djlostmelody' resolved to 'https://video-weaver.vie02.hls.ttvnw.net/v1/playlist/CrgEnNftC4_zv_DKXwu588936qhSbqLNG9W5Fn-B_n1HcygdlyFtQDan18Z78OFu73G2HkjwcoDxwxUk5MBRtaOh_3ab-qCXGZJR_4yI2-_hyy0ap3cmTmqBexQoexcSfCL-tXP_YJnJ_M9Cu71s5ft7aMDdzGl0KmqP4-v86Kja4wI18zTSmn17id7rj8G9VubGrBbQMtlwTn1nmLljoEQotx9O5IgdZ-O411-dwAMPvb8DiHinGsQaC3Msh_NmH2UVjUFTNoGN6CqMwGvAQEpPOOfMZr-N4IlJaCAxIdFkTCTeYDnsXNY7lflFoUYcGynZ3J5lPj-mbUhDCNgS9EBgpL5AjOfKB5n7yz2bGL6qK11oIkVLRhYSjhGrERJxIYd4M_mSw5FeyS_TUnHA-oyySdiWn94S5oHzR-5EvymmiauSfKoW4kdGhH-rFmtiksylbwtLyk0CTT_NhREWztffXe_Upff-q0s2QpBkfZ3AcqAHwMdq4DnRoqFiyItoFdLiMmD9Ay7tlSZRoImdf4gmGbRGJHoeZNTrb1hbb2-U4PIJ4F02d3pEK7rvunPe9PXSQWWAdBFYNrN08gunbJ7Vsnmni0jpX2tjIhdPf3jfLjguutsVhzkf7F3AMtDIEreOtVLgbeefzrgrdvKvcuV3jnPsuGIYTvaSsPn3vZ6gCuX_oXJtKb-AGEJoSi01noUnuOHXOyPUsJFXjGmYpCU6xyaGlQRrjrWxESzHJ5S7LZxh4T-qeHplVhoMl-5jkNpCqHB9v-T8IAEqCXVzLWVhc3QtMjC8Ag.m3u8'

2021.12.07 23:38:35 Log - [AVProVideo] Opening https://video-weaver.vie02.hls.ttvnw.net/v1/playlist/CrgEnNftC4_zv_DKXwu588936qhSbqLNG9W5Fn-B_n1HcygdlyFtQDan18Z78OFu73G2HkjwcoDxwxUk5MBRtaOh_3ab-qCXGZJR_4yI2-_hyy0ap3cmTmqBexQoexcSfCL-tXP_YJnJ_M9Cu71s5ft7aMDdzGl0KmqP4-v86Kja4wI18zTSmn17id7rj8G9VubGrBbQMtlwTn1nmLljoEQotx9O5IgdZ-O411-dwAMPvb8DiHinGsQaC3Msh_NmH2UVjUFTNoGN6CqMwGvAQEpPOOfMZr-N4IlJaCAxIdFkTCTeYDnsXNY7lflFoUYcGynZ3J5lPj-mbUhDCNgS9EBgpL5AjOfKB5n7yz2bGL6qK11oIkVLRhYSjhGrERJxIYd4M_mSw5FeyS_TUnHA-oyySdiWn94S5oHzR-5EvymmiauSfKoW4kdGhH-rFmtiksylbwtLyk0CTT_NhREWztffXe_Upff-q0s2QpBkfZ3AcqAHwMdq4DnRoqFiyItoFdLiMmD9Ay7tlSZRoImdf4gmGbRGJHoeZNTrb1hbb2-U4PIJ4F02d3pEK7rvunPe9PXSQWWAdBFYNrN08gunbJ7Vsnmni0jpX2tjIhdPf3jfLjguutsVhzkf7F3AMtDIEreOtVLgbeefzrgrdvKvcuV3jnPsuGIYTvaSsPn3vZ6gCuX_oXJtKb-AGEJoSi01noUnuOHXOyPUsJFXjGmYpCU6xyaGlQRrjrWxESzHJ5S7LZxh4T-qeHplVhoMl-5jkNpCqHB9v-T8IAEqCXVzLWVhc3QtMjC8Ag.m3u8 (offset 0) with API MediaFoundation

But all existing worlds and avatars would be incompatible with the Linux build, so that is presently not an option.

Is it possible to release an SDK that uploads Linux builds too, so in the future maybe a Linux native build will be possible?

Is it possible to release an SDK that uploads Linux builds too, so in the future maybe a Linux native build will be possible?

Based on what Semperverus said a few weeks ago,

Ironically, I can prove this is true. I was trying my hand at uploading an avatar from unity 2018 on Linux once and didn't have the Windows build target set up correctly, but I didn't realize it at the time. I was laughing when I saw neither the PC or Quest icon light up and realized that I probably uploaded the world's first Linux-only VRChat avatar

It sounds like the current SDK is capable of it, but the way it's set up (possibly as an result of how the Unity SDK works) it's only able to export for a certain platform at a given time. I know when developing VRC content for Quest, you have to "switch" to the Android SDK at the Unity level, and re-build your avatar. That can be buggy, and so at least at some point, it was recommended to have to different Unity projects with the same avatar (but modified differently for lower powered hardware as required).

So I'm guessing that the current SDK could do it assuming there was a "Linux" build of VRC-- you just build it the same way you do for Quest.

So, with the current system of uploading the platform-dependent asset bundles, I'm guessing every new platform that gets added adds extra work on the side of the content creator (they have to manually upload to each platform, because the switch between Unity platform SDKs was slow and prone to issues from experience and what I've heard).

There are other similar VR games that allow content creation that works across platforms, including uploading it to the cloud and restoring it into the current instance. My educated guess is that on a technological level, it can be done, but it'd likely require a massive change in how VRChat handles user generated content (possibly abandoning the current asset bundle system completely).

Am I the only one crashing as soon as VRChat tries to open [AVProVideo] https://url... (offset 0) with API MediaFoundation? I don't recall this happening two days ago...

Steam Beta Update (Built: Dec 16 2021, at 22:39:26)
Using SteamVR 1.20.4
VRChat running with Proton Experimental.

My System Info
SteamVR System Report (SteamVR-2021-12-22-PM_11_05_15.txt)

Output Log 1: output_log_22-49-44.txt
Output Log 2: output_log_22-38-45.txt

@KawaneRio chmod 000 the ytdl.exe file.

Again, my testing on Steam Deck, suggested that AVPro no longer caused hard crashes. Evidently, that is still not the case for other distros so I'll be returning it to be disabled in the next update until such time that it is possible for me to make it actually work. Sorry for the inconvenience caused there. I know this part will be ignored, but the Unity Video player will remain not disabled as it does not crash the app on failure.

I'm not sure if it has been mentioned already or not, but after some testing I found that the Unity video player works great on Proton 6.3-8 with the following video criteria: webm containers with vorbis as audio codec, and vp8 as video codec.

I'm not sure if it has been mentioned already or not, but after some testing I found that the Unity video player works great on Proton 6.3-8 with the following video criteria: webm containers with vorbis as audio codec, and vp8 as video codec.

Is this in a VRChat context? If so, please post all the details regarding your distro, packages you installed, etc.

Can confirm, this was the same codec combo we discussed over dms a
few weeks ago that I knew to work.

On Wed., Dec. 22, 2021, 6:59 p.m. MehStrongBadMeh, @.***>
wrote:

I'm not sure if it has been mentioned already or not, but after some
testing I found that the Unity video player works great on Proton 6.3-8
with the following video criteria: webm containers with vorbis as audio
codec, and vp8 as video codec.

Is this in a VRChat context? If so, please post all the details regarding
your distro, packages you installed, etc.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-999948057,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFQNHWT3Y7PCES3PTZCFABTUSJQ7PANCNFSM4FS34H6A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID:
@.***>

I'm not sure if it has been mentioned already or not, but after some testing I found that the Unity video player works great on Proton 6.3-8 with the following video criteria: webm containers with vorbis as audio codec, and vp8 as video codec.

Is this in a VRChat context? If so, please post all the details regarding your distro, packages you installed, etc.

I can confirm as well, I was able to make a video play. I encoded it with ffmpeg using ffmpeg -i 'my-video-file.mp4' -c:v libvpx -b:v 1M -c:a libvorbis myoutputfile.webm, hosted myoutputfile.webm where VRChat could access it (and it wouldn't get transcoded), allowed access to yt-dlp.exe again, and it works!

I'm running on Debian Testing + Proton Experimental.

Looks to me like it's probably just a codec issue with Proton, possibly requiring some non-free codecs that can't be implemented?

I tried to play the same URL with the Stream player and the game crashed.

I'm not sure if it has been mentioned already or not, but after some testing, I found that the Unity video player works great on Proton 6.3-8 with the following video criteria: webm containers with vorbis as audio codec, and vp8 as video codec.

Is this in a VRChat context? If so, please post all the details regarding your distro, packages you installed, etc.

Yes, it is in a VRChat context (Viewing videos on a vrchat video player inside a world, I can confirm that the Udonsharp video player in the 'CBC in Pajamas' world works flawlessly with the combo vp8/vorbis in a webm container.

I use Gentoo Linux, And my packages should not affect the result as I tested with the bundled (with steam) steam runtime; But I've attached a package list regardless since you asked for itinstalled-pages.txt.

Theory/Speculation:
I believe the reason this works is since VP8 and Vorbis are both listed as natively supported by Unity on all platforms, and are both open source and royalty free, It seems feasible they might be built into unity itself.

Edit:
Also for the record I've not experienced any crashes with AVPro or ytdl

Two questions @Goofybud16 and @FrostbyteVR

1. Are you playing the videos hosted via a webserver (I.E. an http or https link)?
2. Could you also test this with a VP9+Opus webm just for reference (you may already have done so, if so, confirm your results)?

I'll take a look at this after the team break, does open up some interesting possibilities.

I can also confirm that vp8 works. I tested that out some time ago when trying to figure out how to get the video player to work but gave up because I couldn't think of a reliable way to transcode literally everything as it comes in.

Two questions @Goofybud16 and FrostbyteVR

1. Are you playing the videos hosted via a webserver (I.E. an http or https link)?

Yes. I stuck the video file on an internet-facing webserver with HTTPS. In my case, I transcoded a 1 minute segment of an old Youtube video I had laying around. I can send the link (or the file) directly if you're interested, but I'd rather not post it publicly.

2. Could you also test this with a VP9+Opus webm just for reference (you may already have done so, if so, confirm your results)?

I used almost the exact same transcode command, but switched to VP9 (ffmpeg -i 'input-file.mp4' -c:v libvpx-vp9 -b:v 1M -c:a libvorbis test-vp9.webm) and it did not work. After attempting to play it, I pasted in the old VP8 URL, and the VP8 video did work.

Two questions @Goofybud16 and @FrostbyteVR

1. Are you playing the videos hosted via a webserver (I.E. an http or https link)?

Yes I've tested on both a local and remote web server (specifically nginx)

2. Could you also test this with a VP9+Opus webm just for reference (you may already have done so, if so, confirm your results)?

I tried some different combos for you, the only one that fully works is VP8 + vorbis, VP8 + opus produces a video but with no audio. VP9 does not produce a video at all, no matter the audio codec is used.

I'll take a look at this after the team break, does open up some interesting possibilities.

Great, by the way if you do re-disable the avpro player can you please make it a switch / launch argument to reenable it? I've personally not had any issues with avpro players in these latest builds

Vp8 has native decode support in unity itself, and they reccomend it: which
is a big reason why it "just works" without windows media foundations.
It's a handy format that doesn't low latency livestream the greatest but if
a certain cdn was running it as a dedicated output it would be pretty
awesome for upcoming devices running Linux natively. (Also the quest's soc
likes it a lot)

On Wed., Dec. 22, 2021, 9:12 p.m. FrostbyteVR, @.***>
wrote:

I'm not sure if it has been mentioned already or not, but after some
testing, I found that the Unity video player works great on Proton 6.3-8
with the following video criteria: webm containers with vorbis as audio
codec, and vp8 as video codec.

Is this in a VRChat context? If so, please post all the details regarding
your distro, packages you installed, etc.

Yes, it is in a VRChat context (Viewing videos on a vrchat video player
inside a world, I can confirm that the Udonsharp video player in the CBC
world works flawlessly with the combo vp8/vorbis in a webm container.

I use Gentoo Linux, And my packages should not affect the result as I
tested with the bundled (with steam) steam runtime; But I've attached a
package list regardless since you asked for itinstalled-pages.txt
https://github.com/ValveSoftware/Proton/files/7766195/installed-pages.txt
.

Theory/Speculation:
I believe the reason this works is because VP8 and Vorbis are both listed
as natively supported by Unity on all platforms
https://docs.unity3d.com/Manual/VideoSources-FileCompatibility.html,
due to the fact these codecs are open source and royalty free, It seems
feasible they might be built into unity itself.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-999991713,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFQNHWUBAGRX3JKX4YPRLWTUSKAR5ANCNFSM4FS34H6A
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID:
@.***>

Great, by the way if you do re-disable the avpro player can you please make it a switch / launch argument to reenable it?

I want to second this request. While I understand the need for disabling it, there's a small army of tinkerers here looking to try to get this working. Please create a way to force enable it, we understand the consequences.

I have an issue with VRChat. I'm running it on an ancient ThinkPad, an X230T with an Intel HD 4000 GPU. As such, it just barely supports DX11 on Windows, and Vulkan on Linux. Running this with DXVK gives an error about window resizing, so I have to run it with WINED3D. I'm using Debian Sid and WindowMaker.

When I do that, it runs, pretty much, but the lighting is very, VERY dark. Not quite a black screen, but about as close as you can get without being a black screen.

However, when I mouse over anything, like a mirror, or a menu, or any interactive object… let there be light.

Interestingly, the Proton log repeats the same messages over and over again.

6189.648:010c:033c:fixme:combase:RoGetActivationFactory (L"Windows.System.DispatcherQueue", {00000035-0000-0000-c000-000000000046}, 00000001C539F940): semi-stub
6189.657:010c:033c:err:combase:RoGetActivationFactory Failed to find library for L"Windows.System.DispatcherQueue"
6189.658:010c:0180:fixme:d3d:wined3d_device_resolve_sub_resource Multisample resolve is not fully supported for typeless formats (dst_format WINED3DFMT_R16G16B16A16_TYPELESS, src_format WINED3DFMT_R16G16B16A16_TYPELESS, format WINED3DFMT_R16G16B16A16_FLOAT).
6189.668:010c:0180:fixme:d3d:wined3d_device_resolve_sub_resource Multisample resolve is not fully supported for typeless formats (dst_format WINED3DFMT_R8G8B8A8_TYPELESS, src_format WINED3DFMT_R8G8B8A8_TYPELESS, format WINED3DFMT_R8G8B8A8_UNORM).

steam-438100.log

Here's what Steam thinks the machine has:
STEAMCPU.TXT

@roryyamm Your GPU seems to have a missing texture format
I don't think VRChat is compatible with integrated GPUs

I don't think VRChat is compatible with integrated GPUs

It should be, though. After getting DXVK to work (I had to explicitly enable DRI3 in my xorg.conf) it works just fine… until DXVK runs out of memory and brings VRC down with it, because it isn't content with 1.5 GB. Haswell GPUs do support OpenGL 4 and DirectX 11, which should be more than adequate for VRChat. I think it's a problem with the wined3d implementation.

I've noticed a trend that it seems like VRChat on DXVK uses a lot of VRAM-- short sessions can easily eat up 4GB and longer sessions can eat up 8-10GB. Not sure if that's the same on native Windows, but I'm not surprised at all that 1.5GB of VRAM isn't enough.

I wonder if there's a significantly observable difference in VRAM usage when using DXVK on Windows vs native DirectX?

Noticed a new issue since upgrading to Kernel 5.16.0: It seems that the game's audio thread will lock up. Mouths stop moving, I can no longer say anything or hear anyone, and the game starts to stutter really bad. It requires a restart of the game to fix. Seems to happen about once every hour or so.

Tested on v5.15.14, and there were no issues after several hours. Going to boot back into v5.16.0 tomorrow and see if the issue happens again.

If it's any use, I use Pipewire + WirePlumber, and the game is recording from a USB device (a Yamaha MG-10XU) and outputting sound directly to the Index via Displayport audio.

@Goofybud16 are you using wireplumber 0.4.6-1?

I updated wireplumber the other day and it completely broke my USB audio interface. I couldn't get any sound. Not exactly the same problem you're having but it indicates there might be problems with USB audio. I ended up downgrading to 0.4.5-2. and it's working fine again.

Hello @Goofybud16, it might be interesting to test if setting the game's launch options to PROTON_NO_FSYNC=1 %command% and using the 5.16 kernel behaves as you expected.

I'll try that! It was my understanding that current Proton versions still used an older incompatible revision of the futex2 call present in v5.16, so I didn't think to disable it, as I didn't think it would have enabled in the first place.

@Goofybud16 are you using wireplumber 0.4.6-1?

I updated wireplumber the other day and it completely broke my USB audio interface. I couldn't get any sound. Not exactly the same problem you're having but it indicates there might be problems with USB audio. I ended up downgrading to 0.4.5-2. and it's working fine again.

I still have wireplumber:amd64/testing 0.4.5-1 from Debian. Good to know that, though! I'll keep an eye out.

With PROTON_NO_FSYNC=1 %command% the game ran properly for several hours straight on 5.16.0 without the previously experienced audio bug.

I've noted it on that issue.

Another issue I observed, but didn't realize until just now, was that there was a broken world as well-- Sketchu Spring has a Helicopter-style flying device. I was unable to enter it (the "chair" was broken) and when other people would ride it, it would not animate properly.

I tested it briefly in desktop (With NO_FSYNC set) and it seems to work properly now. I'll test it again in VR tonight.

For anyone else who wants to test it, when you spawn into the world, there is a somewhat T-shaped dock that you spawn on. To one side, there is a blue orb, "clicking" it will spawn in the helicopter. In my case, I couldn't even it in it, and when someone else flew in it, I would see them moving, but the "helicopter" would just go straight forwards.

For anyone else who wants to test it, when you spawn into the world, there is a somewhat T-shaped dock that you spawn on. To one side, there is a blue orb, "clicking" it will spawn in the helicopter. In my case, I couldn't even it in it, and when someone else flew in it, I would see them moving, but the "helicopter" would just go straight forwards.

That's an extremely bizarre issue to happen based on a Linux client alone, that's fascinating. Can you speculate what it is about the translation to proton that would prevent network object sync from working correctly?

I can also confirm that vp8 works. I tested that out some time ago when trying to figure out how to get the video player to work but gave up because I couldn't think of a reliable way to transcode literally everything as it comes in.

Holy Tupper, this... this works！？

I can also confirm that vp8 works. I tested that out some time ago when trying to figure out how to get the video player to work but gave up because I couldn't think of a reliable way to transcode literally everything as it comes in.

I guess one way to do that would be to run a local transcoding service, and then compile a custom version of youtube-dl which reports URLs back which proxy over the local transcoding service. Of course, this would take up system resources, but since VRChat is only using a limited number of cores anyway, this might actually work, hmmm…

indeed

I can also confirm that vp8 works. I tested that out some time ago when trying to figure out how to get the video player to work but gave up because I couldn't think of a reliable way to transcode literally everything as it comes in.

Holy Tupper, this... this works！？

Screenshot
URL used: http://demo.nimius.net/video_test/videos/test.webm

I can also confirm that vp8 works. I tested that out some time ago when trying to figure out how to get the video player to work but gave up because I couldn't think of a reliable way to transcode literally everything as it comes in.

I guess one way to do that would be to run a local transcoding service, and then compile a custom version of youtube-dl which reports URLs back which proxy over the local transcoding service. Of course, this would take up system resources, but since VRChat is only using a limited number of cores anyway, this might actually work, hmmm…

This is a misconception, VRChat will use many cores for many things, it's quite threaded. Basically anything 2019.4.31f1 that unity can do in the standard pipeline, vrchat does, and then some including custom optimizations that they do for things like garbage collection. The team works hard over there.

But indeed, webm vp8 does work, as it's native to unity. Realtime encoding is heavy work, but if you have a processor that supports it, it can even be used to do things like stream to your quest 2 in virtual desktop ;) VP8 and VP9 are natively supported on the Quest, as well.

A local transcoding service isn't a bad idea, something that would pass all currently playing video to unity's video player as a https://localhost:8888/video.webm or something.

Lots of people stream the game and having something that runs in the background to handle video streams from players in game has been a desire of mine even on windows: because I want to be able to do things like have the output source of the video player at a separate physical volume from the in game audio for accessories like a woojer, or mirroring to subwoofers and whatnot. Being able to control the bitrate and other performance considerations would be neat too. Video recording from the in game camera would be nice, lots of things like that would be great on a companion app.

I was able to check it again-- the Sketchu world does work properly now.

My best guesstimate as to "why" is that there is logic related to chairs or some other function in VRC's SDK2 that is used which runs in another thread, and for some reason, that thread wasn't running or wasn't running properly.

That may or may not be related to the audio bug that was experienced.

@KawaneRio chmod 000 the ytdl.exe file.

@DASPRiD https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-999618131

This worked! Thank you!! :sob::sob::sob::pray:

For later reference for anyone having the same issue:

chmod 000  ~/.steam/debian-installation/steamapps/compatdata/438100/pfx/drive_c/users/steamuser/AppData/LocalLow/VRChat/VRChat/Tools/yt-dlp.exe 

I started seeing this crash:

Shader 'Standard': fallback shader 'VertexLit' not found
Shader 'Particles/Standard Unlit': fallback shader 'VertexLit' not found
Shader 'PPPen/Trail_Toon_Cutout': fallback shader 'Fallback/Toon/Cutout' not found
Shader 'Hirabiki/VRCLens/Standard VR-Only Object': fallback shader 'Diffuse' not found
Shader 'UnityChanToonShader/Toon_DoubleShadeWithFeather': fallback shader 'Legacy Shaders/VertexLit' not found
Shader 'UnityChanToonShader/Toon_DoubleShadeWithFeather_TransClipping': fallback shader 'Legacy Shaders/VertexLit' not found
Shader 'Sunao Shader/Opaque': fallback shader 'Diffuse' not found
terminate called after throwing an instance of 'std::out_of_range'
  what():  bitset::set: __position (which is 512) >= _Nb (which is 512)
Crash!!!

in some cases (maybe when certain avatar is present? unsure). Does anyone have similar experiences?

This crash message looks like something from libstdc++, so it's likely something on the Proton side crashed. Maybe it's dxvk?

@yshui, when does that crash occur? Game startup, in randomly when in a world, consistently in specific worlds?

I've found that there were some specific worlds that would consistently crash my game when trying to load in, but haven't been able to reproduce it in a little while.

What kernel, Mesa, and Proton version are you using currently to achieve that crash?

@Goofybud16 this happened right after i joined a world, after the "initialize world" screen. I can see the world and other players for like a second, then the game crashed. I tried multiple times with the same instance and it happens consistently.

But if I create another instance of the same world just for myself, I can join fine.

kernel: 5.16, mesa: git commit 7440fbd596a, proton experimental or proton 6.3-8

That sounds very similar to the issue I was having intermittently as well.

@yshui I noticed that as well – from what I could see, it has to do with a video player running (even with ytdl disabled).

@DASPRiD I tried using the video player in the world, it just failed normally, without causing a crash. So I am inclined to think it's not related to the video player.

maybe not related to the video player issue, I had chmod 000 yt-dlp.exe, but my game crashed while joining a world anyway. (tried twice) It was probably either related to it being in VR mode or it was some other user in that world when I tried in VR. (Haven't retried it in VR, but it doesn't crash in a new instance in desktop. The world was The Station (Channel 1) for reference)

Unsure if this is related to proton, but there were a lot of other players on Windows in VR so it probably is.

2022.01.21 22:58:10 Log        -  HTTPFormUseage:UrlEncoded


2022.01.21 22:58:13 Exception  -  Object has not been locked by this thread.
  at DžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDžDŽDŽDžDŽDŽDžDŽDžDžDžDžDžDŽDŽDŽDŽDžDŽDžDŽDŽDŽDŽDŽDžDž.DžDžDžDŽDžDžDžDžDžDŽDžDžDŽDŽDžDŽDžDŽDŽDžDžDžDžDžDŽDŽDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDŽDž () [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DŽDžDŽDžDŽDŽDžDžDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDŽDžDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽ (System.Int32 DŽDŽDŽDŽDžDŽDžDžDžDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDŽDžDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDžDŽDŽDžDžDžDŽDŽDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DžDŽDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDŽDŽDŽDžDŽDžDžDžDŽDŽDŽDŽDžDžDŽDŽDžDŽDžDŽDŽDžDŽDžDžDžDžDŽDŽDžDžDŽDŽ (System.Object DŽDŽDžDžDžDŽDžDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDŽDŽDžDžDŽDžDžDŽDŽDŽDžDžDŽDžDžDžDžDŽDžDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Action`1[T].Invoke (T obj) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 


2022.01.21 22:58:13 Exception  -  Object has not been locked by this thread.
  at DžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDžDŽDŽDžDŽDŽDžDŽDžDžDžDžDžDŽDŽDŽDŽDžDŽDžDŽDŽDŽDŽDŽDžDž.DžDžDžDŽDžDžDžDžDžDŽDžDžDŽDŽDžDŽDžDŽDŽDžDžDžDžDžDŽDŽDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDŽDž () [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DŽDžDŽDžDŽDŽDžDžDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDŽDžDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽ (System.Int32 DŽDŽDŽDŽDžDŽDžDžDžDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDŽDžDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDžDŽDŽDžDžDžDŽDŽDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DžDŽDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDŽDŽDŽDžDŽDžDžDžDŽDŽDŽDŽDžDžDŽDŽDžDŽDžDŽDŽDžDŽDžDžDžDžDŽDŽDžDžDŽDŽ (System.Object DŽDŽDžDžDžDŽDžDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDŽDŽDžDžDŽDžDžDŽDŽDŽDžDžDŽDžDžDžDžDŽDžDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Action`1[T].Invoke (T obj) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 


2022.01.21 22:58:24 Log        -  VRCApplication: OnApplicationQuit at 47.27266


2022.01.21 22:58:24 Log        -  NativeProcess.Start: started process id [2780]: Z:/home/webfreak/.local/share/Steam/steamapps/common/VRChat/VRChat_Data/../install.exe 


2022.01.21 22:58:24 Log        -  [Behaviour] OnLeftRoom


2022.01.21 22:58:24 Log        -  [Behaviour] OnDisconnected: DisconnectByClientLogic


2022.01.21 22:58:24 Log        -  [Behaviour] Client invoked disconnect.


2022.01.21 22:58:24 Log        -  [Behaviour] Unregistering WebFreak


2022.01.21 22:58:24 Log        -  Connected to lighthouse:LHR-6E50B063


2022.01.21 22:58:24 Log        -  HTTPFormUseage:UrlEncoded

2022.01.21 22:58:24 Error      -  [UdonBehaviour] An exception occurred during Udon execution, this UdonBehaviour will be halted.
VRC.Udon.VM.UdonVMException: An exception occurred in an UdonVM, execution will be halted. ---> VRC.Udon.VM.UdonVMException: An exception occurred during EXTERN to 'VRCSDKBaseVRCPlayerApi.__GetPosition__UnityEngineVector3'. ---> System.NullReferenceException: Object reference not set to an instance of an object.
  at VRC.Udon.Wrapper.Modules.ExternVRCSDKBaseVRCPlayerApi.__GetPosition__UnityEngineVector3 (VRC.Udon.Common.Interfaces.IUdonHeap heap, System.Span`1[T] parameterAddresses) [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDžDŽDžDžDžDŽDŽDŽDžDŽDŽDŽDžDžDžDŽDŽDžDžDŽDžDŽDžDŽDžDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽ.Invoke (System.Object DžDŽDŽDžDžDŽDžDŽDŽDžDŽDžDžDžDŽDŽDŽDžDžDžDžDŽDŽDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDŽDžDžDžDžDŽDŽDŽDŽDžDž, DžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDžDŽDžDžDŽDžDŽDžDŽDžDžDžDžDžDžDžDŽDŽDŽDžDŽDžDž DžDžDžDžDžDŽDŽDŽDžDžDŽDžDŽDžDžDŽDŽDŽDŽDžDžDŽDŽDŽDŽDŽDžDŽDŽDžDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDžDŽDŽDŽDžDž) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.VM.UdonVM.Interpret () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.RunProgram (System.UInt32 entryPoint) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.RunEvent (System.String eventName, System.ValueTuple`2[System.String,System.Object][] programVariables) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.ManagedUpdate () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonManager.Update () [0x00000] in <00000000000000000000000000000000>:0 
   --- End of inner exception stack trace ---
  at VRC.Udon.VM.UdonVM.Interpret () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.RunProgram (System.UInt32 entryPoint) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.RunEvent (System.String eventName, System.ValueTuple`2[System.String,System.Object][] programVariables) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.ManagedUpdate () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonManager.Update () [0x00000] in <00000000000000000000000000000000>:0 
   --- End of inner exception stack trace ---
  at VRC.Udon.VM.UdonVM.Interpret () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.RunProgram (System.UInt32 entryPoint) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.RunEvent (System.String eventName, System.ValueTuple`2[System.String,System.Object][] programVariables) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonBehaviour.ManagedUpdate () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Udon.UdonManager.Update () [0x00000] in <00000000000000000000000000000000>:0 


2022.01.21 22:58:26 Exception  -  Object has not been locked by this thread.
  at DžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDžDŽDŽDžDŽDŽDžDŽDžDžDžDžDžDŽDŽDŽDŽDžDŽDžDŽDŽDŽDŽDŽDžDž.DžDžDžDŽDžDžDžDžDžDŽDžDžDŽDŽDžDŽDžDŽDŽDžDžDžDžDžDŽDŽDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDŽDž () [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DŽDžDŽDžDŽDŽDžDžDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDŽDžDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽ (System.Int32 DŽDŽDŽDŽDžDŽDžDžDžDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDŽDžDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDžDŽDŽDžDžDžDŽDŽDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DžDŽDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDŽDŽDŽDžDŽDžDžDžDŽDŽDŽDŽDžDžDŽDŽDžDŽDžDŽDŽDžDŽDžDžDžDžDŽDŽDžDžDŽDŽ (System.Object DŽDŽDžDžDžDŽDžDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDŽDŽDžDžDŽDžDžDŽDŽDŽDžDžDŽDžDžDžDžDŽDžDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Action`1[T].Invoke (T obj) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 


2022.01.21 22:58:26 Exception  -  Object has not been locked by this thread.
  at DžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDžDŽDžDŽDŽDžDŽDŽDžDŽDžDžDžDžDžDŽDŽDŽDŽDžDŽDžDŽDŽDŽDŽDŽDžDž.DžDžDžDŽDžDžDžDžDžDŽDžDžDŽDŽDžDŽDžDŽDŽDžDžDžDžDžDŽDŽDžDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDžDžDŽDŽDŽDžDŽDž () [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DŽDžDŽDžDŽDŽDžDžDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDŽDžDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽ (System.Int32 DŽDŽDŽDŽDžDŽDžDžDžDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDŽDžDŽDŽDŽDŽDžDžDŽDžDžDžDŽDŽDžDžDžDŽDŽDžDžDžDŽDŽDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DžDžDŽDŽDŽDžDžDŽDžDŽDŽDžDžDžDžDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDžDžDžDŽDžDžDžDŽDŽDžDžDŽDžDŽDŽDŽDžDžDŽ.DžDŽDŽDžDžDžDŽDŽDžDŽDŽDžDŽDŽDŽDŽDŽDžDŽDžDžDžDŽDŽDŽDŽDžDžDŽDŽDžDŽDžDŽDŽDžDŽDžDžDžDžDŽDŽDžDžDŽDŽ (System.Object DŽDŽDžDžDžDŽDžDŽDžDžDžDžDžDŽDŽDŽDžDŽDžDžDžDŽDžDžDŽDžDžDŽDŽDžDžDŽDžDžDŽDŽDŽDžDžDŽDžDžDžDžDŽDžDŽ) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Action`1[T].Invoke (T obj) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state, System.Boolean preserveSyncCtx) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, System.Object state) [0x00000] in <00000000000000000000000000000000>:0 
  at DŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDŽDŽDžDŽDŽDžDŽDŽDžDžDžDžDŽDŽDŽDžDŽDŽDžDžDžDžDžDžDŽDžDžDŽDžDŽDžDžDžDžDž+DŽDŽDŽDžDžDŽDžDŽDŽDŽDžDŽDŽDŽDžDŽDŽDŽDŽDŽDžDžDžDžDžDŽDžDžDŽDžDžDžDŽDžDŽDŽDžDžDžDŽDžDžDžDžDžDžDŽ.Invoke (System.String DŽDŽDžDŽDžDŽDžDŽDŽDžDžDŽDŽDŽDŽDŽDŽDŽDŽDŽDžDžDžDŽDžDŽDžDŽDžDžDŽDŽDŽDžDŽDŽDžDžDŽDžDžDŽDžDžDžDžDž) [0x00000] in <00000000000000000000000000000000>:0 


2022.01.21 22:58:26 Log        -  VRCApplication: OnApplicationQuit at 49.28649


2022.01.21 22:58:26 Log        -  UserInterface destroyed

@WebFreak001 well there is your error right there:

2022.01.21 22:58:24 Error - [UdonBehaviour] An exception occurred during Udon execution

it's a different error from mine so not the same problem.

I guess one way to do that would be to run a local transcoding service, and then compile a custom version of youtube-dl which reports URLs back which proxy over the local transcoding service. Of course, this would take up system resources, but since VRChat is only using a limited number of cores anyway, this might actually work, hmmm…

I made something that live transcode videos to vp8 and it's taking 10 of my cores to reach 1x speed... seems somewhat unrealistic.

some points from my observation:

• video must be played with unity internal player, trying to play it with AVPro crashes the game
• the transcoded video must have a duration, otherwise it doesn't play
• unity player can't stream the video, it downloads the whole video then plays it.

Crash backtrace:

Backtrace:
=>0 0x00000001e683474a EntryPoint+0xfffa88da() in avprovideo (0x00000001d0c73384)
  1 0x00000001e683aa24 EntryPoint+0xfffaebb3() in avprovideo (0x000000000062ec89)
  2 0x000000006ca4f3c6 EntryPoint+0x458fc3d() in gameassembly (0x000000000062ec89)
  3 0x000000006a6e228d EntryPoint+0x2222b04() in gameassembly (0x0000000065584f40)
  4 0x000000006994e049 EntryPoint+0x148e8c0() in gameassembly (0x000000006994e020)
  5 0x0000000068b9c073 EntryPoint+0x6dc8ea() in gameassembly (0x000000006994e020)
  6 0x000000006a66b1f4 EntryPoint+0x21aba6b() in gameassembly (0x000000000062ee20)
  7 0x0000000068b9c073 EntryPoint+0x6dc8ea() in gameassembly (0x000000006a66aea0)
  8 0x000000006a66ae2f EntryPoint+0x21ab6a6() in gameassembly (0x0000000000000002)
  9 0x000000006b4f934e EntryPoint+0x3039bc5() in gameassembly (0x0000000000000002)
  10 0x00000000680f2d96 EntryPoint+0xffffffffffffffff() in gameassembly (0x0000000000000002)
  11 0x0000000068484c10 EntryPoint+0xffffffffffffffff() in gameassembly (0x0000000000000002)
  12 0x00000001808b92e0 EntryPoint+0xff4d6107() in unityplayer (0x0000000000000002)
  13 0x00000001808ca563 EntryPoint+0xff4e738a() in unityplayer (0x0000000000000000)
  14 0x00000001808d2150 EntryPoint+0xff4eef77() in unityplayer (0x000000000062f1c0)
  15 0x00000001808d21c5 EntryPoint+0xff4eefec() in unityplayer (0x000000000062f380)
  16 0x00000001808d21c5 EntryPoint+0xff4eefec() in unityplayer (0x000000000062f540)
  17 0x00000001806505dd EntryPoint+0xff26d404() in unityplayer (0x00000001808d1680)
  18 0x000000018079a717 EntryPoint+0xff3b753e() in unityplayer (0x0000000000000000)
  19 0x000000018079a7b3 EntryPoint+0xff3b75da() in unityplayer (0x0000000000000000)
  20 0x000000018079cc0c EntryPoint+0xff3b9a33() in unityplayer (0x0000000000000000)
  21 0x000000018054b89e EntryPoint+0xff1686c5() in unityplayer (0x0000000000000000)
  22 0x000000018054a5fa EntryPoint+0xff167421() in unityplayer (0x0000000000000000)
  23 0x000000018054e7d8 EntryPoint+0xff16b5ff() in unityplayer (0x0000000000000000)
  24 0x00000001805522db EntryPoint+0xff16f102() in unityplayer (0x0000000000000000)
  25 0x00000001400011f2 EntryPoint+0xffffff91() in vrchat (0x0000000000000000)
  26 0x000000007b62c9e9 EntryPoint+0xffffffffffffffff() in kernel32 (0x0000000000000000)
  27 0x000000007bc5e603 EntryPoint+0xffffffffffffffff() in ntdll (0x0000000000000000)
0x00000001e683474a EntryPoint+0xfffa88da in avprovideo: movq    (%rcx),%rax

As noted before, I will be returning AVPro to disabled in Proton in our next update, which will fix the crashing issues. The ability to play VP8+Vorbis in the Unity Player is interesting. Doing a system that could automatically transcode the videos into vp8+vorbis locally is a possibility, albeit there is a significant amount of code involved in handling it a proper manner, so I cannot guarantee a system like that being implemented in the short term.

I made something that live transcode videos to vp8 and it's taking 10 of my cores to reach 1x speed... seems somewhat unrealistic.

Would it be easier to, say, halve the resolution before transcoding? Doesn't have to be half, but gets the point across. Watching at all is a great stopgap between all and nothing.

Another option might be to try GPU accelerated transcoding. I'm sure ffmpeg has the option. It'll still kill some in game frames but won't be as bad as maxing out all CPU cores.

Keep in mind that any solution that isn't performant enough to run on the Steam Deck isn't worth considering, as far as I am concerned. Lowering resolution is definitely an option though, being able to watch the video at 480p or 360p is better than not at all.

I'd suggest making it configurable so Deckers can use whatever works, and pcs aren't so limited.

being able to watch the video at 480p or 360p is better than not at all.

Very true, and something I'd love to see. Plus, down the road, toggles could be made to take user input for target transcode sizes buried in a text file or launch flags somewhere, so the people who are technical enough to care about it would find it and use it but wouldn't hurt your average user. I've got a 5900x with 64gb of RAM which could chew on a video transcode fairly easily, but most people don't.

Keep in mind that any solution that isn't performant enough to run on the Steam Deck isn't worth considering, as far as I am concerned. Lowering resolution is definitely an option though, being able to watch the video at 480p or 360p is better than not at all.

That does make a lot of sense. As for YouTube links, doesn't ytdl also report webm formats as well, so that could be used without any transcoding on the local machine?

So I dug into the options of vp8 encode a little bit, and by setting -deadline realtime, performance is accept at 480p (30~40% of one core), although quality is significantly lowered. Hardware encoding isn't an option for me, looks like hardware vp8 encoding is only available on Intel platforms.

Also is the unity player capable of playing videos as it comes in? The loading time will be way too long if the entire video has to be transcoded first.

@DASPRiD most of the youtube videos do have webm format, but they are usually encoded with vp9+opus. I wasn't able to find a single video that's vp8+vorbis.

I made something that live transcode videos to vp8 and it's taking 10 of my cores to reach 1x speed... seems somewhat unrealistic.
. Hardware encoding isn't an option for me

That's surprising to me. You have an AMD or Intel processor and Nvidia or AMD gpu, I presume? Hardware realtime encoding and decoding for vp8/vp9 is built in to one of your devices, you're just not using the encoder at the moment I would imagine

OBS by default (and even oculus airlink and virtual desktop) all have access to those features, even on linux, and blender too, even android directly on the XR2 chip in the oculus quest (which is how it does streaming and recording) and your cell phone all have dedicated SoC's to accelerate encoding off software mode, and linux is the primary OS where the majority of these encode servers in major distribution services like Amazon's Twitch use. See if you can do accelerated recording in OBS, if you can, you should be able to do it with a piped function too.

Here's some documentation:

For Intel, it's called QSV. Here's how to use it with ffmpeg: https://www.intel.com/content/dam/www/public/emea/xe/en/documents/white-papers/quicksync-video-ffmpeg-install-valid.pdf

For AMD, it's called AME.
https://obsproject.com/forum/threads/experimental-ffmpeg-vaapi-plugin.61529/page-2 here's a thead on OBS with none other than gloriouseggroll discussing integration into OBS back in 2018.
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/tree/master/amf/public/samples/CPPSamples/SimpleEncoder here's a basic AMF standalone encoder you could play with.

For Nvidia, it's NVENC. https://docs.nvidia.com/video-technologies/video-codec-sdk/ffmpeg-with-nvidia-gpu/ here's the docs for that.

As of the end of 2021, the open source standard for Vulkan Video has been published by Khronos group, which is another neat step in the right direction.
https://www.khronos.org/blog/an-introduction-to-vulkan-video

Finally, there's another option that takes the burden off your system entirely - a dedicated hardware encoder/decoder box, with an internal OS. (usually tinylinux)

My favorite at the moment is the TBS2603au, a little box that can take any streaming service (rtmp,rtspt etc) and even NDI|HX2 and HDMI sources and straight up process it out to any server, even with modern standards like SRT And webrtc just like it was vrcdn or obs, all by itself.

So to use one of those, you would take the streamURL into it, have it spit out NDI ideally for quality, then run a local vp8 encode off the NDI in OBS or something like that.

The hardware encoder in this device to make it transcode is only H.265/H.264 as far as I know but there's a lot of other companies out there making similar products.

Also is the unity player capable of playing videos as it comes in? The loading time will be way too long if the entire video has to be transcoded first.

Usually that's done using something like DASH with vp8, or fragMP4. Basically you give the file a header, load it locally and as long as you can write and read faster than you're playing out with about a 5-10second or more "running start" you're good to go. I have done it with TS and MKV/vp8 on my Oculus quest 1 a couple years back even using Unity's native video player and pointing it at a local webserver resource.

@Lhun

That's surprising to me.

You'd be surprised. From my vainfo:

...
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
...

So decoding only for vp9. No mention of vp8 even, meaning it can't even decode vp8.

NVENC only does h264 or h265. Only Intel can do vp8 (or so I heard, I don't have an Intel CPU).

@Lhun

Usually that's done using something like DASH with vp8,

Thanks for the pointer, I will look into it.

So the Unity VideoPlayer doesn't do DASH / HLS, AVPro does. But as AVPro crashes the game when trying to play the webm, I am not holding my breath.

So the Unity VideoPlayer doesn't do DASH / HLS, AVPro does. But as AVPro crashes the game when trying to play the webm, I am not holding my breath.

Yes, typically it would be dash, my apologies. But we're looking at a workaround for avpro here.

Effectively you need to point the unity web player at a mkv/webm that it can read, with a long length. Something like _http://localhost:8888/video.mkv_

If you're writing to it faster then you're reading it (like, by giving yourself a seconds buffer) it'll continue along as you would expect. MKV/webm specifically supports resume, and doesn't use a MOOV header like mp4, so I suspect it should just work.
A good way to do a simple test would be to just open OBS and start recording to mkv and stick that in a local web server you can read with a hardcoded link like above.

I always recommend MKV it when you're recording in OBS too, because if it crashes, you don't have a junk unreadable file.

https://github.com/obsproject/obs-amd-encoder
Here's a version of OBS with AMD encoder support.

@Lhun So I have already tested and know that the Unity VideoPlayer (not AVPro) doesn't start playing the video until it's fully downloaded.

I am not sure I understand what you are suggesting and what the goal is.

If we take a step back, it looks like the issue is:

There are two problems that render both video players unusable in VRChat on Proton:

Lack of WMF codecs: can be manually solved on the user's end by adding the codecs themselves, albeit doing this is questionable from a licensing perspective, depending on the codecs installed

Proton incompatibility with loading videos from URLs: This cannot be worked around, Proton does not presently work with loading a video from a URL. Likely requires work on Valve's end to fix.

Looking into the codec support in Proton, I found that Proton's WMF implementation already looks to have a transcoding functionality built in: https://github.com/ValveSoftware/Proton/tree/proton_6.3/media-converter
Looks to me like it uses gstreamer (thus supports anything gstreamer supports?), so I'd assume it'd take the average mp4 video from Youtube without too much hassle. If Proton's WMF support can't handle a specific codec, it seems to me like the result should simply be the color bars pattern being displayed, which is not what currently happens (anywhere from "nothing" to "crashing.")

In that case, is the issue just that the WMF implementation within Proton can't handle videos from a URL? In that case, would it make sense to use yt-dlp to download the file to disk? Obviously that wouldn't necessarily fix watching livestreams, but it could work for fixed-length video sources.

Is it known/documented that Proton can't handle a web URL, but Windows can? The only comment I see about it on #1464 is from Jul 2, 2019, mentioning the missing implementation of mfplat:mfsourceresolver_CreateObjectFromURL. That was 2019, though, so it could have been implemented since.

My completely uninformed guess is to say that it wouldn't be a terribly hard thing to implement, although maybe it isn't a priority, since I don't know how many games outside of VRChat would even make use of such a functionality. I'd assume most ship the video files as part of the game itself.

I found that Proton's WMF implementation already looks to have a transcoding functionality built in: https://github.com/ValveSoftware/Proton/tree/proton_6.3/media-converter

A quick explanation of the situation: Proton can't ship with proprietary codecs, so it includes this media-converter, which submit the video file to Valve's server for transcoding, when the game wants to play a video. If the video isn't already transcoded and cached, a test pattern will be displayed. This only happens for local video files.

the media-converter is a gstreamer plugin, and Proton uses gstreamer to play videos.

mentioning the missing implementation of mfplat:mfsourceresolver_CreateObjectFromURL

It is still not implemented. If you try to play a youtube video in VRChat you will see it in the log. And I suspect you are right about it not being a priority. I can't comment on how hard would this be to implement.

I was hoping the unity videoplayer would support playing videos as it is coming in (i.e. HTTP progressive download), and since it doesn't use MF this would mean we would have usable solution. But alas. I guess it still is usable if you can accept waiting the equivalent of the length of the video for the video to play.

I am still curious why AVPro crashes, normally it just fails with MF errors.

I've done some experimenting with vp8 and dash:

ffmpeg -re -i somevideo.m4v -map 0:0 -c:v libvpx -keyint_min 24 -g 24 -b:v 2000k -f webm_chunk -header webm_live_video.hdr -chunk_start_index 1 webm_live_video_%d.chk

ffmpeg -f webm_dash_manifest -live 1 -i webm_live_video.hdr -c copy -map 0 -f webm_dash_manifest -live 1 -adaptation_sets "id=0,streams=0" -chunk_start_index 1 -chunk_duration_ms 1000 manifest.xml

With nginx, the commands are run together in /usr/share/nginx/html/webm_live

and then the command:
ffplay -allowed_extensions ALL http://localhost/webm_live/manifest.xml

plays a vp8 live stream of somevideo.m4v

I get some stuttering in video, changing keyint_min and -g seems to help with it. 24 is closest I got to smooth video (which almost matches the framerate of the source video I'm testing - 23.98).

There is no sound, but I imagine that will be a matter of splitting off two streams from the same file and mapping both of them instead of the one single map at the moment.

It uses a fair chunk of CPU, maybe 40% of each core. I haven't experimented yet with hardware acceleration.

I did try loading that URL in game. It didn't play, but reading above about the unity player not supporting dash I guess there isn't a way to test this in game unless AVPro starts working. It might also be necessary to generate an m3u file somehow before the URL will be accepted.

I followed this and this.

I wonder if it would be possible for VRChat developers to implement DASH support on top of the existing Unity VideoPlayer. IIUC on a high level the process would be parsing the manifest, then downloading and playing video chunks one by one?

I wonder if it would be possible for VRChat developers to implement DASH support on top of the existing Unity VideoPlayer. IIUC on a high level the process would be parsing the manifest, then downloading and playing video chunks one by one?

That's probably outside our wheelhouse, certainly outside mine.

A quick explanation of the situation: Proton can't ship with proprietary codecs, so it includes this media-converter, which submit the video file to Valve's server for transcoding, when the game wants to play a video. If the video isn't already transcoded and cached, a test pattern will be displayed. This only happens for local video files.

This seemed strange to me, so I dug into how this actually works a little, and I think it explains some potential problems.

It looks like what happens within the game process is (my best understanding):

• If it has support for a codec, it will play that video locally. If not, it will use the media converter utility.
• The mentioned media converter rust code will take the incoming audio and video from the media foundation APIs, hash it, and then use a Fossilize database to attempt to retrieve the pre-transcoded video file that is distributed via some part of Steam or a related service.
• If the matching piece of pre-transcoded content is not present, it will store the hash into the database with no transcoded content, and eventually that makes it back to Valve's servers, and gets transcoded, and then a new database (containing new transcoded video pieces) is eventually downloaded to all clients.

That sounds like it could be a huge headache if trying to play a video via web URL, which is possibly why it isn't implemented. For example, if it was implemented, every video that anyone ever tried to play using an unsupported codec (such as mp4/mpeg, which are rather common in my experience) in a VRChat world with a Proton user in the world would potentially be added to VRChat's transcoded video Fossilize database...

Looks like Proton has the 'base' and 'good' gstreamer plugins, and uses this system in place of the 'bad' and 'ugly' gstreamer plugins. Unfortunately, 'ugly' includes x264 and mpeg. Possibly fortunately, it includes libvpx for vp8 and vp9, so for some sources (like Youtube) that sounds like it may be helpful (maybe can just download in vp9 to disk somehow instead of streaming it?) For other formats (like mp4) it looks like some kind of transcoding would be required, unfortunately.

Since VP8 and VP9 are both open source and freely available (even look to be implemented in the same library which Unity uses-- libvpx) it's unfortunate that Unity hasn't enabled support for VP9. Since vp8 video seems to playback just fine, that seems like it'd allow at least certain sources (eg Youtube) to work without a huge hassle.

Since vp8 video seems to playback just fine, that seems like it'd allow at least certain sources (eg Youtube) to work without a huge hassle.

You still need MF URL playback support.

It isn't really a matter of enabled. It is a matter of building it in. VP9 actually works in Unity on Windows, relying on the Windows MF codec to do so. Doesn't work in Proton due to the issue of Windows MF and URL playback, something Unity's built in VP8 and Vorbis codecs sidestep entirely.

You still need MF URL playback support.

Not exactly. On Linux anyway, you could /etc/hosts the source url (after prebuffering to your HDD) a localhost url the transcoded vp8 MKV/webm so that unity plays it natively from your own disk or server.

I did try loading that URL in game. It didn't play, but reading above about the unity player not supporting dash I guess there isn't a way to test this in game unless AVPro starts working. It might also be necessary to generate an m3u file somehow before the URL will be accepted.

For this to work you can't do any url manifest based stuff: that's why AVPro is a solution VRCHat uses in the first place.
You CAN, however, play a direct on your local disk (or a remote, DIRECT url to the file!) vp8 encoded video file using the unity native video player in linux. Dash has a manifest too, so you can't use that either.

So, for it to "stream" (much like telling a torrent to download a movie in sequential mode, or how "webtorrent" video works), you can wait a few seconds and then play it from your "beginning" - whenever you started caching the livestream and saving it.
As long as you're downloading and writing to disk faster than you're playing and reading the file, it'll "stream".
The file will of course grow in size the longer the stream is. A clever person could cull the file now and then.

Here's a caveman lowtech way to do it yourself with VRCDN or a Twitch stream or whatever using OBS Studio (for acceleration possibly) or ffmpeg and a web server on linux:

Get a web server running on a machine, maybe make sure the httpd.conf only accepts connections from the local lan.
Make a vrchat world that points at http://127.0.0.1/somepath/somefilehere.mkv in the unity video player (the one that works for vp8)

Install https://github.com/xaymar/obs-streamfx/wiki
The reason why you need to install streamFX is because it includes the ffmpeg custom output plugin for OBS Studio. It supports ubuntu, at least.

Go into output, and make your recording settings like the attached picture but set the file path to /somepath/somefilehere.mkv so you're overwriting the one on your little webserver.
Alternately manually paste whatever the filename ends up being into the video player.

not like this, but maybe something like this.

Find your favorite vrcdn DJ 's rtmp url (or yt-dlp -g a twitch url)
Open OBS, and create a VLC projector SOURCE. Pop in the h3u8 url (or rtmp from vrcdn).
Hit "start recording" in obs.

Note: StreamFX's implementation of Matroska tends to fail on libvpx and libopus for but maybe not for you. This is really niche (it shouldn't be niche, but that's on the streamfx guys). Alternately you could also use VLC and save the network stream to a file with that too. Lots of options.

Wait a lilbit, stop recording, then load/reload the url. If you can reach the url, you should start to see the video.

You could also automate this with a vm or docker or something using ffmpeg with a script that's listening to your vrchat log. If it was standardized to a certain url in some way, you could probably make a button that made a local player for Linux users willing to go this far.

Have you gotten that working ingame?

This comment https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1020489259 suggests that it won't work as the native unity player waits until the video is fully downloaded

You've got to trick it into thinking it is. You could, for example, create an udon script that that emulates the behavior of a m3u8 and provide a looping playlist of files that self-replaces from an ffmpeg script.

Edit: actually, maybe not?

Does it really wait until fully downloaded? I know I've played videos gigabytes in size from a plain http .mp4 link that started playing immediately. It definitely didn't download the file completely first.

This is playing in Fancy Cat Theater which lets you select between stream and normal. I always pick "normal" which I think is the Unity player?

Edited to add:

This is the command I always use to make a video that can be played immediately from an http server -

ffmpeg -y -i input.mkv -preset slow -c:v libx264 -b:v 2500k -pass 1 -an -f mp4 /dev/null ; ffmpeg -y -i input.mkv -vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1" -map_chapters -1 -preset slow -c:v libx264 -b:v 2500k -pix_fmt yuv420p -pass 2 -ac 2 -c:a aac -b:a 192k output.mp4

Taking another look (at the VRC docs0, it seems that the normal player is the native unity one, while the stream player is AVPro, although AVPro can be used for 'normal' videos, I recall at least one world doing that.

The only documented limitation is that livestreams aren't supported in the normal player, which I suspect is a lack of DASH support

Maybe the video tested in https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1020489259 was not web optimised? (much like how MP4 needs to be encoded with -faststart), maybe Unity's native playback isn't able to play vp8 mid download, (but can using MF for MP4 playback), or it could be something else that triggered a full download?

@TheLastRar That's very possible, but I can't seem to find any information on whether the native player can play the media as it is being downloaded, or in what scenario will it try to download it first.

If anyone is able to make it play a webm/vp8/vorbis video as it is being downloaded, on Proton, I will be very interested to know the encoding settings.

Given that the built-in VP8 and Vorbis codecs are likely primarily meant for video clips and audio clips (which unity transocdes into vp8+vorbis and vorbis respectively). It is possible they aren't designed to be able to handle playing in progress like the windows codecs can.

It's helpful to know how this works in normal situations to devise solutions that are platform agnostic.
For example, this problem may become more relevant and pressing to @MehStrongBadMeh as the Valve Steam Deck is likely to be quite popular, will have this same issue.

I'm going to provide a small rundown here you can skip if you want for the benefit of people finding this thread down the line.

--startrant

AVPro Video is a unity package made by a company called RenderHeads that VRChat utilizes for playback of video in worlds. It's wrapped in a vrchat created custom script to utilize a subset of it's features with it's programming language Udon. It's specially not supported in Linux, but it is supported in Android and Apple, and UWP apps for Windows and VR.
https://www.renderheads.com/content/docs/AVProVideo/articles/requirements.html
https://github.com/RenderHeads/UnityPlugin-AVProVideo/releases

In addition, VRChat also supports via unity's "standard video player" via a wrapper for Udon. Unity's standard video player
itself usually transcodes all video in the project folder used in a scene to vp8+vorbis since it's low impact for 99% of target devices, since most have hardware decoders for the format for many years. VP8+Vorbis codecs are typically in an MKV container, and is comparable to mp4, but designed with the erweb in mind by Google and YouTube teams.

There's several streaming schema formats that AVPro supports, as well as providing accelerated playback of esoteric codecs and render modes like sbs 3d - IF your operating system or android SoC reports DECODING support for the codec is installed for it via a now standardized abstraction.

It's important to understand that Containers and Codecs are not the same thing. An "MP4" can contain h.264, x.265, h.265 (HEVC) video, or even vp8 if you're feeling spicy, but it's not "made for it". h.264 and HEVC are a LICENCED and not open source codec, and while you can play them on linux, it's not Libre. Similarly, MP4 can use all kinds of audio codecs, though most people use AAC.
MKV on the other hand is also a container: designed to be future proof, and can contain several media streams and formats (including h.264!). Webm is USUALLY (but not always) really just a renamed mkv, for example (this is important for later)

With the following package: https://github.com/Nevcairiel/LAVFilters/releases you can play pretty much all formats... in DirectShow. This a "legacy" "natively by the OS" function. Microsoft has decided to replace it in Windows with MediaFoundation step by step but both are still widely in use by various player software.

In Unity, hardware acceleration is made possible by OS native custom APIs (like mediafoundation), which vary from platform to platform. Unity’s video architecture hides these differences by providing a common UI and Scripting API in order to access these capabilities, in it's "native" player. In windows, by using LAVFilters, you can decide if you want to use hardware or software decoding for each.

Importantly, Unity is also capable of software-based video decoding, which is where this conversation has led us. This is ONLY possible with the VP8 video codec and Vorbis audio codec, and is useful for situations where a platform’s hardware decoding results in unwanted restrictions in terms of resolution, the presence of multiple audio tracks, or support of alpha channel (which is variably supported in hardware chips, like the video decoder on your GPU or Arm based system).

Software decoding is "purely on the cpu". It can be slow or "heavy", though not always. You certainly wouldn't want it on your main thread. Ideally, you shunt the rendering off to a chip that can do it with 0 load, which is one reason why AVPro is popular and why mediafoundation is so useful.

Unity's Native Video player as detailed here: https://docs.unity3d.com/2019.4/Documentation/Manual/Video.html Supports "URL Source". It really should say "path", but yeah. This is where things get weird.

For most platforms, H.264 (typically in a .mp4, .m4v, or .mov format) is the optimal supported video codec because it offers the best cross-platform compatibility (and hardware decoding).
Linux is the notable exception. For Linux, the optimal encoding is usually a .webm container with video tracks encoded using the VP8 codec, and audio encoded using the Vorbis codec.

Personally, I think VP8 works fantastically in windows, and I wish more focus was put on it. I would like to see vp8 and later AV1 completely take over as it would solve this problem once and for all, and Unity is starting work on WebRTC as well.

Setting the Video Player component source to URL can also be used to read videos from web sources via http:// and https://. In these cases, Unity performs the necessary pre-buffering and error management. - so, from https://, it should prebuffer webm, even on linux.

Of course, MKV (webm) is supported in mediafoundation too:
https://docs.microsoft.com/en-us/windows/win32/medfound/mkv-support

---endrant

Now, one issue here is that AVPro is configured to (usually) use mediafoundation, because it wouldn't make sense not to accelerate media.
RTMP streaming in AVPro uses DIRECTSHOW believe it or not, which is why it doesn't work on Android or PC in the default configuration. We used to workaround this by using sdk2 video players, and overwriting avpro to be directshow WITH OUR OWN COPY OF APVPRO ;)

RTSP on AVPro uses Exoplayer (a mediafoundation like abstraction) and is well supported for Android, but doesn't work on windows except in h.264 via a shunt to mfnetsrc.dll that AVpro made.

Unity's native video player does not support streaming schema at all, like HLS, RTSP, RTMP or DASH, but AVpro does.
Unity's native player does support buffered url playback of .webm vp8+vorbis on all os.

Clubs with live DJs in vrchat tend to use rtmp and rtspt via vrcdn, or HLS (M3u8) via youtube live and twitch. Believe it or not, some HLS streams (on youtube at least) are using VP8 codec. :)

It's not like Linux can't play those encapsulations in various ways: software like VLC and OBS can open that stream directly just fine. You could even open it up and pop the url in while playing VRChat in Linux to at least hear the music in clubs, and you can of course stream it in your browser.

So, this is a Unity+Avpro problem. Not a VRChat problem or Valve problem or even Linux problem.
in short, AVPro doesn't support Linux and Unity's player doesn't natively support HLS which you could stick a vp8 stream in.

VRCDN on the other hand does not currently support vp8+vorbis webm in HLS because that would require constant realtime transcoding and would be a nightmare in server costs, and we wouldn't be able to open it on Linux. It's nice for Android though. However, the quest 2 supports h.264 codecs natively anyway, so there's no pressure since everything else "just works" for users.

How AVPro gets HLS url in VRChat from twitch/yt/others is done by "yt-dlp.exe -g" and shunting that result to the player. It also gets direct files, like .mp4, for non-streaming video in that way to the unity native player, so support for it in Linux would be helpful sometimes if it didn't crash.

The only really viable format for "streaming" for all three targets therefore is webm vp8 + vorbis ... or a "shunt".

So what do we do?

You could try https://github.com/vbence/stream-m + OBS. Capture the incoming stream from vrcdn/twitch/whatever and point it to that server locally, and point your unity video player at it's webm url.
This might "justwork(tm)" with minimal delay with a long enough running start.
I can't test it personally today though. I'll see if I can find someone who wants to.

This could be built into a companion app for vrchat on linux or you could override the host url in yt-dl or something etc etc.

All that being said for actually well supported LIVE Streaming WebM is currently quite problematic even though it was designed for it. http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live-streaming-via-dash

As mentioned by others, DASH is the currently accepted way to do it because of tools like https://github.com/google/shaka-player/releases/tag/v3.3.1 from google.

Future Solutions for VP8/Dash/Live video done by devs?

1. VRChat could Add VLC for unity as an optional video player source on all platforms with an Udon wrapper and VRChat's SDK. https://code.videolan.org/videolan/vlc-unity . It could be hardcoded to use this by default in linux or something

2. Valve could make a video "shunt" to unity using some kind of local or remote shakaplayer implementation or something

3. Interestingly, there is one solution for WEBM-DASH in Unity, made just for vr, using mpd was tucked away that has been around since the days of google cardboard... https://github.com/googlevr/gvr-unity-sdk/releases
   But support would have to be programmed in house and adapted for Linux and Windows: since it uses Exoplayer/iOS only.

4. Since unity 2019.4 unity has newly added support for webrtc, something could be built around that.
   https://docs.unity3d.com/Packages/[email protected]/manual/videostreaming.html
   if VRChat added support for this package in a limited way, you could abstract to something like a virtual camera in Linux or steamVR plugin for video receiving purposes onto a texture.
   On Linux desktop, manually, you would create a render texture from your virtual camera stream that is pulling into OBS or something.

5. Valve or VRChat could make some kind of "spout-like" implementation that just takes the output of an external video player or app like ffplay and dumps it onto a render texture in unity, or something like that.

Note: I'm curious if someone with Linux could try BigscreenVR lately on Linux. If it works, there is a proven implementation right there since it's unity. I suspect it might not work at all for everything. https://github.com/ValveSoftware/Proton/issues/3676

I should note that including the VLC plugin is likely not an option due to including license-restricted codecs built-in. Paying for the licenses for those codecs is strictly off the table for the foreseeable future.

@Lhun thanks for the write-up! some points I noticed:

Capture the incoming stream from vrcdn/twitch/whatever and point it to that server locally, and point your unity video player at it's webm url. This might "justwork(tm)" with minimal delay with a long enough running start.

Interesting, if this works, which path way would it go through? Unity native player can't play video without downloading, as you've noted too in your comment. Can AVPro play this without using MF?

RTMP streaming in AVPro uses DIRECTSHOW believe it or not

Hmm, I wonder what's DirectShow support like in Proton, will VRChat be able to play a RTMP vp8 stream?

1. Since unity 2019.4 unity has newly added support for webrtc

Personally I think this solution probably has the most potential.

@yshui unity's documentation disagrees with that, but it could be wrong. It says that if you use https:// it should pre-buffer and then play. you would use something like https://localhost/server/stream.webm
Check that the .webm you're pointing at is set up with the "1 frame" timing in the format as per that server documentation linked in the /vbence/stream-m repo, perhaps it's just a formatting thing.

@Lhun I read the readme but can't find the setting you mentioned, and i can't find any other documentation in the repo. can you give me a pointer?

unity's documentation disagrees with that

yeah but my testing disagrees with that :) have you tried this yourself?

I have, we built a linux crossplatform video world many months ago. We didn't dig super deep into it, however. Sorry I can't do this interactively with you, I can only offer advice off the top of my head right now.

I'll say this, for live streaming WebM files (like with dash) the video and audio streams have to be non-muxed and chunked.
For VOD adaptive streaming you do Non-Chunked and Non-muxed.
You could try maybe:

ffmpeg -i ${SOURCE} -vcodec libvpx -vb 250k -keyint_min 150 -g 150 -acodec libvorbis -ab 128k ${FFMPEG_VIDEO}.webm

I have no idea how yours was encoded, and the documentation on Unity's implementation of webm vp8 software mode playback is nonexistant :( I imagine it would behave differently depending on how it was encoded.

Replying to https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1025057385

You said you have a working video world? could you give me the name of it so i can do some testing? Unless it's private

I've tried a few combinations of ffmpeg commands (including Lhun's) in Fancy Cat, but I can't get the player to play without downloading first either. It must be technically possible because playing the same file in Firefox it streams it fine, but not in the Unity player.

ffmpeg -i input.mkv -ss 0 -t 600 -c:v libvpx -b:v 3000k -keyint_min 150 -g 150 -c:a libvorbis -f webm -reserve_index_space 1048576 -cluster_size_limit 4096 -cluster_time_limit 1000 test.webm

ffmpeg -i input.mkv -ss 0 -t 600 -c:v libvpx -b:v 3000k -keyint_min 150 -g 150 -c:a libvorbis -f webm test.webm

ffmpeg -i input.mkv -ss 0 -t 600 -c:v libvpx -b:v 3000k -c:a libvorbis -f webm -reserve_index_space 1048576 -cluster_size_limit 4096 -cluster_time_limit 1000 test.webm

none of these combinations worked for me before downloading fully (verified with tcpdump).

Edited to add: I am using https for these tests too, from an https only remote server.

I should note that I do not find these hacks very interesting. Creating a super-complicated setup that requires a specially-designed world and specially-design servers serving content in a super specific way offers very little value to broader userbase. My focus is on methods that will allow existing content services to work in Proton with little to no work needed on the user's end, even if a drop in quality is required. Although I should also note that, on top of that, my even bigger focus is getting a Deck Verified designation, which the video players aren't actually a requirement for (been fixing gamepad input).

Not to be that guy, but the first solution is rarely the most elegant. Lets see what actually does work first, then we can focus on how to work around arbitrary parameters.

Worst case scenario the technically inclined gain a valuable tool, best case it leads to the elegant solution you're after.
If this discussion is going to upset the devs, any recommendations on where we should take it?

I totally understand where you're coming from here, and I wonder what Valve has done in the past.
Existing content sources is key. Personally, the solution with the most potential in my opinion is shuttling the video playback itself into a standalone video player executable (maybe one that comes with the vast majority of operating systems targeted, like some playback service on the steamdeck itself) and then it'll be running parallel to the client to take advantage of threading and and full support for hardware decoding and encoding.
Unity's webrtc would also allow shuttling of that video and audio to render textures and unity audio sources too, which would be nice.
Video content delivery for unity is a tricky egg to crack with very few people working on it for linux until valve.

Toying around today (i'm in the office on windows unfortunately), and here's something easy you might want to try @duckbytes
VLC has a server built into it that'll host things for you, and HTTP is possible with Webm direct streaming since 1.1.0 or something
But: you can attempt it to see if it just buffers forever (maybe!) or is treated as "downloaded" in vrchat and just plays the bit it had then stops (I suspect maybe it'll do this), or maybe it just works? Try setting the video player to "loop" if it just plays a short bit then stops, and in that case on the video player, maybe there's a solution with udon.

If this works at all you can ingest anything with vlc and output with webm on the same system with one binary since vlc (at least on windows) makes it's own little webserver.

I'll attach images with the steps.
What makes this curious to me is that VLC creates a webm with a "duration" of something like 403 hours, which is what I would expect for one encoded properly to run "buffered play" webm streaming. How chrome treats the file is interesting, basically it sees it as "downloaded" fully with a huge duration and no chapters, then starts playing it. You can test it directly in a browser if you would like first.

On this test I edited the stream to be 24fps and 320px wide just to see if I could get realtime encoding. It seems to be able to keep up with realtime (at least on this i7-7700) if you go really low resolution and 1000kbps bitrate. You CAN adjust vlc to not use every core on your system too if you want, but in this case for me on windows with these settings, leaving it unrestricted, it's using 4 cores in 66 threads, which averages about 26% of available cpu.

This is the VLC command line option it creates more or less:
:sout=#transcode{vcodec=VP80,vb=1000,fps=24,scale=Auto,width=320,acodec=vorb,ab=128,channels=2,samplerate=44100,scodec=none}:http{mux=webm,dst=:8080/stream.webm} :no-sout-all :sout-keep

last image is it running in a browser and vlc at the same time, if you were to try to to do a save-as on the webpage, it'll download basically forever at whatever bitrate you're encoding at, so chrome is just making a little handler page internally for it.

Thanks @Lhun for the idea. I gave it a try. The player continually downloads the stream and doesn't play it. I can see traffic flowing with tcpdump but it seems like it's waiting for the "download" to finish.

I had tried something similar before using ffmpeg, a named pipe and flask:

while true; do; ffmpeg -i video.m4v -c:v libvpx -c:a libvorbis -f webm pipe:1 > fifo.webm; done;

and the flask route:

from flask import Flask, request, Response

app = Flask(__name__)

@app.route("/test.webm", methods=['GET'])
def hello_world():
    fifo_read = open("fifo.webm", "rb")
    def generate():
        while True:
            data = fifo_read.read(1024)
            if not data:
                break
            yield data
    return app.response_class(generate(), mimetype="video/webm")

but got the same result. The data is flowing but the video never plays. It does stream properly in a browser.

One thing I noticed is that the client does two requests, one first for the header and one for the content. The only relevant thing in the header is the Content-Type which returns video/webm. I thought there was a chance the player was using this to decide what to do with the file, but if I pretend it's an mp4 with video/mp4 it doesn't make the player act any differently.

However none of these tests are using https, but I was also not successful in playing a statically hosted video by https from a remote server.

It really seems like we are beholden to Unity adding support to stream webms.

@duckbytes

I thought there was a chance the player was using this to decide what to do with the file, but if I pretend it's an mp4 with video/mp4 it doesn't make the player act any differently.

I've done the same thing. I didn't even set a Content-Type and it still plays fine.

Edit:
https://forum.unity.com/threads/vp8-vorbis-encoded-webm-files-from-url-do-not-prebuffer-and-play-via-url.1238488/
made a unity forum post about this. Not sure I'm ready to call it a bug before we get a second opinion.

So I wrote a little script to try and figure out what was going on here with url webms.
It's happening in the editor too, not just in game, even in windows.
The setup is just a standard unity video player not set to play on awake, with a url pointing at a vlc setup like the above.
This might be something to take to Unity and try to resolve, which would fix some things and provide an automated solution to shunt videos on linux or non-supported platforms via on the fly transcoding.

public class videoplayer : MonoBehaviour
{
    public VideoPlayer vid;
    void Start()
    {
       vid.Prepare();
    }
    void Update()
    {
        ulong stats = vid.frameCount;
        bool vidprepped;
        vidprepped = vid.isPrepared;

        if (vidprepped == true)
        {
            vid.Play();
        }
        if (vid.isPlaying == true)
        {
            float fr = vid.frameRate;
            Debug.Log(fr);
        }

        Debug.Log("Is the videoplayer prepped? "+vidprepped);
        Debug.Log("Detected video Length "+stats);

    }

You can see from the console log here that unity at least is actually saying the video is prepared and is actually "playing" (I wait to play until the videoplayer reports that it's prepped)
Unity is doing something really unusual here with these webms.

New in Proton 7.0:
"Added support for local decoding of H264 videos"

New in Proton 7.0: "Added support for local decoding of H264 videos"

I saw that too and gave it a try, but I couldn't get an h264 video to play.

I still don't fully understand the legalities behind not being able to play videos. I thought it was because it was patent encumbered but it looks like h264 support has been added anyway?

It's free to use for non-commercial. Unlike Youtube or Netflix Streaming video is not the primary business of Steam nor VRC.

Just want to chime in here that Neos is somewhat unity based and they use libvlc.

From the Proton 7 change log:

Added support for local decoding of H264 videos

This may be useful...

EDIT: My bad, browser wasn't showing new comments that had happened... Noted, refresh the page before commenting.

From the Proton 7 change log:

Added support for local decoding of H264 videos

This may be useful...

You dont say lol.

Can Neos stream youtube over proton already?

Neos has been able to stream everything including esoteric new codecs like AV1 due to leveraging the LibVLC system, probably and specifically this one: https://github.com/videolan/vlc-unity

New in Proton 7.0: "Added support for local decoding of H264 videos"

It would really help me out if someone could give specific steps of how to test a feature in this game that you think should benefit from h264 decoding :)

Edit: A log with GST_DEBUG set to "2,GST_CAPS:5" of a run where h264 video should be playing on 7.0-1 would go a long way too :) This variable is in user_settings.py, but you will have to change GST_CAPS to 5 to capture the necessary info.

@alasky17

Here is a gist that has a log output with the GST_DEBUG flag you suggested and ffprobe output of the video I'm testing:

https://gist.github.com/duckbytes/ce025ecb59eec8710af26382dbc68089

Hopefully this is what you meant. I set the launch options to PROTON_LOG=1 GST_DEBUG=2,GST_CAPS:5 %command% and copied the log file. I couldn't find any file called user_settings.py on my system.

The output is a bit huge but I grepped for the part that mentions the URL I was using to test with:

WindowsVideoMedia error 0x80070003 while reading https://ducky.ovh/test.mp4

Context: MFCreateSourceReaderFromURL
Error details: Path not found.

Track types:

GI: material 'Standard' does not have Meta pass, and could not find default material. Object 'lights' will not be affecting GI.
GI: material 'Standard' does not have Meta pass, and could not find default material. Object 'lights' will not be affecting GI.
GI: material 'Standard' does not have Meta pass, and could not find default material. Object 'lights' will not be affecting GI.
GI: material 'Standard' does not have Meta pass, and could not find default material. Object 'lights' will not be affecting GI.
WindowsVideoMedia error 0x80070003 while reading https://ducky.ovh/test.mp4

Context: MFCreateSourceReaderFromURL
Error details: Path not found.

Track types:

WindowsVideoMedia error 0x80070003 while reading https://ducky.ovh/test.mp4

Context: MFCreateSourceReaderFromURL
Error details: Path not found.

Track types:

WindowsVideoMedia error 0x80070003 while reading https://ducky.ovh/test.mp4

Context: MFCreateSourceReaderFromURL
Error details: Path not found.

The specific steps are:

• hit escape
• click Worlds
• search for Fancy Cat Theater
• click New Instance and Invite Only
• click Go
• go downstairs to the theater room
• select "normal player"
• enter the URL to an mp4 hosted on a web server
• hit enter

@duckbytes Thank you for the steps to repro! And sorry about the confusing user_settings.py instructions ... unfortunately that log did not have the variable I need. To get a log with user_settings.py, you just need to go into ~/.steam/steam/steamapps/common/Proton\ 7.0 and cp user_settings.sample.py user_settings.py first.. that is why the file name didn't show up on your computer yet - we ship it as user_settings.sample.py so it isn't on by default :) Then you can edit user_settings.py and change the GST_DEBUG line. I also have a simpler edit for user_settings.py -- if you uncomment out the verbose GST_DEBUG line, you can just change the first "4" to "5", and that should do the trick.

@alasky17 Ah no worries, I think I've got it now. I uncommented the verbose line like you suggested.

The gist link is updated with the new log.

From the open beta notes:

EXPERIMENTAL: Added the --enable-avpro-in-proton launch option, which will allow Proton users to re-enable AVPro for video playback. This may cause crashes!

For anyone who wants to experiment. It crashed VRChat for me when I tested it out.

Context: MFCreateSourceReaderFromURL
Error details: Path not found.

Is MFCreateSourceReaderFromURL still not fully implemented, even though h264 playing works for local files?

When I load Big Buck Bunny 1080p 60 fps, also on my own server so I can log the request, in Video Player Showroom (https://vrchat.com/home/world/wrld_985acb34-cc17-4b5a-85ae-04ade5195059), VRChat does a HEAD request from my server when loading in the Unity default player, and crashes immediately when using the AVPro based one. Other video players now crash as well when they didn't before, despite me never using --enable-avpro-in-proton. I am guessing the AVPro-based video players are now using the new code, but that it is not working properly.

The disabled AVPro code change is currently in the Open Beta, live presently still has it is enabled until the current open beta is released as live.

Does Whirligig work ? It's a media player I've used for a long time without much issue. Might help to narrow down.

As far as I can see, the MFCreateSourceReaderFromURL issue continues to be a blocker to properly useful working video players. As part of testing the H.264 Proton update, I tried making a test build where I set AVPro to use DirectShow instead of Media Foundation, but it still hit the MFCreateSourceReaderFromURL error (though it didn't crash, which is something).

Perhaps Valve may be more inclined to fix the MFCreateSourceReaderFromURL error now that H.264 incompatibility had been resolved.

For shits'n giggles I noticed https://vrchat.com/home/world/wrld_985acb34-cc17-4b5a-85ae-04ade5195059 is backed by cloudfucked's crapatcha.. wonder if that is what's causing vrchat to barf?

Regarding ducky.ovh, it's using Let's Encrypt. Their (LE) root CA expired last year, wonder if something is still looking at the old cert.

fwiw:

49573.701:0484:0488:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, L"ROOT": stub
49573.711:0484:0488:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_SERVICES, L"ROOT": stub
49573.711:0484:0488:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_USERS, L"ROOT": stub

49580.959:0518:051c:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, L"CA": stub
49580.959:0518:051c:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_SERVICES, L"CA": stub
49580.959:0518:051c:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_USERS, L"CA": stub

Besides the dispatch queue spam being annoying AF - There's another odd error in the gist above re Youtube?

@duckbytes Not including it here .. you REALLY should edit the gist to remove parts of the url .. search for googlevideo.

Without symbols of any kind those stack traces are basically useless to anyone but Valve sigh.

Some other errors from that gist

WARNING: Shader Unsupported: 'Hidden/PostProcessing/DeferredFog' - All passes removed
WARNING: Shader Did you use #pragma only_renderers and omit this platform?
Shader 'Particles/Standard Unlit': fallback shader 'VertexLit' not found
WARNING: Shader Unsupported: 'Hidden/PostProcessing/Bloom' - All passes removed
WARNING: Shader Did you use #pragma only_renderers and omit this platform?
WARNING: Shader Unsupported: 'Hidden/PostProcessing/DepthOfField' - All passes removed
ERROR: Shader Hidden/PostProcessing/FinalPass shader is not supported on this GPU (none of subshaders/fallbacks are suitable)
Shader 'Autodesk Interactive': fallback shader 'VertexLit' not found

etc

Regarding ducky.ovh, it's using Let's Encrypt. Their (LE) root CA expired last year, wonder if something is still looking at the old cert.

According to Firefox it expires on the 4th of May. I'm not sure why you're seeing an expired certificate.

I have hosted other videos successfully to Windows using that server over https (it only support https).

Not including it here .. you REALLY should edit the gist to remove parts of the url .. search for googlevideo.

I've removed the gist. Can you let me know what the problem is with those URLs? I don't understand the risk.

Edit: I just realised why, thanks for the heads up.

I didn't actually try to play a video from Google or YouTube, so I can only guess those URLs were generated in my home world which does try to play a music video, before I went to Fancy Cat.

According to Firefox it expires on the 4th of May. I'm not sure why you're seeing an expired certificate.

I think h1z1 might be talking about the DST Root CA X3 expiration where Let's Encrypt's root certificate (ISRG Root X1) was, when they started out, cross signed with that one. When an (older) device does not have the ISRG Root X1 in their trusted certificate store, they won't accept it as root CA.

Additionally, there was a bug with older OpenSSL versions, (1.0.x and below) that the certificates won't be accepted, even if ISRG Root X1 is trusted. This is an issue I still often see right now with apps that use deprecated OpenSSL versions.

It's not so much the root cert won't be trusted but the servers cert can't be verified because it can't determine the trust chain.

There's a LOT of broken software out there (and libraries), that refuse to allow exceptions either especially when hsts and pinning are used. Browsers are horrible for it. Even worse is the number of "things" that trust mozilla to maintain a global default trust store. Mozilla is .. wayyy too "woke" and I'll leave it at that (bet you didn't know you're trusting Honkong Post).

It's possibly related because not everything uses the system certificates.. CEF, python, firefox, curl etc, they all have different behaviours.

I would have to agree that the shader precaching is of essentially no use to VRChat. If Valve can disable shader precaching for VRChat, that would definitely be optimal.

3398.711:0130:01a8:trace:unwind:RtlCaptureStackBackTrace captured 25 frames
WindowsVideoMedia error 0x8007007b while reading https://rr3---sn-aigzrnld.googlevideo.com/videoplayback?[shortened this due to long url]

Context: MFCreateSourceReaderFromURL
Error details: Invalid name.

Track types:
 
(Filename:  Line: 3872)

3398.714:0130:018c:trace:unwind:RtlCaptureStackBackTrace (0, 128, 0000000076A988B0, 0000000000000000)

On VRChat [open-beta] with --enable-avpro-in-proton and Proton 7.0-1 on Arch/Linux 5.15. Tried to play a YouTube URL in a vrc video player, crashed and produced log above. Hopefully MFCreateSourceReaderFromURL will be worked on. I'd love to see working video players, it'd just be another blocker between me and migrating more stuff to linux.

@elliot5 that url unfortunately contains the format it was trying to use.

fwiw https://github.com/ValveSoftware/Proton/search?q=MFCreateSourceReaderFromURL&type=issues

Did some research into the Windows API. Maybe this is already common knowledge, but I am writing it down in case this saves somebody some time.

So MFCreateSourceReaderFromURL uses what's called "Scheme Handlers" to create media source objects (details here: https://docs.microsoft.com/en-us/windows/win32/medfound/scheme-handlers-and-byte-stream-handlers).

Scheme handlers are registered in the Windows registry, located at Software\Microsoft\Windows Media Foundation\SchemeHandlers\. If you look at wine/proton, you would only see a file: entry there, basically means proton can only handle file:// URLs.

If someone wants to add support for http:// and https://, they don't even have to touch wine/proton's codebase. They need to write a COM object that implements this interface, register the object's CLSID, and finally add an entry to Software\Microsoft\Windows Media Foundation\SchemeHandlers\. Maybe use curl if implementing HTTP is too much work.

This would be the first step. Maybe things would just work after this, or there could be more problems.

Update: Looks like on native Windows, the scheme handlers we want is located in mfnetsrc.dll and mfnetcore.dll. Some one should try copy those dlls from a Windows install and see if that helps. You would need to add these to the registry:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{37A61C8B-7F8E-4d08-B12B-248D73E9AB4F}]
@="Secure Http Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{37A61C8B-7F8E-4d08-B12B-248D73E9AB4F}\InprocServer32]
@="mfnetcore.dll"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation\SchemeHandlers\https:]
"{37A61C8B-7F8E-4d08-B12B-248D73E9AB4F}"="Secure Http Scheme Handler"

This should make https:// work. I might try this myself later.

Update2: Unfortunately didn't work, got this error:

wine: Call from 000000007B01390E to unimplemented function MFPlat.DLL.MFGetCallStackTracingWeakReference, aborting

I think Windows 7's mfplat.dll doesn't have MFGetCallStackTracingWeakReference either, maybe if someone find an old enough mfnetcore.dll, this could still work?

What's the purpose of that call and why would it be found in an older mfnetcore lib as opposed to a newer one?

@SpookySkeletons mfnetcore is using that call, so I was think maybe an older one wouldn't use that call.

No idea what that call does, it's not documented anywhere.

Think it's unrelated but triggered because it was trying to print a stacktrace? Only places I could find references were complaints after Micro$oft removed it.

FWIW this issue is now one of the few results on ddg and if you can scroll past the crap Github's search returns (seriously .. 40+ pages from the same retarded repo .. I triggered a ratelimit lockout by Github just trying) - you'll find no other references to it either.

mingw added it as a stub 15 months ago https://github.com/mirror/mingw-w64/commit/1f56b42e08fb513ad1bb3b0fbb12c64700966de3

Maybe I could add a stub to wine's mfplat.dll and see what happens? I am not familiar with wine's codebase though

Yeah just stub it and see if it works. It really just dies because it cant print a stacktrace??

EDIT: Does valve wine repo ship an mfplat.dll now to stub in?

https://github.com/ValveSoftware/wine/blob/proton_7.0/dlls/mfplat/mfplat.spec

Need a quick patch and build or already tried that? Will be home soon

EDIT: Spec patch and build process underway on my cruddy net, give it time

Sorry about the delay, I was missing some python packages on my Gentoo install and I wasn't too familiar with what was needed from pip.

Proton bin here: https://drive.google.com/file/d/10DP7tEFnXp5EuHkQewJi0FoKYM_7npYg/view?usp=sharing

Drop this in your wine directory, apply patch, and build if you don't trust my build.

commit 75816bab7d2a562f1c420be1970ad93a5a7a07e0
Author: BabbleBones <[email protected]>
Date:   Sun Mar 27 23:57:56 2022 -0400

    Stub MFGetCallStackTracingWeakReference in mfplat spec

diff --git a/dlls/mfplat/mfplat.spec b/dlls/mfplat/mfplat.spec
index 44d98a957e2..46340d9608d 100644
--- a/dlls/mfplat/mfplat.spec
+++ b/dlls/mfplat/mfplat.spec
@@ -3,6 +3,7 @@
 @ stub MFGetIoPortHandle
 @ stub MFGetPlatformVersion
 @ stub MFGetRandomNumber
+@ stub MFGetCallStackTracingWeakReference
 @ stub MFIsFeatureEnabled
 @ stub MFIsQueueThread
 @ stub MFPlatformBigEndian

Sorry about the delay, I was missing some python packages on my Gentoo install and I wasn't too familiar with what was needed from pip.

Does it make video players work?

Does it make video players work?

I'm not sure I dont have the time atm but if h1z1 is still up to test his configured prefix with this modded proton, please do.

A simple stub isn't enough, looks like the caller uses the return value of the function for something. Not sure which would be easier, reverse engineering or reimplementing the handler.

Update: returning NULL from the stub seems to get me past that point. Now it's missing mfplat.dll.MFGetConfigurationDWORD

Update2: there just seems to be a chain of unimplemented function there, i think this is not worth it.

After re-evaluating options, I think the easiest way to move forward is to reimplement the handler using either libavformat (see how mpv uses it, seems relatively simple), or gstreamer's httpsrc (wine is already using gstreamer, so this is a plus). Should save a lot of time comparing to using libcurl directly.

gstreamer implementation would be much easier to upstream but given the circumstances anything would be good! Do you have any inclination or time to work this?

I should note that, if you manage to make the Unity Video player work but the AVPro Stream Player still doesn't, let me know. There is an alternate media api mode I can set AVPro to that might help in that scenario (presently neither mode works without those scene handlers).

It may be better to preemptively add a startup flag for API selection given the length of your build cycle beside the speed of proton development, can always be reverted later if confirmed functional.
P.S. A deep thanks for strongly engaging on the git here before even the allure of the steam deck, cant wait for the day we can plat on protondb. I just wish I had more dev skills to attempt what yshui is sketching out myself

Seriously, just to echo what Spooky said, it's awesome to have involvement from the devs themselves like this. Thanks for setting the bar!

It may be better to preemptively add a startup flag for API selection given the length of your build cycle beside the speed of proton development, can always be reverted later if confirmed functional.

I'd rather not if it proves not necessary. Having to run another startup flag through the QA process is quite a pain, (then having to go through it again when I inevitably remove it) while making an internal test build is easy.

I should also note that VRChat needs the http: https: rtsp: and rtspt: scene handlers for the video players
(latter two for streaming specifically).

Hey, just want to say I am making some progress on this. Just in case someone else also picks this up and ended up doing duplicated work.

Can you expand on your progress?

Hmm I don't know why I am getting an "[Invalid URL] parsing error?" from the player. I have --enable-avpro-in-proton, and looking in the log I don't think it even called MFCreateSourceReaderFromURL yet.

Update: OK, I had to delete and recreate the proton prefix so the registry entries are added. Now the video player is stuck loading the video. Still nothing useful in the logs...

BTW things seem to work outside VRChat. I am using this example: https://docs.microsoft.com/en-us/windows/win32/medfound/how-to-play-unprotected-media-files

This example uses video rendering feature (EVR) that's not implemented yet in wine, so video doesn't show. But audio players fine so I think my code works.

What happens when you try to use the standard unity player in vrchat, instead of the AVPro Stream player?

I will link my patches here: https://gist.github.com/yshui/6625f4537dd9a7d0b28a59a9a3a79967

It doesn't work for VRChat, but feel free to test it out. It however fixed the intro video issue here: #5195, which is at least something.

@yshui Did you test with the Unity Video Player, or only AVPro?

@MehStrongBadMeh Sorry! I forgot to test the Unity Player. I just did that, and it actually works!

... to an extent at least, the video plays, but it is distorted. I will upload a screen capture.

https://user-images.githubusercontent.com/366851/162644461-1bd895b7-ec2e-4f7f-b67d-4f8812f6c25b.mp4

@yshui How's the sound playback? Does it work?

@roryyamm yes.

@yshui If you can send me a pre-compiled build, that would save me a lot of time. I want to try running through playing with various settings on our Unity and AVPro players while using your build.

@MehStrongBadMeh The build is about 1GB, and is compiled against libraries on my system, so I am not certain if it will work. Is there any ArchLinux users on the VRChat team? It's relatively easy to make a build.

Observations on the distortion:

1. a seam running from top left to bottom right. Maybe the video has an unexpected pitch (more pixels in every row than expected)?
2. another seam in the middle, which doesn't seem to break the video?
3. different planes of the video appears to be separated, distorted differently.

I think either the game took the video frame and did something weird with it, or maybe there is some postprocessing pipeline on wine side that did something wrong.

The issue reminds me of the analog/film days, there's a timing mismatch and your screen is updating progressively but not in sync with the frames of the video. Explains the half/half frames and the top to bottom skew.

@yshui if it seems like a sane change, please submit to wine-staging. This will make it much more accessible for testing.

@jp-bennett I tried wine upstream, but was told this is not how they would like it to be implemented. So wine-staging probably won't take it.

I will try to get it into Valve's fork of wine instead. But I'd like to do a bit more investigation first.

Ill see if I can produce another public build with your patch.
The scene issue is wacky! how's wined3d look?

Seems to be a black and white layer, with a color layer, sliced at slightly different angles.

Do the MS docs reference anything that splits chroma or applies a layer rotation? Post the original video container to dissect.

@SpookySkeletons yeah, basically the Y plane and UV plane are separated and have different distortions. I wonder if the pixel format is correct.

@SpookySkeletons yeah, basically the Y plane and UV plane are separated and have different distortions. I wonder if the pixel format is correct.

Haha, we had this exact issue with space engineers png heightmaps. The 10bit formatting was incorrect turning the planets into colossus spike maps. Might be another one.
Wheres the format listings at?

I should note that we aren't doing anything particularly special when it comes to the Unity Video player. It renders to material like normal and works essentially works like a vanilla Unity Video Component.

Once I get a chance to compile and try out the build. I will test out the different modes for the AVPro player. If I get it operating, I wonder if it will have the same render issues.

I gave the patches a try and got some weirdness and some MF errors. No working videos.

In Fancy Cat (Unity player) I get Error details: Path not found and in Udon Theater (AVPro player) Error details: Invalid name

Some of the output is visible in the screenshots.

Also very strange is that I could see random textures appearing in places depending on the angle I was looking at it.

In Fancy Cat I could see textures from the world where the video player should be. In Udon Theater I could see textures from my own avatar on the wall at spawn. There was also missing text in some parts of the UI.

I used wine-tkg to build and patch wine.

@duckbytes try delete your proton prefix and recreate it.

I want to use renderdoc on VRChat, but I am not sure if there will be intellectual property issues...

Trying to see if results will be different with wined3d, but VRChat doesn't even start with wined3d. :cry:

Update: switched to d3d12 and it looks the same. so likely the problem is at somewhere before the image reaches d3d. (or could it be inside dxgi? i am not familiar with this stuff).

I created a Unity project which has a single plane with a video player component attached. And I was able to reproduce the problem there too. I thought this would be something I can 100% legally attach renderdoc to, but alas renderdoc crashes it.

Interestingly the crash happens with Proton 7.0 and Proton-tkg, but Proton Experimental is fine. So I guess I should get this patch into Proton Experimental first, which should hopefully make further investigation easier.

Caught your merge request. Early build, if valve isn't gonna be up late, incoming; If my net is faster than they are.

Edit:
https://drive.google.com/file/d/1m-PZwhclExuUF3tFJeaMKS-u7X4G4tL3/view?usp=sharing
Download here but please note, this binary did not seem to work for me. The wine has all three patches from the MR included, latest experimental.

@SpookySkeletons does it crash? does it not play the videos? did you start from a fresh proton prefix?

Edit: I might have made some mistakes porting to proton experimental's version of wine:

03d0:warn:mfplat:media_source_init_from_parser Failed to construct MFMediaSource, hr 0x80004005.

allow me some time to fix it.

Edit2: proton's gstreamer didn't come with the httpsrc element needed.

Yep fresh prefix. Waiting for fix.

I think my code is fine. it's just proton's gstreamer missing some plugins.

I got

winegstreamer warning: uridecodebin9: No decoder available for type 'video/x-h264...

I thought proton is not shipping the h264 decoder now?

@SpookySkeletons I needed to enable http support in gstreamer while building Proton, I will create a branch of proton you should be able to build from. Or just stick to proton-tkg?

Looks different in Proton Experimental:

https://user-images.githubusercontent.com/366851/163185089-6a23b564-8ab3-41bc-a2d0-bf8940a15ef8.mp4

Not on an arch system but could probably just chroot one if necessary.
Used GE with your forked wine submodule. Send a gstreamer patch for what tree(s) need it and ill pullto enable on my GE build.

EDIT: Realized I applied this patch to my stock Proton experimental tree instead of GE so as you say its missing the gstreamer checkboxes.

@SpookySkeletons @MehStrongBadMeh Here is a proton build you can test with: https://drive.google.com/file/d/1M-h_OT5DkDLdD5nNYB9r34pKtCbJ8JjB/view?usp=sharing

Here is my hack on top of Proton to get http & h264 support: https://github.com/yshui/Proton/tree/urlhack

@SpookySkeletons @MehStrongBadMeh Here is a proton build you can test with: https://drive.google.com/file/d/1M-h_OT5DkDLdD5nNYB9r34pKtCbJ8JjB/view?usp=sharing

Here is my hack on top of Proton to get http & h264 support: https://github.com/yshui/Proton/tree/urlhack

Cool, I should be able to squeeze in a chance to test out some AVPro modes to see if that can be made operational. If so, I may be able to put out a beta that is just live vrchat with those tweaks. As for rendering issues currently being seen in the Unity player, I doubt there is anything I can on my end for that. Looks like that needs to be fixed Proton-side.

@MehStrongBadMeh

Looks like that needs to be fixed Proton-side.

Yeah, most likely. The issue I saw with proton-tkg I am not sure, but the rendering issue seen with Proton Experimental definitely looks like pixel format mismatch. I am trying to investigate but don't hold your breath.

Any likely candidates? Where do they keep the pixel formats? Can we play video with varying format to see what happens?

With information from #4433, if I set WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1, it reverts to the type of distortion seen with 7.0.

This hack entirely fixes the distortion?

@SpookySkeletons @MehStrongBadMeh Here is a proton build you can test with: https://drive.google.com/file/d/1M-h_OT5DkDLdD5nNYB9r34pKtCbJ8JjB/view?usp=sharing

Here is my hack on top of Proton to get http & h264 support: https://github.com/yshui/Proton/tree/urlhack

I tried using the google drive build, but I couldn't get it to play h264 videos - only webms from 4chan. I'm running Debian, however, so that might be the issue. Will compiling your github version work better?

@roryyamm Can you run with GST_DEBUG=5 WINEDEBUG=+mfplat and upload the proton log file? And what h264 video were you trying to play?

@yshui Here we go. This is using the Unity player.
steam-438100.log
The part you want starts at line 1656.

01a0:trace:mfplat:resolver_create_scheme_handler L"https", 0x1, 00000000782EF4A0.

The handler should be "https:", it was "https" before part of my patch fixed it. So looks like you are not running a proton build with my patch. @roryyamm

01a0:trace:mfplat:resolver_create_scheme_handler L"https", 0x1, 00000000782EF4A0.

The handler should be "https:", it was "https" before part of my patch fixed it. So looks like you are not running a proton build with my patch. @roryyamm

Ah. So do I have to compile a new build or simply patch on top of the GDrive build?

Can confirm that the GDrive build didn't work for me either.

Hmm, weird, let me verify I did upload the right thing. Or maybe you can build from my Proton repo? You just need to install docker and run make redist. @MehStrongBadMeh

It's weird, the gdrive build works for me... @MehStrongBadMeh can you also upload your proton log with GST_DEBUG=5 WINEDEBUG=+mfplat ? Did you make sure to delete your old proton prefix?

@yshui
using:
your google drive build
the same vrchat world you showed "working"
the same URL
in-world player selection of unity 720p as well as avpro 480p
launch options:
PROTON_LOG=1 GST_DEBUG=5 WINEDEBUG=+mfplat %command% --enable-avpro-in-proton

results: unity fails without crashing vrchat, ingame text mentions a failure to load; selecting avpro 480p fails and crashes vrchat

resolver_create_scheme_handler seems to indicate the patch working as expected for me
my log contains both attempts at playing the url with unity, and with avpro
steam-438100.log

@RestlessCavy Looks like the code is working correctly from your log file, but:

0:00:00.113072827 771175 0x7fbde8089c00 INFO GST_ERROR_SYSTEM gstelement.c:2261:gst_element_message_full_with_details:<typefindelement0> posted error message: Stream doesn't contain enough data.

So maybe a network problem?

And yes, avpro player doesn't work.

Finally had a chance to make the log, still doesn't work in the Unity Player. Won't be attempting any work with the AVPro player until it is working (at least partially) on the Unity Player
steam-438100.zip

@MehStrongBadMeh

0:00:00.168157306 17647 0x7f1e9807d800 WARN souphttpsrc gstsouphttpsrc.c:1382:gst_soup_http_src_parse_status: error: Secure connection setup failed.
0:00:00.168165236 17647 0x7f1e9807d800 WARN souphttpsrc gstsouphttpsrc.c:1382:gst_soup_http_src_parse_status: error: TLS/SSL support not available; install glib-networking (6), URL: ..., Redirect to: (NULL)

Interesting, I could swear I tested https URIs. In the meantime can you test something that's http only? And can you also try installing glib-networking?

I noticed the same "tls/ssl support not available" in my log, but I already have glib-networking installed, at least through apt.
I also tested the same trailer.mp4 but through a local http server (which needs to support range requests) and got the same format errors yshui showed before; regardless it would seem http works for me.

@MehStrongBadMeh

0:00:00.168157306 17647 0x7f1e9807d800 WARN souphttpsrc gstsouphttpsrc.c:1382:gst_soup_http_src_parse_status: error: Secure connection setup failed.
0:00:00.168165236 17647 0x7f1e9807d800 WARN souphttpsrc gstsouphttpsrc.c:1382:gst_soup_http_src_parse_status: error: TLS/SSL support not available; install glib-networking (6), URL: ..., Redirect to: (NULL)

Interesting, I could swear I tested https URIs. In the meantime can you test something that's http only? And can you also try installing glib-networking?

I could have sworn there was a hard requirement to use HTTPS now at least in avpro.
Remember: the Unity native player is EXTREMELY limited in the formats it supports without mediafoundations support Unity's native "go to" transcode format is vp8.
On linux, literally the only formats that work in the unity player (And i've had this working on live in the past) is webm/mkv vp8 encoded (and it's very specific to your linux build!) and sometimes good ol' mpeg 2, but this is proton, doing weird mediafoundation-ey bridgey things.

Would it be helpful to give you all a bunch of hosted urls with https on a hardcoded and reliable server, where the video content is encoded in a variety of ways: clearly described in the video data and encoded in ways that I believe should work based on which codec you want to try?

Also I'll note that the url in your logs here @MehStrongBadMeh is of course locked to the IP, due to the gsturi.c, gstsouphttpsrc.c,

And also it appears that you are indeed missing glib-networking here. which for this method is necessary.

The urls are unusually long and are locked to various user specific ips on googlevideo.com (likely due to yt-dlp) and this is a monkey wrench that we should be avoiding while we test, because it's entirely unpredictable when it's wrapped in proton.

I could have sworn there was a hard requirement to use HTTPS now at least in avpro.

There is no such thing, please cease spreading misinformation in this thread.

Remember: the Unity native player is EXTREMELY limited in the formats it supports without mediafoundations support Unity's native "go to" transcode format is vp8.

We know that, that's the entire point of what @yshui and the rest of us have been working on. Valve added H.264 codecs to proton and we're trying to take advantage of them.

Would it be helpful to give you all a bunch of hosted urls with https on a hardcoded and reliable server, where the video content is encoded in a variety of ways: clearly described in the video data and encoded in ways that I believe should work based on which codec you want to try?

No, because we are all perfectly capable of setting up those servers ourselves. The test request wasn't to test on a hardcoded url. And we successfully discovered an issue via this testing in the current implementation that prevents https urls from working. The fact that you can't view that url yourself is irrelevant.

Actually, I was right, there is a hard requirement for https. It was just on android. Since I build cross platform compatible stuff, it's just become my headcannon that it's always required. (and imho it should be your headcannon too)

excessively long uri strings with characters that often need to be escaped in various libraries are generally not conducive to an effective test of something so unusual as this when you have an application that thinks it's on one operating system architecture trying to get data from another. Use a short url. Why you gotta be so sharp strongbad, we're all trying to help here.

I don't mean to be rude here but I've been doing cross platform media codec playback professionally for government agencies and major international corporations on linux/windows/android for a decade and a half professionally, iterating across operating systems since windows XP and android 2.0 on a unique, award winning SaaS platform from the days when you needed to run your own red5 and cassandra servers.

You should probably enable glib-networking.

@yshui I can confirm that your proton build works with the Unity Player on http videos, with the previously mentioned rendering issue. glib-networking is pre-installed on Steam Deck. I tried compiling builds of VRChat that set AVPro to other video apis, but none of them made AVPro work, as it seems they only implemented H.264 via MediaFoundation. We are going to be updating to a newer version of AVPro soon, so that might help (apparently, it will at least stop the crashing in Proton)

@MehStrongBadMeh the https issue is weird because it worked out of the box for me. And Steam Deck would be using Arch Linux as well, so it would be the same environment as my tests. I wonder what exactly is missing here.

@MehStrongBadMeh does https work outside Proton? e.g. does this command work:

gst-launch-1.0 -v souphttpsrc location=https://google.com '!' filesink location=/tmp/google.html

This command should download the Google homepage and save it at /tmp/google.html. You need to install gstreamer if gst-launch-1.0 is not found.

@yshui
It barks out the following:

WARNING: erroneous pipeline: no element "souphttpsrc"

It appears that gst-plugins-good is not installed on Steam Deck.

You cannot install any packages via pacman to Steam Deck in a persistent manner. Thus, the only options here are to either convince Valve to start including it in SteamOS or to find a different way to access https content.

@kisak-valve That is good to know. Is there a way to set up test Proton builds to run inside the Steam Linux Runtime - Soldier environment? In addition, is there any way VRChat can work with the Proton and/or Steam Runtime Container devs on adding the capabilities needed to make web video players work? We are interested in bringing VRChat on Proton up to full feature parity with running on native Windows, the video players are the last piece of the puzzle to do that.

@kisak-valve BTW, the review of the PR to Proton: https://github.com/ValveSoftware/wine/pull/142, seem to have staled. Maybe @zfigura is currently occupied with other work and don't have time. Can you help me find other people who would be interested to give this PR a look?

Latest update to VRChat (IK 2.0, 2022.2.1 update) seems to have broken VR support for SteamVR (build linux_1.14), since it's no longer compatible with Proton 5.13-6, which was previously the latest version that supported it.

I can play it on the current/beta build of SteamVR (Using Proton builds 6.3 or 7.0), but that means having the flickering overlay issues (as described here: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/395)

For me VRChat has suddenly started to crash with:

380158.677:0144:0288:err:virtual:alloc_area_in_reserved_or_between_callback Could not map in reserved area.
../src-wine/dlls/ntdll/unix/virtual.c:1442: create_view: Assertion `!((UINT_PTR)base & page_mask)' failed.

Tested Experimental and 7.0-2. I don't know what changed, first few days after the 2022.2.1 update there was no such problem.

Update: removing VRChat's compdata folder and start over made the crash go away.

Within the past few days, it appears that VRChat has a seemingly random, but rare, chance of crashing every time it makes a BestHTTP request. This can be anything from loading the "Worlds" tab, "Social" tab, requesting world info upon viewing a player's profile, or simply loading the avatar/image of a player. Tested with Proton Experimental and 7.0-3rc, both on a clean prefix.

Here's the vrchat log at the time of a crash:

2022.06.07 12:58:56 Error      -  Caught SystemException in UpdateDelegator Job: Thread creation failed.
  at System.Threading.Thread.Start (System.Threading.StackCrawlMark& stackMark) [0x00000] in <00000000000000000000000000000000>:0 
  at System.Threading.Thread.Start () [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPManager.SendRequestImpl (BestHTTP.HTTPRequest request) [0x00000] in <00000000000000000000000000000000>:0 
  at BestHTTP.HTTPManager.SendRequest (BestHTTP.HTTPRequest request) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Core.API+<>c__DisplayClass36_0.<SendRequestInternal>g__FinishSendingRequest|0 () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Core.API.SendRequestInternal (System.String endpoint, BestHTTP.HTTPMethods method, VRC.Core.ApiContainer responseContainer, System.Collections.Generic.IReadOnlyDictionary`2[TKey,TValue] requestParams, System.Boolean authenticationRequired, System.Boolean disableCache, System.Single cacheLifetime, System.Int32 retryCount, VRC.Core.API+CredentialsBundle credentials, BestHTTP.Forms.HTTPFormBase formData) [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Core.API+<>c__DisplayClass35_0.<SendRequest>b__0 () [0x00000] in <00000000000000000000000000000000>:0 
  at OVR.OpenVR.IVRSystem+_AcknowledgeQuit_Exiting.Invoke () [0x00000] in <00000000000000000000000000000000>:0 
  at VRC.Core.UpdateDelegator.Update () [0x00000] in <00000000000000000000000000000000>:0

UPDATE: After crashing a bit more in different ways and digging through some more logs, I figured out that I just had to increase my hard open file limit in /etc/security/limits.conf by adding the line * hard nofile 1048576
If you use a systemd distro (I was not), you'll have to also change that in sysctl.

I've got an intermittent issue where the game will crash a minute or three after startup. If I watch radeontop after launching the game, it will continuously eat VRAM until it crashes. Restarting the game once or twice usually fixes the issue. Seems similar to the issue that used to effect the game a while back (which required removing the lipsync dll to fix).

This has been an issue for a while, but I haven't been able to find any particular cause for it. There might be some correlation between > 4096MB of VRAM being used at launch (as reported by radeontop) and the crash, but I can't say for certain.

VRAM is not reported to be full when the game crashes, so I don't believe that is the source of the crash.

I have the same issue, and could not find a fix other than having a script detect it and restart steamvr when it crashes.

It seems to be quite consistent with timing, usually at the 2 minute mark for me.

The proton debug logs are hard to navigate since it generates almost 10MB of logs in the 2 minutes until the crash, but looking at the end of them it does seem to be memory related since it fails to allocate a bunch of times then crashes.

anyone know how to fix these errors please help
usr_84ad354b-5ff1-48e8-b5f6-33f49d783bb9 is not an owner of usr_ef31bbcd-fe34-4354-a6d7-ea83d0820433
UnityEngine.Debug:LogErrorFormat (string,object[])
VRCSDK2.RuntimeWorldCreation:SetupUI (bool,bool) (at Assets/VRCSDK/Dependencies/VRChat/Scripts/RuntimeWorldCreation.cs:293)
VRCSDK2.RuntimeWorldCreation/<>c__DisplayClass38_0:b__1 (System.Collections.Generic.Dictionary`2<string, object>) (at Assets/VRCSDK/Dependencies/VRChat/Scripts/RuntimeWorldCreation.cs:197)
VRC.Core.APIUser/<>c__DisplayClass375_0:b__0 (VRC.Core.ApiContainer)
VRC.Core.APIResponseHandler:HandleResponse (int,BestHTTP.HTTPRequest,BestHTTP.HTTPResponse,VRC.Core.ApiContainer,int,bool)
VRC.Core.API/<>c__DisplayClass35_3:b__4 (BestHTTP.HTTPRequest,BestHTTP.HTTPResponse)
BestHTTP.HTTPRequest:CallCallback ()
BestHTTP.ConnectionBase:HandleCallback ()
BestHTTP.HTTPManager:OnUpdate ()
BestHTTP.HTTPUpdateDelegator:Update ()

I've tried with the above mentioned methods of doing WINEDEBUG=+mfplat and --enable-avpro-in-proton along with adding mfplat native DLL, but the result is that Unity crashes.. I had also tried this https://github.com/Natsumi-sama/VRChat-YouTube-dl-stub to self-build a stub for VRChat with YouTube-DL to cache the stream URL directing with a PHP script to a local server, but the result ends up being Access Denied and URL Encode Error.

https://github.com/ValveSoftware/wine/pull/142#issuecomment-1167303650
@MehStrongBadMeh The unity video player now work but you need to use (AVPro still crash)

Replying to https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1168874788

Have you checked this yourself?

Checking this with an MP4 catbox link and the standard Unity player, removing all possible ways for Youtube-DL to mess with things, produces this result:

WindowsVideoMedia error 0x80070003 while reading https://files.catbox.moe/frp5e4.mp4

Context: MFCreateSourceReaderFromURL
Error details: Path not found.

Track types:
 
(Filename:  Line: 3872)

Have you checked this yourself?

Of course

World: https://vrchat.com/home/launch?worldId=wrld_fac11e5f-1c73-4436-8936-a70b80961c5a
Video: https://youtu.be/QRqY_20ti9A

Checking this with an MP4 catbox link and the standard Unity player, removing all possible ways for Youtube-DL to mess with things, produces this result:

Video: https://files.catbox.moe/frp5e4.mp4

Trying with that video produces this result:

WindowsVideoMedia error 0x8007007b while reading https://rr1---sn-jp3uxa-tt1s.googlevideo.com/videoplayback?expire=1656465230&ei=7lK7YtLWJLST2LYPjIuQsAE&ip=135.0.230.68&id=o-ADWd5f9TVIef3GUGhWCpGaEejpR_qZU2294rIQA0mOIk&itag=22&source=youtube&requiressl=yes&mh=aA&mm=31%2C29&mn=sn-jp3uxa-tt1s%2Csn-cxaaj5o5q5-t0ad&ms=au%2Crdu&mv=m&mvi=1&pl=24&initcwndbps=1193750&vprv=1&mime=video%2Fmp4&cnr=14&ratebypass=yes&dur=83.220&lmt=1630167075337849&mt=1656443132&fvip=1&fexp=24001373%2C24007246&c=ANDROID&txp=5311224&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Ccnr%2Cratebypass%2Cdur%2Clmt&sig=AOq0QJ8wRQIgbjKzULkrGZCmsRI0_pJS_ZW702kXoLpFTybJ7hNQnbkCIQD2ce6OiNicvGGscuJVEZZveI216c7HGevxeQLn2JssCA%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRQIhANzfDiNQouJ5z4KnSECOPfC7GyYt-ASmKM0wVYek4dC3AiBUMpdp_ZtHxvEsfb39YLgm_rTnZinEiSUCM0T5q-j36Q%3D%3D

Context: MFCreateSourceReaderFromURL
Error details: Invalid name.

Track types:
 
(Filename:  Line: 3872)

Trying with another video (https://www.youtube.com/watch?v=AqChXQj-w5I) produces this result:

WindowsVideoMedia error 0x8007007b while reading https://rr1---sn-jp3uxa-tt1s.googlevideo.com/videoplayback?expire=1656465325&ei=TFO7YurkN46d2_gP6NChyAc&ip=135.0.230.68&id=o-APWt9elNN_aas_4HnW_Am-ay9qg2bi9OCTNfxp18nIH2&itag=22&source=youtube&requiressl=yes&mh=aA&mm=31%2C29&mn=sn-jp3uxa-tt1s%2Csn-cxaaj5o5q5-t0ad&ms=au%2Crdu&mv=m&mvi=1&pcm2cms=yes&pl=24&initcwndbps=1236250&vprv=1&mime=video%2Fmp4&cnr=14&ratebypass=yes&dur=83.220&lmt=1630167075337849&mt=1656443362&fvip=1&fexp=24001373%2C24007246&c=ANDROID&txp=5311224&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Ccnr%2Cratebypass%2Cdur%2Clmt&sig=AOq0QJ8wRgIhANrUiKvbhisHuOCrS0BMH9n46R4eAN7OnQlqsO6_LVAXAiEApeWYNfqioum89bW7v-KOa3UYEp-DEcK1-Z3prFCiCJU%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpcm2cms%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRAIgaFll2Vvqlk7EiT5RXggLvLUNEGdH_hLU10MZxO9p8HsCICklsbQ5F5DhwjAWke6yTB0L-GElGdrTUQZocbKPzi0G

Context: MFCreateSourceReaderFromURL
Error details: Invalid name.

Track types:
 
(Filename:  Line: 3872)

The only thing that properly works is https://files.catbox.moe/j3bno7.webm. That one works like a dream, with only a few possible skips:

https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1169127338
Can you post the name or the url of the world you are using to test ?

Hi There,

The only thing that properly works is https://files.catbox.moe/j3bno7.webm.

I too tested this while running Steam Linux Runtime - Soldier on beta and Proton Experimental on bleeding edge. Can confirm video players (USharpVideo) does work with WEBM file formats.

World Tested In: https://vrchat.com/home/world/wrld_6ebfc3e2-3553-4cd3-9aca-1ee5e84f7811

I have tested with MP4 and standard youtube links to no luck sadly.

Do note: I am using VRC ytdl stub from natsumi-sama

https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1169135449

I used the video you used to demonstrate that it's working. https://youtu.be/QRqY_20ti9A

I figured out I was on the wrong Proton version, but with all the right systems - Proton Experimental on bleeding_edge, Soldier on client_beta - it still doesn't work. Although now, it fails in a different way.
steam-438100.log

I've never seen such a colorful error log.
It looks like GStreamer is having a field day trying to decode the videos. The WebM still works fine.

Hi There,

I may have a possible suggestion, but it's a real hacky way of solving this problem. If WebM formats work, perhaps make a temporary yt-dlp executable that can download & convert to webm and stream it to file while giving VRC client the local file path for the .webm file?

It's just a thought atm. Definitely not the best solution out there, hence "being hacky".

I tested with an h264 mp4 and it worked great.

If it's of any interest this is the ffprobe output for the file:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'symph501.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    title           : Symphogear XV - 01
    encoder         : Lavf59.16.100
  Duration: 00:23:40.05, start: 0.000000, bitrate: 2700 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/unknown/unknown, progressive), 1280x720 [SAR 1:1 DAR 16:9], 2499 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](jpn): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 194 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]

Which h264 MP4 video?

https://ducky.ovh/space.mp4

Here's one encoded in the same way @roryyamm

transcoded with this command:

ffmpeg -y -i Y064cQ6.mp4 -preset slow -pix_fmt yuv420p -vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1" -c:v libx264 -b:v 2500k -pass 1 -an -f mp4 /dev/null ; ffmpeg -y -i Y064cQ6.mp4 -vf "scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1" -map_chapters -1 -preset slow -c:v libx264 -b:v 2500k -pix_fmt yuv420p -pass 2 -ac 2 -c:a aac -b:a 192k space.mp4

@duckbytes Unfortunately, it doesn't work. Same issue as the YouTube videos.

I made an effort to annotate this log with announcements of what I was doing. If you see something surrounded by '---', that's me.
In order, I tested:
https://ducky.ovh/space.mp4 (Did not work)
https://files.catbox.moe/j3bno7.webm (Played twice)
https://www.youtube.com/watch?v=QRqY_20ti9A (Did not work)
https://www.youtube.com/watch?v=1GvV0UkVq20 (Did not work)
steam-438100.log

I am presently on vacation, so I can't investigate these video developments in great detail until I get back. That being said the j3bno7.webm file uses VP8 video and Vorbis audio, which has always worked in proton, due to those codecs being built into unity (scroll up much higher in thread for that conversation).

As for offline transcoding into a compatible format, I have completely thrown out the concept as it is too hard for most computers to run VRChat, transcode the video, and play the video at the same time. Especially while maintaining sync.

I think I might have figured out why people are having trouble with h264 playback. It seems to be affected by what version of libavcodec.so.58 gets used - the one in the old Steam runtime under steam/ubuntu12_64 seems to be getting picked for me and that definitely doesn't work at least on my system, whereas the system-wide version obviously does. Unfortunately this doesn't work when launching from within Steam and I can't even figure out what's in Steam's version of libavcodec.so.58 - it seems to have a load of references to valve_h264 that don't correspond to anything public and easily found.

Nice, I've been out of the loop for a couple days, glad to see the patch got into bleeding edge and is working! :smile:

Interested to see why AVPro is crashing

@roryyamm can you remove your proton prefix and try again?

webm has always worked, even before this patch.

There are a couple of things we can investigate regarding AVPro. Including an updated version that may fix the crashing issue. No promises there. Also, still on vacation.

I think I might have figured out why people are having trouble with h264 playback. It seems to be affected by what version of libavcodec.so.58 gets used - the one in the old Steam runtime under steam/ubuntu12_64 seems to be getting picked for me and that definitely doesn't work at least on my system, whereas the system-wide version obviously does. Unfortunately this doesn't work when launching from within Steam and I can't even figure out what's in Steam's version of libavcodec.so.58 - it seems to have a load of references to valve_h264 that don't correspond to anything public and easily found.

That's interesting, actually. If it's embedded in steamworks for that path that's really interesting. The important thing is knowing exactly how unity and avpro are routing mediafoundation.

TL;DR for the love of god use vaapi hardware acceleration.

I want to bring up an important discussion regarding decoding paths for the sake of VRChat's overall performance on deck as we get closer to a viable playback method. The short bit is that we want to make sure the method by which mediafoundations routes the play request is going through the most efficient path for encoding/decoding, which is the dedicated silicon that exists on the deck.

Long thing you can skip if you know a a lot about video encode/decode

H.264 is not included on linux arch by default. However, there is an embedded DSP and of course it has 8 RDNA 2 CUs. 
It IS no doubt part of the proton stack, because the steam deck fully includes **Steam's Remote Play On Steam Deck**, which is fully realtime, fully hardware accelerated, near zero latency video encoding over a local network without slowing the deck down. That being said, decoding should ALSO be done as close to that method as possible, using AMdec, otherwise the deck will occupy an entire cpu core just to play video, and will probably occupy the hardware DSP as well, which isn't good. There's dedicated SoC silicon for this. We want to make sure it's being utilized. 
I know live encoding seems like a bad idea on the surface (and should be avoided whenever possible) but actually, if it comes down to it there may be reasons why doing the same kind of encoding via the same path that Steam Remote Play is using is fine. (which is near or is actually realtime with no cpu load for 720p and 1080p) via AME which is included on the Deck much like your cell phone. It's the same reason why steam link is so cool (I've got one of those too). 

In any case, let's hope we're doing something accelerated for the decoding here. There's an interesting tidbit about gaming mode however:
In 'Gaming Mode' Kodi and plex and other things can't detect VAAPI. In desktop mode, VAAPI detected just fine.
In 'Gaming Mode'+: software decoding only. This is bad.

If you have sshd running on your Steam Deck, you can do something fun with native encoding and decoding that might give you some insight. This is close to how the steamdeck does it's own Steam Remote Play.

Gstreamer first off is where it's at, and looks at native, internal hardware codecs.

(deck@steamdeck ~)$ sudo steamos-readonly disable
(deck@steamdeck ~)$ sudo pacman -S gstreamer-vaapi gst-plugin-pipewire

The important, fiddly bit is this: alsa_output.pci-0000_04_00.5-platform-acp5x_mach.0.HiFi__hw_acp5x_1__sink.monitor

You can use the vaapi plugins if you want hardware accelerated encoding, then the pipewire plugin for fetching the video itself. You then take pipewiresrc and convert it to a h264 stream (no actual load to do this really).

gst-launch-1.0 -e \
    pipewiresrc do-timestamp=True \
        ! queue \
        ! videoconvert \
        ! queue \
        ! vaapih264enc \
        ! h264parse \
        ! mux. \
    pulsesrc device="alsa_output.pci-0000_04_00.5-platform-acp5x_mach.0.HiFi__hw_acp5x_1__sink.monitor" \
        ! queue \
        ! fdkaacenc bitrate=2300\
        ! mux. \
    flvmux name=mux streamable=True \
        ! rtmpsink location='rtmp://YOURIPGOESHERE/stream/hwinc live=1'

You could also mux this into webm and be done with it but obviously we should be focusing on just doing decoding, not encoding.

https://github.com/matanui159/ReplaySorcery here's another project that does something similar to mimic nvidia/amd instant replay.
Anyway, I'll leave my comments at that. Hopefully valve fixes this issue with vaapi on gaming mode, becasue avpro could play very nice with this in vrchat.
I'm going to page @pema99 since this is also sorta a unity issue

(note: the steam deck also makes a really dope dedicated streaming server box, but it's a bit pricy and overkill for that purpose compared to a TBS2603au or something)

last edit: found a steam forum discussion on hardware decoding
https://steamcommunity.com/app/1675200/discussions/1/6117591738156361243/
and this gist by robert kirkman has some really good stuff (but I would suggest using gstreamer over ffmpeg whenever possible) https://gist.github.com/robertkirkman/753922262259486ec417e5ff8b5b924b

@kisak-valve
hey there, I'm not sure how focused you are on this effort since may, but it extends well beyond just VRChat, of course. This is somewhat fundamental to Unity and video playback in a few ways for things like RTSPT, and unless groups are using ffmpeg or VLC addons for unity, they're generally using RenderHead's AVPro or relying on system codec playback support and multichannel.

AVPro is extraordinarily popular for vr video for a number of reasons, especially for things like the ability to pipe it into audio game objects with steamaudio HRTF attached and other things like that. They are an incredibly talented group that unfortunately hasn't focused on Linux much. If we could make them aware of this perhaps things could change.

@ComputerMaster1st @roryyamm
Can you check if you have libx264.so.142 in ~/.local/share/Steam/ubuntu12_32/ ?
If not, this was the cause of the issue after I reinstalled steam.

@guerryer I have libx264.so.142.crypt and libx264.so.142.md5, but no libx264.so.142.

@guerryer I have libx264.so.142.crypt and libx264.so.142.md5, but no libx264.so.142.

Here's the file https://drive.google.com/file/d/13GGVzflaa8ASG--On52YpYsf-ReD1Azy/view
MD5: 21ac1673b87bbb895fda049c306b3268

@guerryer Nope. Didn't work. It's there, but I get the same GST errors.
steam-438100.log

@roryyamm After digging further, go to steam://unlockh264 and restart the Steam client afterwards.
It should add this line "UnlockedH264Feature" "1" in ~/.local/share/Steam/userdata/ Your User ID /config/localconfig.vdf

Away from my setup on vacation as well. Anyone got a quick ytdl wrapper for transcode right now?

Well, that seems to have made it work, but now it's hanging for long periods every once in a while.
Log was too big for GitHub, even after I removed the unending error messages about Windows.System.DispatcherQueue not being found

Related Issue https://github.com/ValveSoftware/steam-for-linux/issues/6780

Holy hell H264 unlocked. Videos fully work on regular player! This is like a dream no transcode!

Hi There,

@roryyamm After digging further, go to steam://unlockh264 and restart the Steam client afterwards. It should add this line "UnlockedH264Feature" "1" in ~/.local/share/Steam/userdata/133076828/config/localconfig.vdf

I have just executed this on my system and I am pleased to announce that YouTube videos now work successfully as long as you set yt-dlp to do -f b[ext=mp4] filtering.

As far as I know from my own testing, only the worlds that use USharpVideo or similar (any world that doesn't use AVPRO basically) can play videos as mp4 with minor issues. I've only tested with newer videos and some new videos (uploaded within 24 hours) might not work properly. It's very hit & miss. With older videos I've tested, it's been mostly successful. Your mileage may vary.

World Used: https://vrchat.com/home/world/wrld_af0b87c4-8c50-4678-a697-887088013c72
Other Github Project Used: https://github.com/Natsumi-sama/VRChat-YouTube-dl-stub

Proton: Experimental (Bleeding-Edge)
Steam Linux Runtime - Soldier: client_beta

I do have a "proxy/fake" yt-dlp.exe program compiled using source from the youtube-dl-stub project I linked just above as well as put a php script onto a server I own. NETFramework 4.7.2 is required for compiling a yt-dlp.exe for yourself to link to webserver that hosts the php script. YT-DLP will also need to be installed on the system you're hosting the php script from.

Please perform testing of your own to confirm the results.

EDIT: Worlds like "LS Media" won't work still as it seems they're using fmp4 or some form of fragmented streaming and I'm unable to figure out how to solve this.

Just wanted to confirm that with unlockh264 + Experimental Bleeding Edge + Soldier client_beta, I was able to paste a Youtube video into the Room of the Rain video player, and it played the video.

~Might be a good idea to have VRChat pass -f b[ext=mp4] to yt-dlp when Proton is detected? At least for the time being.~

~Actually, Proton should be able to play vp9 as well IIUC. So webm should be accepted too.~

Edit: actually, most of the videos on YouTube would be either h264, vp9 or av1. I don't know if Proton can play av1 (although Proton Experimental ships with libdav1d), but it should play vp9. So your result might actually be better if you don't filter for mp4 @ComputerMaster1st

This is amazing! I have waited for this so long and it is FINALLY HERE!!!

That said, when playing various versions of Big Buck Bunny, it will go for 3-5 seconds then freeze, and become unresponsive (in the world mentioned earlier https://vrchat.com/home/world/wrld_6ebfc3e2-3553-4cd3-9aca-1ee5e84f7811). Does anyone have any idea why this happens?

Looks like different versions of USharpVideo preform differently
The version in Sovren's Chill home:https://vrchat.com/home/launch?worldId=wrld_1b482eca-bede-4de8-88a8-bbb6ca7e24cd) 1.0.0 And will have poppy audio and lagging video
While Room Of The Rain:https://vrchat.com/home/launch?worldId=wrld_fae3fa95-bc18-46f0-af57-f0c97c0ca90a) plays back just fine Version 0.3.0
@happysmash27 I just tested that world, i have the same issue as well. looks to be the same version as Sovren's USharpVideo 1.0.0

Is there some sort of feature set that came out between 0.3.0 and 1.0.0? USharpVideo https://github.com/MerlinVR/USharpVideo/releases

I am on Manjaro with a
AMD 3900x
Nvidia 2080TI
32gb of Memory

This is amazing! I have waited for this so long and it is FINALLY HERE!!!

That said, when playing various versions of Big Buck Bunny, it will go for 3-5 seconds then freeze, and become unresponsive (in the world mentioned earlier https://vrchat.com/home/world/wrld_6ebfc3e2-3553-4cd3-9aca-1ee5e84f7811). Does anyone have any idea why this happens?

It seems to work fine in the player in Midnight Rooftop! Either that, or it just started to work for unrelated reasons. Amazing!

I do have a similar issue. With a bog-standard Unity player, playing Youtube videos has random hiccups. It freezes, but then it skips.
https://www.youtube.com/watch?v=buBuAWsXdhs

I don't know how to upload a 400 MB log file.

Where is the log stored anyway? Maybe could find something interesting looking through mine, to see why the other players don't work.

You have to enable logging in Proton by adding PROTON_LOG=1 to your launch command.

Already have that, but where is it actually stored? stdout?

you'll usually find it as steam-APPID.log. I usually see it in my home directory. I don't know if that's the default - there are a lot of things on my system that I've changed and since forgotten about - but if you're doing debugging on the video players, just look for a steam-438100.log that's a couple hundred megabytes in size somewhere.

Wow! That is a very verbose log. Lots and lots of unwinded functions in assembly and and messages of being unable to find library for L"Windows.System.DispatcherQueue". Wonder what a good way to sort through it would be. Maybe some kind of grep or regex which removes these specific messages?

My usual solution is to do grep -vwE "Windows.System.DispatcherQueue" steam-438100.log > holy-shit-why-is-the-dispatcher-queue-throwing-up-so-many-issues-where-is-it.log

I've ended up doing a:

cat steam-438100.log |grep -v "trace:unwind"|grep -v "Windows.System.DispatcherQueue"|less

Which seems to make the log a great deal more readable at only 60512 lines instead of 1675072.

Ooh, this part looks relevent:

(wine:16868): GLib-GObject-WARNING **: 20:03:07.778: g_object_set_is_valid_property: object class 'GstURIDecodeBin' has no property named 'max-size-bytes'
winegstreamer warning: uridecodebin0: No decoder available for type 'audio/x-ac3, framed=(boolean)true, rate=(int)48000, channels=(int)6, alignment=(string)frame'.
winegstreamer warning: uridecodebin0: ../src-gst_base/gst/playback/gsturidecodebin.c(959): unknown_type_cb (): /GstBin:bin0/GstURIDecodeBin:uridecodebin0
winegstreamer warning: videoconvert1: not negotiated
winegstreamer warning: videoconvert1: ../src-gstreamer/libs/gst/base/gstbasetransform.c(1431): gst_base_transform_reconfigure_unlocked (): /GstBin:bin0/GstVideoConvert:videoconvert1:
not negotiated
First video frame not zero: 2 (0.033333s). Result may be out of sync. Please make sure tracks all start at 0 in https://happysmash27.me/Upload/Movies/bbb_sunflower_1080p_60fps_normal.mp4
(Filename:  Line: 0)

1244374.823:0124:01a4:fixme:mfplat:src_reader_QueryInterface ({7b981cf0-560e-4116-9875-b099895f23d7}, 000000007952F4E0)
1244374.825:0124:01a4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\mpr.dll" at 000000024F470000: builtin
1244374.825:0124:01a4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\wininet.dll" at 00000003A0440000: builtin
1244374.827:0124:01a4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\mferror.dll" at 000000023D7E0000: builtin
WindowsVideoMedia error 0xc00d36e6 while reading https://happysmash27.me/Upload/Movies/bbb_sunflower_1080p_60fps_normal.mp4

Context: Get video transform output sample count
Error details: Attribute is not found.

Track types:
   Audio Track, type: %01
   Audio Track, type: %03
   Video Track [1920 x 1080], type: I420
   Video Track [1920 x 1080], type: NV12
   Video Track [1920 x 1080], type: YV12
   Video Track [1920 x 1080], type: YUY2
   Video Track [1920 x 1080], type: IYUV
   Video Track [1920 x 1080], type: %15
   Video Track [1920 x 1080], type: %16
   Video Track [1920 x 1080], type:

(Filename:  Line: 3872)

Pretty sure that was the first one I tested where it would play for 4 seconds then stop.

Then it says a bunch of:

warn: D3D11Texture2D::QueryInterface: Unknown interface query
And some "warn:" then some ID that I am not sure is safe to post here.

For a couple thousand lines.

Then it says:

1244389.368:0108:012c:fixme:oleacc:find_class_data unhandled window class: L"[#32769](/issue/ValveSoftware/Proton/32769)"
1244394.364:0124:0380:fixme:mfplat:passthrough_transform_ProcessMessage 0000000079600BF0, 0, 0.
1244394.364:0124:0380:fixme:mfplat:passthrough_transform_ProcessMessage 0000000079600890, 0, 0.
WindowsVideoMedia error 0x80004004 while reading https://happysmash27.me/Upload/Movies/bbb_sunflower_1080p_60fps_normal.mp4

Context: WindowsVideoMedia::DiscardSamples ReadSample
Error details: <Empty>
Track types:
   Audio Track, type: %01
   Audio Track, type: %03
   Video Track [1920 x 1080], type: I420
   Video Track [1920 x 1080], type: NV12
   Video Track [1920 x 1080], type: YV12
   Video Track [1920 x 1080], type: YUY2
   Video Track [1920 x 1080], type: IYUV
   Video Track [1920 x 1080], type: %15
   Video Track [1920 x 1080], type: %16
   Video Track [1920 x 1080], type:

(Filename:  Line: 3872)

<Transmtn.Get GET api/1/time>

Some random base64-like nonsense, then something starting with "authcookie_"

Then this:

PostOffice SystemTime=07/03/2022 03:04:06 UTC
PostOffice ServerTime=07/03/2022 03:03:24 UTC
SystemTimeToServerTimeAdjustment=-00:00:42.5805063
1244440.619:0108:012c:fixme:oleacc:find_class_data unhandled window class: L"[#32769](/issue/ValveSoftware/Proton/32769)"
1244448.379:0370:0374:trace:seh:sigsys_handler SIGSYS, rax 0xffff, rip 0x600000000005.
1244448.379:0370:0374:trace:seh:install_bpf Seccomp filters already installed.
1244448.381:0370:0374:trace:loaddll:build_module Loaded L"C:\\users\\steamuser\\AppData\\LocalLow\\VRChat\\VRChat\\Tools\\yt-dlp.exe" at 0000000140000000: native
1244448.382:0370:0374:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernelbase.dll" at 000000007B000000: builtin
1244448.382:0370:0374:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernel32.dll" at 000000007B600000: builtin
1244448.385:0370:0374:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\msvcrt.dll" at 00000001C8DB0000: builtin

And it lists a ton of different libraries, which also occurred before the video message.

After that it lists the same thing again, just with my video on fast.happysmash27.me instead, so I think that's about where the video log for the non-working video (probably the one in the boat?) ends.

This other "Pro" video player which I'm guessing used AVPro didn't even seem to try to download the video as far as I could tell from my web logs, which is interesting.

In the beginning, before the first log, there is also:

1244371.750:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.750:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:Collection_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.750:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.750:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:Collection_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.750:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.751:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.963:0344:0340:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_LOCAL_MACHINE_ENTERPRISE, L"ROOT": stub
1244371.986:0344:0340:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_SERVICES, L"ROOT": stub
1244371.986:0344:0340:fixme:crypt:CRYPT_SysRegOpenStoreW CERT_SYSTEM_STORE_USERS, L"ROOT": stub
1244371.986:0344:0340:fixme:crypt:Collection_release Unimplemented flags 1
1244371.986:0344:0340:fixme:crypt:Collection_release Unimplemented flags 1
1244371.986:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.986:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.987:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.987:0344:0340:fixme:crypt:Collection_release Unimplemented flags 1
1244371.987:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.987:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.988:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:Collection_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.988:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.988:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:Collection_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:ProvStore_release Unimplemented flags 1
1244371.988:0344:0340:fixme:crypt:CRYPT_RegCloseStore Unimplemented flags: 00000001
1244371.988:0344:0340:fixme:crypt:MemStore_release Unimplemented flags 1

Hi There,

After more testing, a few worlds for me appear to have audio at x2 speed while others work fine. Can confirm that "Room of the rain" should work fine. Sovren's chill world did have mixed results. It worked for a bit... but then did the audio x2 speed. The rooftop world that was used for movies works aswell along with the movies in there.

I've also tested a few other movie worlds but not much luck due to either m3u8 issue or audio at x2 speed.

Yup, can also confirm that I got it working with Proton Experimental + Steam Beta + Steam Linux Runtime Soldier Beta + steam://unlockh264. Don't know if all of those are required, but for first time in my life I've seen a video player in VRChat on Linux.

Midnight Rooftop works perfect!

Cozy Boat plays the audio at double speed, but the video plays fine. This can be confirmed by playing a time sync video, where the beats happen exactly twice as fast as in the video.

Also, the video player stops preemptively. The YouTube clip is 30 minutes long, but the video dies after 53 seconds. Even with the double-speed audio, that only accounts for 106 seconds, barely 2 minutes.

The video is completely stopped/crashed, even though the player says it's only 53 seconds in and still "playing".

Awesome progress :clap:

Does it work with live streams?

Example stream: https://www.youtube.com/watch?v=5qap5aO4i9A

I tried that, but VRChat is crashing when I tried to play live streams.
However, I was able to play some YouTube videos perfectly with same settings too.

While Youtube and licensed codec statically hosted videos are pretty great, you're going to want to test it with a low latency livestream like the whitelisted provider VRCDN, as that's the major use case here in VRChat lately.

(This is due to the bustling concert and limited time events scene that has events daily, but especially on weekends).

There's other creative uses of realtime video that worlds rely on too. Typically if you want the best latency and streaming quality, it's an RTSP(t) source in Avpro's "low latency mode".

Just a reminder to observers that YT-DLP is used in VRChat to get a "media player friendly" url locally when a call is made from the client via udon sync to tell each user in the room to play a video. That url is not synchronized, but resolved locally, which is why you'll sometimes get inconsistent results in a group of users.
AVpro is one of two ways video is played in VRChat, and video players will be "set" in one or the other way, synchronized to the master of the room or current owner of the gameobject. If AVpro can't be made to work and you can only use Unity video player, there's a few tricks you have to do to make a player that is compatible to both. Mainly, you need to use a render texture that will give you the same video on the same canvas or swap the "screen" out entirely depending on which "mode" the player is in.

A creative player could theoretically put a local only toggle that swaps the user to use Unity Video Player while copying the rest of the settings from the person playing the stream.

That being said some livestreams historically worked in unity's native video player in windows, like mpeg2 and other formats.

I have a couple of maps where Lox's videoRT custom render texture material is being used that allows for this, and the video player seamlessly swaps between avpro and unity video player, and I could host a stream for anyone on VRCDN if you're testing.

@MehStrongBadMeh This is a bit of a nonsequiter and probably just about as useful as the "Why not Vulkan" comments... But how non-trivial is it to switch/ introduce the engine to openXR?
We have stuff like the Monado stack coming up https://gitlab.freedesktop.org/monado/monado which opens the door to all sorts of crazy VR configs and a huge amount of devices all platform independent such as box64 proton on ARM!

Is there any internal will to swap out or introduce new APIs?

Recently I started to see my whole game freeze up (not crashing), last few lines of logs on the console always looks like:

<Transmtn.Get GET api/1/time>

authcookie_
PostOffice SystemTime=07/07/2022 20:56:38 UTC
PostOffice ServerTime=07/07/2022 20:56:38 UTC
SystemTimeToServerTimeAdjustment=-00:00:00.3199220
<Transmtn.Get GET api/1/time>

authcookie_
PostOffice SystemTime=07/07/2022 20:57:38 UTC
PostOffice ServerTime=07/07/2022 20:57:38 UTC
SystemTimeToServerTimeAdjustment=-00:00:00.3163484
<Transmtn.Get GET api/1/time>

authcookie_
PostOffice SystemTime=07/07/2022 20:58:38 UTC
PostOffice ServerTime=07/07/2022 20:58:38 UTC
SystemTimeToServerTimeAdjustment=-00:00:00.3217522
Warning: The game hasn't rendered a frame from us in over 10 seconds
Warning: The game hasn't rendered a frame from us in over 10 seconds

Edit: Look at the timestamp the log doesn't seem to be relevant to the freeze. There's nothing in the log file either.

But how non-trivial is it to switch/ introduce the engine to openXR?

Pretty dang non-trivial. It is being investigated though. Can't really discuss much further there.

Recently I started to see my whole game freeze up (not crashing), last few lines of logs on the console always looks like:

Having a similar issue. Found that reverting from Proton Experimental Bleeding Edge back to just Experimental fixed the issue.

I can confirm that updating to the latest build of AVPro fixes it (and, by extension, the stream player) entirely in Proton and Steam Deck. Expect to see it in the next major VRChat update.

@MehStrongBadMeh Awesome news!

Nevermind to my answered openXR question as it appears that Monado actually has a little shim layer to provide an OpenVR interface. I'm using it right now while out and about with the QWERTY driver to pull up the VRC OpenVR virtual HMD on screen!

Holy damn!
For any of those suffering from the dreaded steamVR double vision & stutter give Monado an install and test out your headset and controllers with the vive or libsurvive physical drivers, **you may find the game playable on the open stack as of today. **

Nevermind to my answered openXR question as it appears that Monado actually has a little shim layer to provide an OpenVR interface. I'm using it right now while out and about with the QWERTY driver to pull up the VRC OpenVR virtual HMD on screen!

Are you referring to https://gitlab.com/znixian/OpenOVR/-/tree/openxr? That looks like Windows only at the moment.
or is it the SteamVR plugin that lets you use the monado hardware drivers? https://monado.freedesktop.org/steamvr.html

Either way I'm interested in trying this out if you have the time to write up how you did it.

Sounds really interesting to me too. I suffer really badly from the double vision problem. I'm giving it a try following https://monado.freedesktop.org/getting-started.html and https://monado.freedesktop.org/steamvr.html

While I can get the monado service running, SteamVR outputs my vive display to my main monitor instead of the headset. The headset stays grey, but I can see that tracking is affecting the output on the monitor.

I am using X11 with AMD 5700XT.

@duckbytes I found a wiki page for running OpenComposite on Linux: https://gitlab.com/znixian/OpenOVR/-/wikis/OpenXR-Linux-Setup. I think that's required to actually replace SteamVR with monado.

OpenComposite currently does not work with the openxr branch or the input branch for VRC, pavlov might work last I heard. Might be cool for legacy performance reasons but no real use yet...

However, Monado appears to actually have a steamvr state tracker now that works as an official OpenVR lib that VRC can use! I got the game to output visually in the QWERTY driver on my end. The Monado Discord confirms that the website is out of date and they actually ship functioning OpenVR now.
The appeal of using the Monado stack is it cuts out the steamvr abandonware issues so we can actually collaborate on making a working software stack and VR compositor that talks to the firmware on all these devices. Hell even WMR is starting to come up, just missing some drift compensation and controller support so basically 80% there.

You MUST add Monado as a plugin to your steamvr stack and enable the monado addon in your settings for it to work with steamvr.
https://monado.freedesktop.org/steamvr.html

@SpookySkeletons I don't want to lead this thread off-topic, so I keep it short: I gave monado a try, but I ran into the issue that it spawns the VR view on the desktop instead on the HMD (also, monado-service spams the console with [vive_sensors_read_lighthouse_msg] Unexpected sensor report type Unknown while steamvr is running).

Are you using the vive driver? Check the support matrix for devices/ drivers you will need to use libsurvive with v1 lighthouses

@SpookySkeletons I'm on Index with v2 lighthouses. Not sure which driver it is using.

@DASPRiD Addon installed and enabled in steamvr?

I can confirm that updating to the latest build of AVPro fixes it (and, by extension, the stream player) entirely in Proton and Steam Deck. Expect to see it in the next major VRChat update.

Ooh, this is fantastic news! I am super excited! This is the best thing that's happened related to VRChat for me since getting VR!!

OpenComposite currently does not work with the openxr branch or the input branch for VRC, pavlov might work last I heard. Might be cool for legacy performance reasons but no real use yet...

However, Monado appears to actually have a steamvr state tracker now that works as an official OpenVR lib that VRC can use! I got the game to output visually in the QWERTY driver on my end. The Monado Discord confirms that the website is out of date and they actually ship functioning OpenVR now. The appeal of using the Monado stack is it cuts out the steamvr abandonware issues so we can actually collaborate on making a working software stack and VR compositor that talks to the firmware on all these devices. Hell even WMR is starting to come up, just missing some drift compensation and controller support so basically 80% there.

You MUST add Monado as a plugin to your steamvr stack and enable the monado addon in your settings for it to work with steamvr. https://monado.freedesktop.org/steamvr.html

How to I ensure that it uses Monado instead of detecting my Vive first and trying to drive it directly? And how would I configure which Vive tracker goes where?

@happysmash27 You need to add it as a steamvr driver from that guide and make sure the "monado" addon is enabled in settings. steamvr crashes can disable it by accident so make sure to reenable it if it ever does.
I have NOT tested my HMD yet on account of being on vacation. Only able to test the virtual QWERTY driver and saw that openvr lib worked.

@SpookySkeletons Hm, the website did not say anything about an addon, where does one find it?

@DASPRiD Go here and register your plugin then make sure the addon is enabled.
https://monado.freedesktop.org/steamvr.html

@SpookySkeletons I got the plugin registered, but where can I enable the addon? I looked through the steamvr settings and didn't find anything.

Try here. The Monado service must be started beforehand on my machine as I'm running openRC without the fancy systemd autostart stuff.

Recently I started to see my whole game freeze up (not crashing), last few lines of logs on the console always looks like:

Started having this issue on regular Proton Experimental (but also the video player worked, so guessing Bleeding Edge became experimental)

Found that PROTON_NO_FSYNC=1 seems to fix it.

I found this page about needing libsurvive to be installed before compiling monado - https://monado.freedesktop.org/libsurvive.html

But I've tried a few different combinations of installing libsurvive, libsurvive-git, monado-git, installing libsurvive from source and monado from source, but for some reason libsurvive never appears in the list under "Regular built in drivers" when running monado-cli probe.

However when compiling monado it does say DRIVER_SURVIVE: ON and DRIVER_VIVE: ON in the output.

Not sure if this is the key to getting monado to work or not. I can't see any steps I've missed in the documentation.

On my QWERTY here, I'm running Monado as a regular user executable with monao-service using the specific environment vars to force the QWERTY driver but it should automatically select survive for your hardware even if it doesnt pick up on it in the probe (mine's not there either, I think it exists in the vive driver as a sublibrary).

1. Run monado-service and ensure it's happy and your headset should light up with a white BG
2. Run steamvr ensuring that the monado addon is active and installed, steamvr will show the home
3. Fire up VRC as regular

On further investigation, it appears AVPro isn't working nearly as well as I thought. Turns out the player I was using automatically switches to Unity Player for non-streams. Switching to a different player I can manually control reveals the true situation:

1. All AVPro videos play flipped upside down - I have no idea why, possibly needs to be fixed in Proton or possibly needs to be fixed in AVPro. It is theoretically possible for us to work around it in Unity, but that would be a hack. Will ask AVPro about it.
2. Streams don't work - I am pretty sure this is a Proton issue, I don't think Proton has any handling for dealing with m3u8 files. Perhaps @yshui might be able to assist there.

We'll still be releasing the updated AVPro in our next release, as it makes it possible for people to develop and test potential Proton fixes for it.

Recently I started to see my whole game freeze up (not crashing), last few lines of logs on the console always looks like:

Started having this issue on regular Proton Experimental (but also the video player worked, so guessing Bleeding Edge became experimental)

Found that PROTON_NO_FSYNC=1 seems to fix it.

@Goofybud16 How long would you generally be playing before getting the freeze?

Also, could you compare current experimental (20220706) and the build I uploaded here (unlock code "proton"): https://www.codeweavers.com/xfer/alasky/proton-test/ to confirm that the regression is between those two? (and also Bleeding Edge just to make sure it isn't already fixed?). You can test that build by:

1. Put build in ~/.steam/steam/compatibilitytools.d/. (you might need to create the compatibilitytools.d directory there if you don't already have one).
2. Untar build
3. Reboot Steam
4. Build should show up under drop-down menu when selecting proton versions.

The flipping part is normal for AVPro by itself. Most media players out there now are using some variant of Lox's videoRT which is a custom render texture which accounts for the flip, or we force it to only use Avpro, ignoring unity video player.
Changing this in VRChat would immediately break pretty much every world that has a video player using AVPro, this UV flip is totally expected by anyone building this out (many of our custom shaders for things like the huge alternate world show need the xy 0 position for avpro in the UV to be predictable, please don't change this.)

As for m3u8 - that's half the battle. Youtube live and Twitch use m3u8, but a more pressing soft target would be RTSPT and mpeg2 as that's what is used for VRCDN. For all of the major live events with 500-2000+ attendees every weekend across several instances use vrcdn's rtspt stream and just mirror the output to twitch. Twitch/yt/vimeo/etc is less often used in the more popular worlds these days if we're being honest, but it's still a thing from time to time.

Best Regards/どうぞよろしくお願いいたします。
Dylan Brown
tw: @dylhun

On Tue, Jul 12, 2022 at 8:03 AM MehStrongBadMeh @.***>
wrote:

On further investigation, it appears AVPro isn't working nearly as well as
I thought. Turns out the player I was using automatically switches to Unity
Player for non-streams. Switching to a different player I can manually
control reveals the true situation:

1. All AVPro videos play flipped upside down - I have no idea why,
   possibly needs to be fixed in Proton or possibly needs to be fixed in
   AVPro. It is theoretically possible for us to work around it in Unity, but
   that would be a hack. Will ask AVPro about it.
2. Streams don't work - I am pretty sure this is a Proton issue, I
   don't think Proton has any handling for dealing with m3u8 files. Perhaps
   @yshui https://github.com/yshui might be able to assist there.

We'll still be releasing the updated AVPro in our next release, as it
makes it possible for people to develop and test potential Proton fixes for
it.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1181675104,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFQNHWULRN4OEHCIM2OOCHLVTVNHVANCNFSM4FS34H6A
.
You are receiving this because you were mentioned.Message ID:
@.***>

Once again, you are not correct.
This flip is a disparity from trying the same players in Windows which do not experience this issue.

Strongbad, I promise you I am not talking out of my ass here. We do this every single day for an internationally recognized company.
https://github.com/RenderHeads/UnityPlugin-AVProVideo/issues/284 <-
This is a commonly known thing. Avpro intentionally doesn't flip to save overhead in vr you're expected to flip the UV itself.
I promise all the players you're using are accounting for that. Use it raw on windows and you'll see it's the same.

@MehStrongBadMeh

What API does AVPro use to play m3u8? Does MF support playing directly from m3u8?

As for RTSP, gstreamer should already be able to handle that. Do RTSP streams not work either?

@yshui I am no longer convinced the issue is related to m3u8. Although I also have no idea what is going on. I tried the example RTSP stream on this page: https://www.wowza.com/developer/rtsp-stream-test but it failed to play in Proton (works fine in Windows). We'll be releasing the update pretty soon, so you'll have an opportunity to try it out for yourself and see what is going on.

Sidenote: one of my co-workers mentioned that most of our users who set up RTSP streams actually use RTSPT, which was left out of the added scheme handlers for some reason.

which was left out of the added scheme handlers for some reason.

I think it's just neglect on my part. It would be pretty easy for Proton dev to add them, hopefully they will see this comment...

How long would you generally be playing before getting the freeze?

@alasky17, it was usually within around 10 minutes that I'd see the freeze. Sometimes it was right away (joined a world and the game crashed); sometimes it was while sitting in a world talking with someone. Tried multiple worlds, none seemed to really help much (originally thought it was related to the video player, hence changing worlds).

Looking at chat logs, I believe the first day I observed the issue was July 6 towards the end of the day, and fixed it by rolling back to Proton Experimental non-bleeding edge. I had been running Bleeding Edge to get the Video player to work, seems like one of the last changes to Experimental Bleeding Edge prior to Experimental updating may have been related.

Testing in Desktop mode I wasn't able to reproduce the issue after about 20 minutes.

Testing results in VR mode (SteamVR 1.22.13, Index, Index Controllers, 3x Vive Tracker 2.0, 3x Basestation 2.0) :
Kernel 5.18.10 (Mainline + Debian 5.18 config + 1000Hz)

I also get a freezing issue. Usually it happens within the first few minutes or so, but once or twice it also happened after a much longer time – more than 30 minutes IIRC. Sometimes VRChat also just randomly and very suddenly crashes. The freezes are more common than the crashes though.

Rtspt and rtsp are generally interchangeable for the purpose of vrcdn.
For example, rtsp, (dropping the t), will work in vlc projector in obs
using vrcdn relay.
Rtspt will not (edit for clarity) work in OBS At the moment, but it's required for VRCDN in VRChat with AVPRO for low latency mode, but the rtsp address isn't even listed as a supporting stream format (in vrcdn, but it does work in OBS!).

To be spicific, the Real Time Streaming Protocol itself is split into three:

Rtspu is udp, rtspt is tcp, and rtsp is unspecified, or "autonegotiating"
basically.

Again if you need a proven working stream type hit me up. I can broadcast
from anywhere in the world to any format vrcdn supports (you'll probably want rtspt!) from multiple sources simultaniously, including fmp4 or m3u8 or rtsp or etc, though I reccomend reaching out to them and working with them directly. Great group of people over there.

For the purposes of Concerts in vrchat we always use rtspt and mpeg2 for quest as that's what they recommend for their service.

For twitch it's m3u8 mp4 h.264 main 6000kbps 4.1 or so.
For YouTube it's usually identical, except when it's occasionally vp8 or
vp9, but iirc vrchat forces the quest compatible selection from static
video and m3u8 for streams.

Vimeo is identical.
SoundCloud is audio only but probably doing something unusual like aac
alone or vorbis.

Topazchat in Japan uses rtsp straight up.

On Wed., Jul. 13, 2022, 3:58 p.m. MehStrongBadMeh, @.***>
wrote:

@yshui https://github.com/yshui I am no longer convinced the issue is
related to m3u8. Although I also have no idea what is going on. I tried the
example RTSP stream on this page:
https://www.wowza.com/developer/rtsp-stream-test but it failed to play in
Proton (works fine in Windows). We'll be releasing the update pretty soon,
so you'll have an opportunity to try it out for yourself and see what is
going on.

Sidenote: one of my co-workers mentioned that most of our users who set up
RTSP streams actually use RTSPT, which was left out of the added scheme
handlers for some reason.

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1183621006,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFQNHWT5FEI3PMXDQH56WJ3VT4NVTANCNFSM4FS34H6A
.
You are receiving this because you were mentioned.Message ID:
@.***>

Anyone else reading this thread. Don't let Lhun discourage you from adding rtspt support to the scheme handlers.

Also getting the freezing issue here on proton experimental. It was definitely there in the previous experimental version also, since I remember it freezing there too while testing the video-fixes.

Anyone else reading this thread. Don't let Lhun discourage you from adding rtspt support to the scheme handlers.

I'm not sure where you thought I was discouraging anyone, i'm saying precicely the opposate. RTSPT followed by HLS m3u8 in h.264 [email protected] in that order, everything else is fairly miniscule. You need all three! RTSPT is the -most- required protocol encapsulation and delivery if you want the "full monty" vrchat clubbing experience on linux with low latency, like it is for windows.
I hope it's available soon, because i've got plenty of people who would jump to linux full time if that one thing worked (myself included, probably!)

@ZarathustraDK @happysmash27 @Goofybud16 We are currently looking into the experimental freeze. My recommendation is to use PROTON_NO_FSYNC=1 %command% for now while we work on solving the problem.

We have been having trouble reproducing the issue -- could y'all get logs of the freeze? You can just add this to the launch options (without nofsync of course): PROTON_LOG=+pid,+loaddll,+timestamp,+seh,+unwind,+vrclient,+openxr,+vulkan,+fsync,+server %command%

That actually cropped up when I had QA test the updated AVPro (to ensure we were clear to merge it into the codebase). Seems to be totally random, though it strikes more commonly on a fresh install of VRChat, so it may be worth uninstalling and reinstalling VRChat to try to bait it out.

VRChat also seem to trigger a bug in Wine, see: https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1145092279 Hope this can get some attention...

I said it went away with wiping compdata. This is true to some extent, before I did that, VRChat crashes so often it's unplayable. Now it still happens but it way less often, maybe once every 30 hours of play time?

@Goofybud16

Experimental 20220628 Unset Perfectly fine for 20-30 minutes
Experimental 1 Works for hours, no problems
Experimental Bleeding Edge 1 Runs fine for 20-30 minutes

Could you clarify what you mean here? Did you have trouble with either build after 20-30 min? Or did you just only test those proton versions for 20-30 min whereas you tested the other version for many hours? If there is a problem after 20-30 min, a log with just PROTON_LOG=1 of that problem would be helpful.

Also, logs of the freeze with the logging channels I mentioned above (PROTON_LOG=+pid,+loaddll,+timestamp,+seh,+unwind,+vrclient,+openxr,+vulkan,+fsync,+server %command%) would be greatly appreciated if you get time :)

Did you have trouble with either build after 20-30 min?

No issues, to clarify, that is just how long I ran them for before moving on. The one I tested for hours is my usual play configuration.

I further tested Experimental Bleeding Edge after that comment for a few hours, and it seems to hold up find as well with PROTON_NO_FSYNC=1.

20220628 build also ran fine back when I was using it (before it updated) but I didn't test it for a longer period this time.

My VRChat logs with PROTON_LOG=1 often have a series of base-64-esque characters, a newline, then a string beginning with authcookie_ that contains a series of numbers and characters delineated by - afterwards. Are logs with these safe to publish publicly, or should one remove any lines containing these beforehand?

@ZarathustraDK @happysmash27 @Goofybud16 We are currently looking into the experimental freeze. My recommendation is to use PROTON_NO_FSYNC=1 %command% for now while we work on solving the problem.

We have been having trouble reproducing the issue -- could y'all get logs of the freeze? You can just add this to the launch options (without nofsync of course): PROTON_LOG=+pid,+loaddll,+timestamp,+seh,+unwind,+vrclient,+openxr,+vulkan,+fsync,+server %command%

Attached is my Proton log from last night with PROTON_LOG=1 which I generally leave on, passed through |grep -v "Windows.System.DispatcherQueue"|grep -v "authcookie_"|grep -v "<that random string of characters>". The random string of characters then string starting with "authcookie" seems to always start after the message that starts with <Transmtn.Get GET and which ends with something it is trying to retrieve, e.g, api/1/auth/user/notifications?type=friendRequest&n=100&offset=0, and then a >.

Since your log command includes unwind I have opted to not include the grep -v "trace:unwind", which raises the file size from 260K to 8.4M. Removing the redundant dispatcher queue messages (and authcookie things) lowered the size from 27M to 8.4M.

Since I was only running it to test an avatar and it only worked for a bit before crashing the file size is quite a bit more reasonable than normal so can be uploaded to Github without issue:

steam-438100_2_no_dispatch_queue_etc.log

It should be noted that what caused it to quit fully was most likely me closings SteamVR, after the freeze lasted long enough that it did not look like it would recover.

I will also use the requested log options in the future, but in case it is of any use I am sending a currently available log now in order to get a log out more quickly.

Please mind that logs are compressed very well, even a several GB log can be compressed and uploaded somewhere. Unfortunately the basic log gives no clue what it is waiting for, chances are that the log with suggested channels will tell more.

Also, is it possible to check if the hang is there or not with PROTON_NO_FSYNC=1 PROTON_NO_ESYNC=1 (that is, with server sync)?

Also, I actually do see something in the log, the game is probably hung in its main thread while holding a ctitical section from GameAssembly.dll (no clue why though). If it is maybe possible to guess from some game logs what it is waiting for maybe it can give some clue what is going wrong.

https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1185776786 @alasky17
Here's a log of VRChat after it crashed
steam-438100.zip

I was finally able to get a freeze log after many tries, but my log is 52MB even after compression and cannot be uploaded because of that. And the crazy thing, is that this is one of my smallest logs! I had tried doing the same thing earlier but just didn't crash for so long, and ended up with a log of 50GB or so before I restarted VRChat without the logging. This logging format uses data like crazy enough to tank my framerate, so I couldn't just leave it on all the time... but then VRChat started crashing again so I was able to get it to happen shortly after launch and capture it in the log, which again, is still too big for Github.

VRChat is implementing EAC. @MehStrongBadMeh, has the checkbox that makes it work on Linux been checked? Worried that I may get banned despite not using any mods.

Also wonder if this effects YouTube-DL or not. I had swapped it out before and would need to double-check it is original if it is doing EAC on YouTube-DL too.

I have ensured and tested that EAC has been set to be Linux, Proton, and Steam Deck compatible. No worries there.

I was finally able to get a freeze log after many tries, but my log is 52MB even after compression and cannot be uploaded because of that. And the crazy thing, is that this is one of my smallest logs! I had tried doing the same thing earlier but just didn't crash for so long, and ended up with a log of 50GB or so before I restarted VRChat without the logging. This logging format uses data like crazy enough to tank my framerate, so I couldn't just leave it on all the time... but then VRChat started crashing again so I was able to get it to happen shortly after launch and capture it in the log, which again, is still too big for Github.

There should be a way to upload 52MB somewhere. E. g., dropbox?

Video players now works on Linux since the first EAC update launched on live. It's is mentioned on the patch notes. https://docs.vrchat.com/docs/latest-release#fixes 🎉🎉🎉

I hope this fix affects everyone, but at least it works now on PopOS 22.04 (tested using desktop mode).

Yes, this update contains the updated AVPro that fixes it on Proton. As a result, I have removed the --enable-avpro-in-proton launch option as it is no longer needed. That being said, AVPro still isn't fully working, last I checked. That being said the path should now be clear for additional Proton updates to fix the remaining issues.

Interestingly, I tried setting AVPro to the other codec modes, to see if they ran if they ran any different. The result, they don't work at all. The default MediaFoundation mode is the only one that works in Proton. Which is good to know.

Unity Player seems to be fully operational, which is nice.

Yes, this update contains the updated AVPro that fixes it on Proton. As a result, I have removed the --enable-avpro-in-proton launch option as it is no longer needed. That being said, AVPro still isn't fully working, last I checked. That being said the path should now be clear for additional Proton updates to fix the remaining issues.

Yep you are right, it depends on the video player, I tested AVPro and it flips the video upside down and sound controls don't work, but with the Unity player it works great. Even with that issues that's a very big step.

Looks like the EAC update broke VRC for me..

Attached is my log.

I did a verify integrity of files before trying to run it.

Using proton experimental.

steam-438100.log

Edit: I tried a clean prefix and now it doesn't show not responding, but it is stuck on a blank loading screen.

For some reason github won't let me upload this log, but I'll try to upload it again a bit later.

Final edit: Switching to proton 7 seemed to fix it and going back to experimental it still keeps working, so not sure what happened really.

Random freezes that use 100% CPU are happening.
I needed to use proton-ge in the last version, the last proton from Steam did not start the game.

Running Proton experimental on manjaro
the game wont connect to steam compositor for me. launching from both within steamvr and steam desktop app.
Steamvr is running I can do more tests and grab logs tomorrow
But this EAC rootkit update has been a big botch job for me. even on my windows drive it failed. and I had to reinstall windows as all recovery tools (dism/sfc) failed to repair windows and I lost the ability to launch other apps (some how killed chocolatey gui on my windows side)

I am also experiencing the same issue as noideaman. Can provide logs if told where to find them.

For me, VRChat can start and run with EAC, but it refuse to launch in VR mode. If I choose the VR mode, it still starts in desktop mode.

From log:

2022.07.27 17:59:15 Error      -  XR: OpenVR Error! OpenVR failed initialization with error code VRInitError_Init_InterfaceNotFound: "Interface Not Found (105)"!

...

2022.07.27 17:59:15 Error      -  InitVRSDK failed: failed to load 'OpenVR'!


2022.07.27 17:59:15 Log        -  VR Disabled

Other VR games seems to work fine.

@MehStrongBadMeh

@kisak-valve do you want me to set any additional WINEDEBUG flags?

My experience:

1. On first run (reinstalled VRChat) it installs the dependencies first.
2. It starts what I assume is the EAC installer (black window with a blinking cursor), this goes away after about 10 seconds without any sign of success or failure.
3. The EAC-loader pops up for a split second. This seems to me a very short time (maybe an EAC-installation problem?)
4. VRChat starts, I login to my VRChat-account.
5. It warns me that it's about to drop me into a tutorial world, I click OK, and I get stuck on an empty, animated loading background with music playing like in @duckbytes screenshot. It never gets any further.
6. I kill the program and restart it.
7. Now it assumes I've already gone through the tutorial and starts loading my home world like normal
8. Black screen for a somewhat long time (~10 sec)
9. Controls "cheat sheet" pops in first.
10. Then
    
    Clicking Quit closes the program.

@kisak-valve Log attached
log.zip

@yshui Could you please attach the log with PROTON_LOG=+vrclient,+openxr if possible? Normally the VR interfaces plainly missing in Proton's vrclient are seen in the default log, but nothing here, probably something less obvious is going on.

@gofman
steam-438100.log.gz

maybe the relevant part:

123443.826:01c0:01c4:trace:loaddll:build_module Loaded L"Z:\\mnt\\local_storage\\shui\\SteamLibrary\\steamapps\\common\\VRChat\\VRChat_Data\\Plugins\\x86_64\\openvr_api.dll" at 00000001C4540000: native
123443.858:01c0:01c4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\api-ms-win-core-file-l2-1-1.dll" at 000000039F580000: builtin
123443.863:01c0:01c4:trace:loaddll:build_module Loaded L"C:\\vrclient\\bin\\vrclient_x64.dll" at 00007F8F24400000: builtin
123443.864:01c0:01c4:trace:vrclient:DllMain (0x7f8f24400000, 1, (nil))
123443.864:01c0:01c4:trace:vrclient:VRClientCoreFactory name: IVRClientCore_003, return_code: 0x10f2d0
123443.864:01c0:01c4:trace:vrclient:load_vrclient Linux OpenVR runtime is not available
123443.864:01c0:01c4:trace:vrclient:DllMain (0x7f8f24400000, 0, (nil))
123443.864:01c0:01c4:trace:loaddll:free_modref Unloaded module L"C:\\vrclient\\bin\\vrclient_x64.dll" : builtin

I think this means vrclient_x64 was not able to read the PROTON_VR_RUNTIME environment variable? Maybe EAC cleared it?

Update:
Steam helper is able to find vr runtime:

124310.447:0020:00cc:trace:steam:initialize_vr_data Starting VR info initialization.
124310.447:0020:00cc:trace:steam:load_vrclient got openvr runtime path: /home/shui/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so

Update:
PROTON_VR_RUNTIME was not changed :thinking: , these are all the SetEnvironmentVariableW calls:

124726.953:0020:0024:trace:process:SetEnvironmentVariableW (L"PROTON_VR_RUNTIME" L"/home/shui/.local/share/Steam/steamapps/common/SteamVR")
124726.953:0020:0024:trace:process:SetEnvironmentVariableW (L"VR_PATHREG_OVERRIDE" (null))
124726.953:0020:0024:trace:process:SetEnvironmentVariableW (L"VR_OVERRIDE" (null))
124727.635:014c:0150:trace:process:SetEnvironmentVariableW (L"SteamNoOverlayUIDrawing" L"1")
124730.695:01c8:01cc:trace:process:SetEnvironmentVariableW (L"MONO_REFLECTION_SERIALIZER" L"yes")
124730.695:01c8:01cc:trace:process:SetEnvironmentVariableW (L"MONO_XMLSERIALIZER_THS" L"no")
124738.070:01c8:01cc:trace:process:SetEnvironmentVariableW (L"SteamAppId" L"438100")
124738.070:01c8:01cc:trace:process:SetEnvironmentVariableW (L"SteamGameId" L"438100")

GetEnvironmentVariable is not logged unfortunately logged, but only the call not the result of the environment variable, so:

124738.386:01c8:01cc:trace:process:GetEnvironmentVariableW (L"PROTON_VR_RUNTIME" 000000000010D0D0 4096)

not very useful.

At least if I hard code the VR runtime path in vrclient and recompile it, VR works. This means we just need to sort out the environment variable problem.

Hopefully I don't get banned for using a modified vrclient_x64.dll? 😕

Maybe not the best idea to discuss EAC circumvention here... @ZarathustraDK

Weirdly, for me the bug manifests in another way. When I try to start the game in VR mode, it just boots into desktop mode instead.

@DASPRiD

... manifests in another way. When I try to start the game in VR mode, it just boots into desktop mode instead.

no no, this is exactly the same as what i got.

@yshui Ah, good to know, thanks. I'll keep an eye on this thread then for possible solutions. Until then I'll be out of VRChat I guess.

@yshui
no no, this is exactly the same as what i got.

I'm as far as well. The EAC-circumvention didn't work. In fact I was being a dumb-dumb, I already had the EAC-circumvention installed for Star Citizen (thought I had it removed long ago), and that was what was getting me booted in VRChat. After removing it I can enter in pancake-mode, but VR-mode bugs out and enters pancake-mode instead.

Lessons were learned I suppose ^^'

I guess VRChat's QA just didn't test with VR mode at all then, when they said EAC works with Linux?

Probably only tested for Steam Deck-compatibility I imagine.

Well, we did test other Linux platforms. But not in VR. If there is something we can do on our end to get it working in VR on Linux, I am happy to implement that. I was going to contact Valve about this issue, but it looks like @kisak-valve is already investigating the issue. May still shoot out a message anyways.

The problem (at least the initial one observed with VR now) is clear, it is the way EOS EAC starts game process so that all the Windows environment variables are lost on the way. I am going to fix this part soon in Proton so we don't rely on Win env vars preserved to get that path.

@gofman Ah, excellent! Thanks for your help there.

@kisak-valve good to know. Your assistance in the communication is helpful and appreciated regardless.

I am going to fix this part soon in Proton so we don't rely on Win env vars preserved to get that path.

Good to hear. If only this was tested and discovered before launch...

VR should hopefully work with the just updated Proton Experimental [bleeding-edge] branch (the branch for Proton can be selected by opening Properties for Proton Experimental and going to "BETAS" page.

@gofman Thank you! Amazing how quickly you fixed it.

@gofman Confirmed working here, you just saved my friday. Thanks a million :D

Me: :cry:crying because running VRChat on Proton Experimental (bleeding-edge) is not working Update: Wow was I stupid. I forgot to push the blue update button on the Proton Experimental page in order to make it bleeding-edge! Please forgive my halfmindedness.

@gofman Thank you so much for saving my life.

kawanerio@MoebuntuStudio11:~$ inxi -Gz
Graphics:
  Device-1: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] 
  driver: amdgpu v: kernel 
  Display: x11 server: X.Org 1.20.13 driver: amdgpu,ati 
  unloaded: fbdev,modesetting,vesa 
  resolution: 1680x1050~60Hz, 1280x1024~60Hz, 1920x1080~60Hz, 1920x1080~60Hz 
  OpenGL: renderer: AMD Radeon RX 580 Series (polaris10 LLVM 12.0.0 DRM 3.44 
  5.16.9-051609-lowlatency) 
  v: 4.6 Mesa 22.1.3 

Although this is rather minute, VRChat do tend to not start in my environment sometimes. However, this can easily be fixed with a restart of SteamVR. Just wanted to know if I was the only one with this problem.

@KawaneRio I did experience that issue with a few VR games. Basically the first time it starts fine, then when I quit it and try to start it again, it won't come up at all until I restart SteamVR. Haven't figured out the cause of that yet.

@KawaneRio @DASPRiD Have you tried launching it while still in VR but from the desktop view by interacting with Steam's tray icon and/or window? I've found some weirdness around SteamVR always wanting to enter Room Setup mode even when it doesn't need to, and once it does, specifically launching games through the SteamVR UI is nonresponsive for at least a good few minutes.

So I tested out Bleeding Edge today, and I was able to play for 50 minutes, at which point it crashed. I then tried to restart the game but it immediately froze on the login window. I restarted the game again, and VRChat reported that my client was modified and kicked me out.

@KawaneRio I did experience that issue with a few VR games. Basically the first time it starts fine, then when I quit it and try to start it again, it won't come up at all until I restart SteamVR. Haven't figured out the cause of that yet.

Sounds like this bug: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/479
afaik there is no fix beyond restarting vr

Launching doesn't work. Log file is so short I can put it in a comment

======================
Proton: 1659216786 experimental-bleeding-edge-7.0-21243-20220730-pf97544-wf05d1d-d0eaad2-vd00d03
SteamGameId: 438100
Command: ['/home/rory/.local/share/Steam/steamapps/common/VRChat/launch.exe', '--no-vr']
Options: {'forcelgadd'}
depot: 0.20220727.64
pressure-vessel: 0.20220726.0
scripts: v0.20220726.0-0-ga110829
soldier: 0.20220726.0 soldier 0.20220726.0
Kernel: Linux 5.18.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) x86_64
System WINEDEBUG: +mfplat
======================
fsync: up and running.
wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
src/common/pipes.cpp (883) : fatal stalled cross-thread pipe.
src/common/pipes.cpp (883) : fatal stalled cross-thread pipe.
src/common/pipes.cpp (883) : Fatal assert; application exiting
src/common/pipes.cpp (883) : Fatal assert; application exiting
assert_20220730201709_3.dmp[1554198]: Uploading dump (out-of-process)
/tmp/dumps/assert_20220730201709_3.dmp
_ExitOnFatalAssert
pid 1553609 != 1553608, skipping destruction (fork without exec?)
assert_20220730201709_3.dmp[1554198]: Finished uploading minidump (out-of-process): success = yes
assert_20220730201709_3.dmp[1554198]: response: Discarded=1
assert_20220730201709_3.dmp[1554198]: file ''/tmp/dumps/assert_20220730201709_3.dmp'', upload yes: ''Discarded=1''
pid 1554198 != 1554197, skipping destruction (fork without exec?)

Deletion of prefix hasn't helped. Updating Proton Experimental hasn't helped.

Does anyone know if the EAC fix will be backported to the stable Proton branch?

Does anyone know if the EAC fix will be backported to the stable Proton branch?

Not exactly sure what do you mean by EAC fix, if that is about non functioning VR with EOS EAC which is fixed in Proton Experimental then the fix is proton-7.0.4 release candidate, so should normally appear in 7.0.4.

@gofman That's what I'm referring to, yes. Experimental has the above mentioned (in)frequent crashing issue (that and VRChat randomly reporting one would use a modified client and kicking you out), which is why I'm waiting for the stable release. Is there a release date for 7.0.4 known?

No, there is no known date. You can follow it here: https://github.com/ValveSoftware/Proton/issues/6062, release candidate should be available at this point.

I wonder if the random hang issue is still happening with the very latest Experimental? I was under impression I found and fixed the reason for that in fsync.

As for modified client, can't say anything, this is probably on EAC side. Not sure that is directly related to stable vs Experimental. Does it happen with proton-7.0-rc branch?

Great questions. The random hangs were definitely happening seven days ago on Bleeding Edge, I haven't tested again since then. I gonna test with the RC and Experimental a little bit this weekend and report back.

I am mostly curious about latest Experimental (7 days ago the fix wasn't there). Stable -rc doesn't have the commit which introduced the regression and neither the follow up which fixed it.

@gofman I just had a three hour session without any crashes on latest Experimental.

@DASPRiD may i inquire how did you manage such a feat, im running pop os(1) here and i havvent been able to run the game on steam vr after the EAC update i tried many versions of proton, also may i also get the hardware info your running?

(1)
OS: Pop!_OS 22.04 LTS x86_64
Kernel: 5.18.10-76051810-generic
MB: B450 AORUS M
CPU: AMD Ryzen 7 3700X (16) @ 3.600GH
GPU: NVIDIA GeForce RTX 3060
RAM: 64Gb

@Teru-dot-png I'm using Proton Experimental (Standard, not Bleeding Edge). I initially had an issue with EAC game file mismatches, which was resolved by verifying the game files through steam. Booted up SteamVR and then started the game in VR mode via the Steam desktop app.

Note that starting the game took about 1 minute for me, meanwhile it just looked like it wouldn't start (loading screen on desktop pops up for a moment, then disappears and game window only comes back up after a minute).

Here's my sys info:

OS: Pop!_OS 22.04 LTS
KERNEL: 5.18.10-76051810-generic
CPU: Intel Core i7-5930K @ 3.50GHz
GPU: NVIDIA GeForce RTX 2070
GPU DRIVER: NVIDIA 510.85.02
RAM: 32 GB

Does not work after EAC update
Getting this message in log:
wine: Unhandled page fault on read access to 00000004 at address F7FD1F5D (thread 0138), starting debugger...
How to debug it" gdb_run only launches launch.exe under debugger

EAC has stopped working for me too on experimental:

steam-438100.log

I did a verify integrity of files too before trying again.

It seems to crash after unloading vrclient.dll, when running start_protected_process directly
Maybe EAC is trying to destroy process?

00d8:00dc: loads DLL C:\vrclient\bin\vrclient.dll @00000000F7480000 (0<0>)
000000d8:000000dc: unload DLL @00000000F7480000
[New Thread 228]
[New Thread 224]

Thread 1 "00dc" received signal SIGSEGV, Segmentation fault.
0xf7fd1f5d in ?? ()
Wine-gdb> bt
#0  0xf7fd1f5d in ?? ()
#1  0xf7fd9b90 in ?? ()

https://pastebin.com/yGBP9aFz

BTW, launcher binary does not crash under vanilla wine, showing anticheat module error.
But under proton it crashes before show any window

after downgrading mesa to 22.0 launcher popup shows, but says that failed to load anticheat module. How to load it manually? Proton version does not matter, all from 5.0 to experimental BE shows same error

Enabling cv-style DT_HASH fixed it:
https://forums.gentoo.org/viewtopic-p-8703494.html?sid=3b7962eda125b7eefef3e7212343885d#8703494

From what I understand, video players should be working without extra configuration, right? I've had no luck getting players to play. Latest pop os. Tried on proton 7.0-3 and experimental.

From what I understand, video players should be working without extra configuration, right? I've had no luck getting players to play. Latest pop os. Tried on proton 7.0-3 and experimental.

Sadly no.[^note]

Here is a list of all the issues related to video players that I know with a list of fix/patch

• You must use Proton Experimental or ProtonGE

• H264 Codec are not enabled by default (All of the solutions below will do the same thing)
  https://github.com/ValveSoftware/steam-for-linux/issues/6780

  • Open the Broadcasts page on steam
  • Put steam://unlockh264 in your browser and restart steam afterwards
  • Add "UnlockedH264Feature" "1" in ~/.local/share/Steam/userdata/ Your User ID /config/localconfig.vdf

• AVPro videos play upside down

  • Fixed with Experimental or ProtonGE 7-29 or newer

• AVPro videos Media Controls (Pause, Stop, Volume) doesn't work but you can play a video and stop it by changing world or video player if the world has an option to do so (AVPro -> Unity).

  • You can change the volume on the secondary audio track it creates

• Streams don't work

  • Use ProtonGE (Tested with Youtube & Twitch live stream)
    *Might not work with every video player or link
    [^note]:
    Comments from a VRChat Dev
    https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1181675104
    https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1183621006
    https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1196146054

Here is a list of all the issues related to video players that I know with a list of fix/patch

I see! After enabling H264 it's now working with proton experimental! Thank you very much ^^