Reino

They are actually and always have been. I don't update the upstream script anymore, but all that I locally changed was "openssl-3.3.1" to "openssl-3.6.1". https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/master/ffmpeg_local_builds/cross_compile_ffmpeg.sh#L78-L104 C:\>openssl.exe version -a OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026) built on: Sat Jan 31 22:56:33 2026 UTC platform: mingw options: bn(64,32) compiler: /cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -m32 -O2 -march=pentium3 -mtune=athlon-xp -mfpmath=sse -msse -DL_ENDIAN -DOPENSSL_PIC -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -D_MT -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG -D_WIN32_WINNT=0x501 OPENSSLDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/ssl" ENGINESDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/engines-3" MODULESDIR: "/cygdrive/e/ffmpeg-windows-build-helpers-master/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32/lib/ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0xfed8320b078bffff:0x00405fc6f1bf97a9:0x0000003000000110:0x0000000000000000:0x0000000000000000 The last time I've updated the "MingGW-w64 Build Script" was 18 Sep 2022.

Then why do you need mine? While I was at it (compiling OpenSSL) I've had a look at this, but I couldn't compile quickjs. The culprit is undoubtedly "Add cross-platform Atomics support". I think it will be extremely difficult to restore WinXP compatibility. Attempting this at all, I think a patch similar to how I (with the help of Gianluigi "sherpya" Tiesi) restored WinXP compatibility to libaom back in the day is needed. We could ask him to have a look?

I have no experience with Github workflow at all, but you can't set it up to utilize the latest Python and OpenSSL as well? I thought these are still WinXP compatible, are they not? Anyway... despite a small bump in the road I've compiled and uploaded OpenSSL 3.6.1.

But to be clear; if you value the fact that your custom builds are compiled with the latest OpenSSL, then you shouldn't use `-U`, I guess? I mean... C:\>yt-dlp_nicolaasjan.exe -v [...] [debug] Python 3.14.2 (CPython AMD64 64bit) - Windows-11-10.0.26200-SP0 (OpenSSL 3.6.1 27 Jan 2026) C:\>yt-dlp_nicolaasjan.exe -U [...] Updated yt-dlp to stable@2026.01.29 from yt-dlp/yt-dlp C:\>yt-dlp_nicolaasjan.exe -v [...] [debug] Python 3.10.11 (CPython AMD64 64bit) - Windows-10-10.0.26200-SP0 (OpenSSL 1.1.1t 7 Feb 2023) The initial 'yt-dlp_nicolaasjan.exe' is from yt-dlp-test.zip. And btw, it updates from "yt-dlp/yt-dlp" instead of "nicolaasjan/yt-dlp". Or am I missing something? I thought you managed to compile it yourself...

I know your custom (test-)builds in the past either had some extras or left out some specific upstream changes. Why then set up this Github workflow if there's no difference compared to upstream? I try to understand.

As I'm out of touch as far as WinXP is concerned... do none of the supported JS runtimes work on WinXP? It's obvious you manually create the test-builds with the latest Python and OpenSSL versions, but what about the Github releases? What exactly are the differences between these and the official yt-dlp builds?

