Who here has a Youtube-DL compile for WinXP?

[nicolaasjan]

2 hours ago, reboot12 said:

ffmpeg with full possibilities (~100 MB) - I don't know - probably couple hours ?

At the moment I'm using this one (GitHub built it in 40min):

https://github.com/BnqDzj/FFmpeg-Builds-nonfree/releases

It has all features you can think of.

I do admit it's rather large, haha.

ffmpeg version N-124387-gaa14727cd5-20260504 Copyright (c) 2000-2026 the FFmpeg developers
built with gcc 15.2.0 (crosstool-NG 1.28.0.23_185f348)
configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-ffbuild-linux-gnu- --arch=x86_64 --target-os=linux --enable-nonfree --enable-gpl --enable-version3 --disable-debug --enable-iconv --enable-zlib --enable-libxml2 --enable-libsoxr --enable-openssl --enable-libvmaf --enable-fontconfig --enable-libharfbuzz --enable-libfreetype --enable-libfribidi --enable-vulkan --enable-libshaderc --enable-libvorbis --enable-libxcb --enable-xlib --enable-libpulse --enable-opencl --enable-gmp --enable-lzma --enable-liblcevc-dec --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 --enable-libdvdread --enable-libdvdnav --enable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libkvazaar --enable-libaribcaption --enable-libass --enable-libbluray --enable-libjxl --enable-libmp3lame --enable-libopus --enable-libplacebo --enable-librist --enable-libssh --enable-libtheora --enable-libvpx --enable-libwebp --enable-libzmq --enable-lv2 --enable-libvpl --enable-openal --enable-liboapv --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-librubberband --disable-schannel --enable-sdl2 --enable-libsnappy --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --enable-libdrm --enable-vaapi --enable-libvidstab --enable-libvvenc --enable-whisper --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-libs='-lgomp -ldl' --extra-ldflags=-pthread --extra-ldexeflags=-pie --cc=x86_64-ffbuild-linux-gnu-gcc --cxx=x86_64-ffbuild-linux-gnu-g++ --ar=x86_64-ffbuild-linux-gnu-gcc-ar --ranlib=x86_64-ffbuild-linux-gnu-gcc-ranlib --nm=x86_64-ffbuild-linux-gnu-gcc-nm --extra-version=20260504
libavutil      60. 30.100 / 60. 30.100
libavcodec     62. 30.100 / 62. 30.100
libavformat    62. 13.102 / 62. 13.102
libavdevice    62.  4.100 / 62.  4.100
libavfilter    11. 17.100 / 11. 17.100
libswscale      9.  7.100 /  9.  7.100
libswresample   6.  4.100 /  6.  4.100

 

[reboot12]

9 minutes ago, nicolaasjan said:

It has all features you can think of.

I'm sorry, but I'm a minimalist and I'm irritated by such oversized applications, unnecessary code in scripts or source code. Recently, I have been compiling a lot tools in various environments: Linux with edk2, UEFI, MinGW, Windows with WinDDK, Visual Studio and I try to make the code as readable as possible without unnecessary lines, so that the compiled tool does only what it is supposed to do. My latest tools - all for WinXP 64-bit: ffmpeg, flashrom, UefiMenu

[nicolaasjan]

6 minutes ago, reboot12 said:

Visual Studio

I had it installed some time ago, but good havens that is bloated. Removed it.

What can you suggest as a more lightweight compiler for Windows?

[reboot12]

43 minutes ago, nicolaasjan said:

What can you suggest as a more lightweight compiler for Windows?

One environment will not be universal for everything - it depends on many things:

• what are you compiling and what is your source code - c, c+, c++, rust, etc.
• whether the code is old or new
• on what system the application is to be used - old XP or only new Vista and newer

As I wrote, I compile all tools to work under WinXP 64-bit because they are simply missing. Recently I tried compiling flashrom 1.2 - first attempt MinGW+MSYS on Windows - failed, next attempt MinGW on Ubuntu 24 - failed. All I had to do was change Ubuntu to an older version, e.g. 16, and I could compile the application normally

Other my tool UefiMenu + Windows driver I compile in WDK 7600.16385.1 and UEFI loader in same Ubuntu 16:

Another one tool setcsum - I compiled in Visual Studio 2005

Edited May 4 by reboot12

[nicolaasjan]

@reboot12

Hmm...

