If you're using anything post-Windows 7, don't touch codec packs. That's an ancient way of doing things. I'm not going to do into depth about how stupid it is, but it's the wrong way to deal with these kinds of things. So that this doesn't come off as some elitist shove-off: It's up to software developers to go out of their way to add support for any n-coding (encoding, decoding), be it encoding or decoding, CPU-based (generic software libraries with compiler-based optimized routines or not, out-of-scope here) or GPU-based (which can also be software-based or hardware-accelerated). You can't just throw codecs at something expecting it to work, the software must be written to support even looking for specific ones. Adding in non-expected versions from packs is about as stupid as you can get, it can break any number of poorly-written software that may be fine because of lacking non-integrated codecs. It's just royally stupid stuff that held on from days when codecs were actually useful, Windows 7 and under. Now most software simply ship with ffmpeg (handles many actual formats) and/or rely on native (CPU or GPU-based, any fashion, be it driver-based or software-based that can be loaded) means of n-coding. Of course, this all relies on software developers envisioning the need for it in theirs and implementing it. If a software doesn't even know how to use a codec, let alone isn't even programmed to interact with it, it's 100% useless and won't do anything. Ren'Py may have some compensating effort, dunno. But codec-packing is old and severely out-dated, useful only for extremely ancient n-coders that should actually be installed separately in VMs isolated to interact with old software. In short, stop buying Intel GPUs until they have native OpenGL, Vulkan, VP8, VP9, HEVC (h265), or ask software developers to use ffmpeg (which handles almost anything out there, it's not a “codec pack”, it is one library meant to automatically use CPU or GPU-based means, think of it as an “end of all bull” effort to try to move beyond those ancient times.) In this particular case, the developer of the game should just re-encode the WebM files as MP4 and stick to h264 with lower resolution and quality. You don't need perfection. No game uses 1:1 fidelity, even on modern GPUs (brand-new ones). A single frame in 1:1 quality would be 6.22MB assuming 32-bit RGB, multiply that by 24 (rounded film FPS) and you're looking at about 150MB/s for true 1:1 32-bit quality. Of course, I'm talking about videos (because the game uses them). MP4, JPEG/PNG, for compatibility with older rigs.