Who here has a Youtube-DL compile for WinXP?

[nicolaasjan]

My releases have just been updated.

 

Quote

 

[ie/youtube] Fix default player clients (#15726)

* Add `ios_downgraded` player client

*Remove `android_sdkless` player client

Closes #15712 Authored by: bashonly

 

 

Edited Thursday at 08:29 AM by nicolaasjan

[VistaLover]

On 1/28/2026 at 11:27 PM, VistaLover said:

2026 is definitely NOT a good year so far, it seems...

More bad news (wrt YT and yt-dlp)  : 

https://github.com/yt-dlp/yt-dlp/issues/11868#issuecomment-2560431566

Quote

EDIT/UPDATE (2026/01/29):

YouTube is experimenting with some sort of new aggressive IP-based block on videoplayback urls - perhaps to replace or complement the existing "sign in to confirm you are not a bot" error on the player endpoint. This produces an HTTP 403 error on videoplayback urls, regardless of client and protocol (HTTPS, DASH, HLS, UMP, SABR, ONESIE).

If you are seeing this for the first time, backing off further downloading/requests for a little while may help to lift it. It is recommended to make use of the yt-dlp sleep options to help avoid it.

Otherwise, you might need to change IP.

Update: this comment for more details.

With the changes YouTube has been pushing recently, it is likely the out-of-the-box YouTube format support for yt-dlp will become more limited. To retain format support, we recommend looking into providing PO Tokens to yt-dlp.

Oh, BTW, the `--live-from-start` feature on LIVE YT streams is now BROKEN, too  : 

https://github.com/yt-dlp/yt-dlp/issues/15751

(if you ask me, it's all-out-war Google  have unleashed against the YT-downloading apps, but it appears they have their focus especially on yt-dlp  ) .

[NotHereToPlayGames]

Major bummer!

I've never actually used yt-dlp, but there is certainly a VERY large following.

I guess that shows the popularity of yt-dlp, the ONLY reason Google would "unleash" would be if TENS OF THOUSANDS of videos are being downloaded using this method.

Google really wouldn't "care" if we were talking a few here, a few there.  Or they're looking at it from how many PER DAY are "abusing the system", so to speak.

Edited Thursday at 11:42 PM by NotHereToPlayGames

[VistaLover]

On 1/28/2026 at 6:35 PM, VistaLover said:

I'll say that the ANDR-S formats are unreliable (YMMV): 

As attested already by @j7n, ALL ANDR-S formats are now being 403'd  ; in latest yt-dlp releases (stable, nightly, master update channels), the ANDR-S client has been removed: 

Quote

(official) master >= 2026.01.29.65728

By default, `android_vr, ios_downgraded, web, web_safari` is used. 
If no JavaScript runtime/engine is available, then `android_vr, ios_downgraded` is used. 

If logged-in cookies are passed to yt-dlp, then `tv_downgraded, web, web_safari` is used for free accounts and `tv_downgraded, web_creator, web` is used for premium accounts. 

The `web_music` client is added for `music.youtube.com` URLs when logged-in cookies are used. 
The `web_embedded` client is added for age-restricted videos but only works if the video is embeddable. 
The `tv_embedded` and `web_creator` clients are added for age-restricted videos if account age-verification is required. 
Some clients, such as `web` and `web_music`, require a `po_token` for their formats to be downloadable. 
Some clients, such as `web_creator`, will only work with authentication. Not all clients support authentication via cookies. 

You can use `default` for the default clients, or you can use `all` for all clients (not recommended). You can prefix a client with `-` to exclude it, e.g. `youtube:player_client=default,-ios`

 

18 hours ago, nicolaasjan said:

(JS runtime required)

The ios client m3u8 (aka HLS) formats are NOT behind an n/sig challenge, so a JS runtime shouldn't be needed for them, unless you also want the WEB-S client's m3u8 formats ...

17 hours ago, nicolaasjan said:

Well, I got it from a forum from a large country that is currently under heavy sanctions. 😳

Link to post.

Thanks ; that rules out, then, directly asking them for a NT 6.0 compatible version  ? (though I later realised that a "certain" member is there, too  ...)

17 hours ago, nicolaasjan said:

Maybe you can wake him up? 

I'll probably will, but likely over the coming weekend ...

Thanks for your precious time supporting "legacy" Windows OSes - you're a true hero  ...

Edited Thursday at 11:58 PM by VistaLover

[j7n]

The latest update to yt-dlp works out of the box again with an "ios downgraded" method. And there no sleep. They recommend it now, but there isn't. I didn't know you could use those conditionals [height<=1080][ext=mp4] which would help with changing format numbers.

Can you point me to instructions about how to use a "JS runtime" with yt-dlp on Win Seven? Is this an exe I drop or is there more to it?

[nicolaasjan]

6 hours ago, j7n said:

Can you point me to instructions about how to use a "JS runtime" with yt-dlp on Win Seven? Is this an exe I drop or is there more to it?

You can read all about it in the Wiki. 

Deno can't be used on Windows 7.

 

Node can be used if you use this fork.

Take node-v20.19.2-win-x64.zip. extract to e.g. C:\Bin\Node and add that folder to your PATH.

Can also be done via CMD as administrator:

setx /m PATH "%PATH%;C:\Bin\Node"

 

QuickJS can also be used, but it's rather slow (put qjs.exe and libwinpthread-1.dll next to yt-dlp.exe).

Then add to your config file:

--js-runtimes quickjs

Or:

--js-runtimes node

 

Edited yesterday at 09:34 AM by nicolaasjan

[Reino]

On 9/26/2025 at 5:21 PM, Reino said:

The reason why I prefer the iOS m3u8 HLS streams is because, unlike the DASH streams, they don't exhibit bandwidth "issues".
[...]
I take it I'm not the only one having experienced this?

For anyone not up to speed; the reason why this is happening has been revealed by one of yt-dlp's major contributors:

Quote

Seems like it's because YouTube's HTTPS protocol formats (i.e. the "DASH" streams you're referring to which are actually HTTPS formats) will be throttled if your HTTP chunk size exceeds 10MB. yt-dlp's native HTTP downloader will download in chunks no greater than 10MB to avoid this throttling. Many external downloaders/players either don't support limiting their HTTP chunk size (which is the case with ffmpeg and ffmpeg-based media players like mpv) or they don't know to do so unless you specifically configure them to. HLS is already served in segments that are <10MB in size, so you don't run into this problem with HLS formats.

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.

On 9/26/2025 at 5:21 PM, Reino said:

I hate ads, so I try to watch Youtube videos as much as possible directly with MPC-HC.

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?

Edited 9 hours ago by Reino
Corrections and improvements.

[Reino]

On 1/28/2026 at 3:58 PM, VistaLover said:

Soon-ish, no more youtube downloads without a JS runtime enabled (and without passing logged-in YT cookies, only the WEB-S client (HLS) formats would become available - these do require the JS runtime, though) ...

As I'm out of touch as far as WinXP is concerned... do none of the supported JS runtimes work on WinXP?

On 1/28/2026 at 5:47 AM, nicolaasjan said:

Test: yt-dlp-test.zip.

On 1/29/2026 at 8:28 AM, nicolaasjan said:

My releases have just been updated.

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?

Edited 10 hours ago by Reino

[VistaLover]

54 minutes ago, Reino said:

do none of the supported JS runtimes work on WinXP?

Only the official quickjs (32-bit) release natively supports Windows XP SP3 x86: 

https://bellard.org/quickjs/

https://bellard.org/quickjs/binary_releases/?C=M;O=D

https://bellard.org/quickjs/binary_releases/quickjs-win-i686-2025-09-13.zip

This fact has been stated earlier in this thread (but am lazy now to find the relevant post).

... And, if you're prepared to use "hacked-binaries" (binaries HexEdited to redirect XP-incompatible kernel functions to OCA/Wine/ReactOS DLLs, then there's this  : 

On 1/28/2026 at 9:15 PM, nicolaasjan said:

Special NodeJS for Windows XP:

Node_XP.7z

(the "appeal" of NodeJS vs quickjs is that the former is many times quicker (pun intended) compared to the latter  ...)

[VistaLover]

@nicolaasjan : Positive `quickjs-ng` developments  : 

https://github.com/quickjs-ng/quickjs/issues/1002#issuecomment-3826547072

[nicolaasjan]

5 hours ago, Reino said:

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?

I let the GitHub workflow build releases (which should be identical to upstream) and when that's done, I manually add my (custom Python) compiled versions in the web interface. 

After that, I use a Python script to fetch all the files and generate the SHA-256 and SHA-512 checksum files locally. Then replace the ones GitHub created with these, in order to make the (custom) update function* of my versions work.

(*after having synchronised my fork with upstream, I clone it locally and apply a diff to `./yt_dlp/update.py` and then use that source tree in my VM's to compile)

While the workflow is still running, I grab the version number from it and use that to update it in my builds as well:

Then locally e.g.:

python devscripts/update-version.py -c "nicolaasjan/yt-dlp" -r "nicolaasjan/yt-dlp" "2026.01.30.064627"
python devscripts/set-variant.py win7_exe
python -m bundle.pyinstaller

I admit it's a rather hacky procedure, but it works. 

[Reino]

59 minutes ago, nicolaasjan said:

I let the GitHub workflow build releases (which should be identical to upstream) [...]

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.