Aright well I was gonna make a whole new thread for this but since this one is still somewhat active I’ll just post it here.
The latest round of Youtube player issues is entirely due to Youtube itself. There’s been a lot of in-depth discussion in the yt-dlp github repo about it, and it essentially comes down to (overly simplifying here) YouTube requiring browsers to process some Javascript nonsense before it will provide the actual video stream. If you use a non-Chrome browser that still allows UBlockOrigin to work, you’ll no doubt be familiar with the BS little “Having trouble? Find out why!” popup that appears whenever you go to watch anything (which then tells you to disable adblocking). The YT-in-VRC issue is similar; older versions of yt-dlp are unable to ‘correctly’ process the initial response(s) from Youtube, and as such, Youtube just spits back an error message/404/empty response.
(Brief aside: I’m calling out the video player prefab makers, as a software engineer of 20+ years: Please do better with your debug logging. A program shouldn’t give 8 potential reasons for an error at that log level (or no reason at all, like some players do).)
Anyway. While previous solutions of using the yt-dlp nightly build did work, it has slowly but surely become less reliable as Youtube has continued to make life more difficult for “Reasons”, and as of this past week (11th Nov 2025), the dev team have made the choice to require some form of Javascript runtime to be available to the yt-dlp executable at runtime so that it can correctly process the responses from Youtube. The program will still run without one (for now), but it will emit a warning if it can’t find one, and the devs will no longer be providing support for any bugs/issues/etc if the user reporting said issue doesn’t have one installed.
Obviously VRC staff cannot recommend doing any of this, because of all those fun things like ‘potential liability if they suggest something that borks your computer’ and ‘licensing conflicts of including precompiled binaries of open-source projects’ (and possibly even opening themselves up to legal shenanigans from Goog/YT/Alphabet if they decide to pull the ‘bypassing access control mechanisms’ card).
If you do anything mentioned below, keep in mind that you do so at your own risk, and neither I nor VRChat can be held responsible if you download something that breaks your PC.
Having said that, though, if one were to download the yt-dlp nightly build, along with a Javascript runtime (the yt-dlp devs recommend ‘Deno’; the latter offers a nice single precompiled binary), and place those into the VRC Tools directory, there is a very high probability that YouTube videos will work for you in-game. Keep in mind that VRC appears to re-download their version of yt-dlp every time you load a world with a video player in it, so either setting the yt-dlp binary read-only, or copying it back in after loading the world is necessary.
(Aside: I’m not entirely certain if the same solution will work under Linux; I’ve got VRC running very nicely in Cachy with Proton and WiVRn, but still spend most of my playtime in Windows because Substance Painter refuses to run in Wine (sadface).)
So there you have it. Unfortunately, VRChat has about as much power over what YouTube decides to do in their pursuit of (ad revenue/user data collection/anti-adblocking/etc) as, well, any of us do. I don’t know what sorts of customization VRC does with the yt-dlp binary (and I suspect if I asked they wouldn’t/couldn’t tell me anyway), but at least at this point, it’s not as simple as them just updating the version they distribute to end users. (Though if I may be a snarky little b*tch for a moment, I’d have preferred they spend more cycles on this than ‘boops’, but whatever.)