For anyone not up to speed; the reason why this is happening has been revealed by one of yt-dlp's major contributors: A lot has changed recently, so I've done some new testing. ios For me personally this player_client still works without a Javascript runtime and a 403 HTTP Error. Compared to me previous post `;formats=missing_pot` is needed though: FOR /F "delims=" %A IN (' yt-dlp.exe --extractor-args "youtube:player_client=ios;formats=missing_pot" -f "(bv[width<=1920]+ba)[protocol^=m3u8]" -O urls "https://www.youtube.com/watch?v=###########" ') DO @IF NOT DEFINED url[0] (SET url[0]=%A) ELSE (SET url[1]=%A) "C:\Program Files\MPC-HC\mpc-hc64.exe" "%url[0]%" /dub "%url[1]%" /close This oldschool method works fine, but as it requires two separate commands I always use my favorite command-line tool Xidel to create the following one-liner: FOR /F "delims=" %A IN ('yt-dlp.exe --extractor-args "youtube:player_client=ios;formats=missing_pot" -f "(bv[width<=1920]+ba)[protocol^=m3u8]" -O urls "https://www.youtube.com/watch?v=###########" ^| xidel -se "let $url:=x:lines($raw) return `\"C:\\Program Files\\MPC-HC\\mpc-hc64.exe\" \"{$url[1]}\" /dub \"{$url[2]}\" /close`"') DO @%A FOR /F "delims=" %A IN (' yt-dlp.exe --extractor-args "youtube:player_client=ios;formats=missing_pot" -f "(bv[width<=1920]+ba)[protocol^=m3u8]" -O urls "https://www.youtube.com/watch?v=###########" ^| xidel -se "let $url:=x:lines($raw) return `\"C:\\Program Files\\MPC-HC\\mpc-hc64.exe\" \"{$url[1]}\" /dub \"{$url[2]}\" /close`" ') DO @%A As an alternative to... -f "(bv[width<=1920]+ba)[protocol^=m3u8]" ...you could also use... -f "bv[width<=1920]+ba" -S "+proto" --format-sort-force web_safari This player_client does require a Javascript runtime (I'm using deno). It only provides the m3u8 protocol formats (audio and video combined), so no filtering is needed, which makes the one-liner very simple: FOR /F "delims=" %A IN (' yt-dlp.exe --extractor-args "youtube:player_client=web_safari" -f "[width<=1920]" -O urls "https://www.youtube.com/watch?v=###########" ') DO @"C:\Program Files\MPC-HC\mpc-hc64.exe" "%A" /close I'm not sure if this player_client provides anything larger than 1080p. If it doesn't, then `-f "[width<=1920]"` isn't needed. As mentioned earlier, most of the time I now use LibreWolf to watch ad-free Youtube videos. I do remember getting the "Sign in to confirm you’re not a bot." message after having watched a dozen Youtube videos through yt-dlp and MPC-HC. Maybe "--impersonate firefox" could prevent that from happening?

Seeing you've included my 'libcrypto-3.dll' and 'libssl-3.dll' within your 'Python311_XP-folder.7z', I guess that's my confirmation.

Thank you, @davidz. @VistaLover, you're right. If my old pc wouldn't have died, then I definitely would've continued compiling FFmpeg. But in the end I indeed don't regret it at all. I've gone from a single core AMD Athlon XP 3200+ to an 8 core (16 threads) AMD Ryzen AI Max 385 (Framework Desktop, see photos), with an integrated iGPU (Radeon 8050S) that is as powerful as an AMD Radeon RX 6600 XT. And let's not forget the NVME SSDs. The transition is enormous! Right now only the monitor I'm using is still my old Samsung SyncMaster 203B (1400x1050@60Hz), because I'm waiting for the ASUS ROG Strix OLED XG27AQWMG (2560x1440@280Hz) to become available. For the OS I took the chance and installed Windows X-Lite instead of the normal Win11 Pro iso. Despite all the negative comments on Win11 at the moment, I absolutely love it! Very fast, light and responsive. Never regretted it. My main internetbrowser is still Pale Moon (on WinXP it was New Moon obviously), but my absolute secondary one is LibreWolf. A lot of websites nowadays just don't work anymore with Pale Moon. I'm now typing this message also in LibreWolf. Also with the integrated uBlock Origin add-on I can watch Youtube videos uninterupted. Absolutely amazing!

What piece of software is that? I know Dependency Walker, but this is not it.

I've uploaded v3.6.0 (for which my AMD Ryzen AI MAX 385 for the first time did all the hard, and particularly quick, work). Please confirm it works on WinXP.

You spoke too soon. This is not an issue at all. As commented by xpalidotious, the video is mostly static, which means a low(er) bitrate would suffice for a targeted image quality.

It does. Thank you! I can confirm, the binary works on Win11 Pro (on my brand new Framework Desktop).

Confirmed. Thanks.

https://github.com/yt-dlp/yt-dlp/issues/14456#issuecomment-3339167951: --extractor-args "youtube:player-client=default,-tv_simply"