That looks rather complicated to do on Windows (I'm old...).

Maybe I'll just have to learn to cross-compile FFmpeg on Linux with the native tools available.

The thing is, the MinGW environment also has to be installed (1136MB).

[Mark-XP]

1 hour ago, nicolaasjan said:

That looks rather complicated to do on Windows (I'm old...).

The thing is, the MinGW environment also has to be installed (1136MB).

I'm getting too old for much of the new stuff too - a 1GB+ build environment would definitely be unacceptable for me.

Btw.: your yt-dlp (version 2026.01.29.071857) runs flawlessly here since end of january (on "Bullseye")

[nicolaasjan]

6 hours ago, Mark-XP said:

Btw.: your yt-dlp (version 2026.01.29.071857) runs flawlessly here since end of january (on "Bullseye")

You mean yt-dlp_linux_x86 ?

B.t.w., Debian Bullseye support will end August 31 2026 and Debian Trixie is 64-bit only.

So, I'll have to reconsider building yt-dlp for 32-bit on my LMDE VM, which will also lose support then...

[autodidact]

On 5/1/2026 at 4:17 AM, K4sum1 said:

I'm curious how you worked around w32pthreads.h? It calls for multiple Vista+ functions like SRW locks and such, but I find no mention of the file in any patch.

I think if you are using a pre-built mingw toolchain, most are the default minimum of Windows 7 so the winpthreads will be incompatible with Windows XP.
I built a XP compatible toolchain from scratch to avoid those problems.  The @Reino script also does that and uses pthreads-w32.

[Mark-XP]

16 hours ago, nicolaasjan said:

You mean yt-dlp_linux_x86 ?

B.t.w., Debian Bullseye support will end August 31 2026 and Debian Trixie is 64-bit only.

The exexutable's original name was 'yt-dlp_linux' (which incorporates a python-3.10+ runtime) so there's no need to build/brew the python-3.12.5 runtime here (which i did for testing - but only on one development disk).

And yes, i'm planing an upgrade to bookworm/trixie/forky later this year (but not very enthusiastic tbh. )

[nicolaasjan]

[Announcement] ejs is dropping support for Node v20 and v21 

Quote

 

Node (aka Node.js) is an ejs-compatible JavaScript runtime.

Node v20 reached its end-of-life (EOL) at the end of April 2026. Node v21, which is not a long-term support (LTS) version of Node, reached its end-of-life well before that.

As of the next yt-dlp and/or ejs release, the minimum supported version of Node will be raised to v22.

Going forward, yt-dlp/ejs intends to mostly align with the Node.js support lifecycle, with a notable exception: yt-dlp/ejs will continue to support the non-LTS (odd-numbered) major versions that are above our support floor for as long as they work.

 

There is a request for Node 22/24 on vladimir-andreevich/node.js-windows-7 but there is no answer yet.

Edited May 21 by nicolaasjan

[johk]

I'm not going to get in to details, but I had to switch to the old resolver to test a couple of things and I also tested yt-dlp.

And surprise (what else would I be here for?), the curl_cffi component of yt-dlp that was theoretically responsible for the DNS extensions request problem, look like doesn't require the DNS extensions now :-?

I just wanted to post it. I don't care about the reasons (I'm not going to dig on it). Just mention it.

[VistaLover]

There has been a new release (finally ) by its author, Bellard, of the quickjs JS runtime, necessary for de-scrambling YouTube's nsig challenges (present on most yt_player_clients, except for ANDR-V); the 32-bit binary can be found on: 

https://bellard.org/quickjs/binary_releases/quickjs-win-i686-2026-06-04.zip

(64-bit binary: https://bellard.org/quickjs/binary_releases/quickjs-win-x86_64-2026-06-04.zip)

quickjs is the only supported JS runtime on "legacy" WinOSes, like XP SP3/Vista SP2/Win7 SP1; I can't check on XP SP3 x86, but the new release does launch here (Vista SP2 x86):

qjs -h =>

QuickJS version 2026-06-04
usage: qjs [options] [file [args]]
-h  --help         list options
-e  --eval EXPR    evaluate EXPR
-i  --interactive  go to interactive mode
-m  --module       load as ES6 module (default=autodetect)
    --script       load as ES6 script (default=autodetect)
    --strict       force strict mode
-I  --include file include an additional file
    --std          make 'std' and 'os' available to the loaded script
-T  --trace        trace memory allocation
-d  --dump         dump the memory usage stats
    --memory-limit n  limit the memory usage to 'n' bytes (SI suffixes allowed)
    --stack-size n    limit the stack size to 'n' bytes (SI suffixes allowed)
    --no-unhandled-rejection  ignore unhandled promise rejections
-s                    strip all the debug info
    --strip-source    strip the source code
-q  --quit         just instantiate the interpreter and quit

Additionally, the quickjs-ng fork has also seen a new release: 

https://github.com/quickjs-ng/quickjs/releases/tag/v0.15.1

https://github.com/quickjs-ng/quickjs/releases/download/v0.15.1/qjs-windows-x86.exe

This runtime officially supports Win7 SP1 and later, but it can also work under Vista SP2 (but NOT on XP SP3): 

qjs -h =>

QuickJS-ng version 0.15.1
usage: qjs [options] [file [args]]
-h  --help         list options
-v  --version      print version string and then exit
-e  --eval EXPR    evaluate EXPR
-i  --interactive  go to interactive mode
-C  --script       load as JS classic script (default=autodetect)
-m  --module       load as ES module (default=autodetect)
-I  --include file include an additional file
    --std          make 'std', 'os' and 'bjson' available to script
-T  --trace        trace memory allocation
-d  --dump         dump the memory usage stats
-D  --dump-flags   flags for dumping debug data (see DUMP_* defines)
-c  --compile FILE compile the given JS file as a standalone executable
-o  --out FILE     output file for standalone executables
    --exe          select the executable to use as the base, defaults to the current one
    --memory-limit n       limit the memory usage to 'n' Kbytes
    --stack-size n         limit the stack size to 'n' Kbytes
-q  --quit         just instantiate the interpreter and quit

Both are fully supported by latest yt-dlp; performance-wise, they shouldn't differ much, if at all...

[johk]

I could say that on same video test, about of 3 seconds less, from about 12 seconds to 9-10. That's about a 25%, not the 42% stated, on my Core 2 Duo, but less would have been nothing :)

[autodidact]

FFmpeg update.

XP:  static  shared  libfdk-aac

VISTAx86:  shared  static  libfdk-aac

Edited Wednesday at 08:46 PM by autodidact
Add XP shared

[VistaLover]

5 hours ago, johk said:

not the 42% stated

You're referring to the quickjs release claim, stated below: 

 https://bellard.org/quickjs/

Quote

2026-06-04:

New release (Changelog). It is 42% faster than the previous release based on the bench-v8 (aka v8-v7) score.

... but they specifically mention the "bench-v8 (aka v8-v7) score", which I'm certain doesn't take into consideration using the library together with yt-dlp (especially on old, under-powered, H/W like the one many of us here use ) ... In any case, any performance improvement in general should have a beneficial impact even to us using quickjs for "youtube.com" purposes, and this is something that you verified yourself  ...