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.