VistaLover

Do note that the OpenSSL-3.x.x DLLs are actually integral parts of every CPython for Windows higher than py3.10 (CPython-3.10.x, by default, uses OpenSSL-1.1.1.x), so they're not necessarily linked to just "YouTube downloaders" ; any other python application/script requiring py3.11+ may use those... libeay32.dll+ssleay32.dll are part of very old/insecure OpenSSL versions, the last branch that used them was the 1.0.2.x one; the 1.1.x.x branches used DLLs named libcrypto-1_1.dll and libssl-1_1.dll; BTW, TLSv1.3 support was first introduced with the OpenSSL-1.1.1.x series; so, your "legacy applications" can only use up to TLSv1.2 when connecting to the web...

Sure ; it loads fine: yt-dlp_x86 -v => [debug] Command-line config: ['-v'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out cp1253 (No VT), error cp1253 (No VT), screen cp1253 (No VT) [debug] yt-dlp version nicolaasjan/yt-dlp@2026.02.01.063416 (win7_x86_exe*) [debug] Python 3.14.2 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.6.1 27 Jan 2026) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.4.0 [debug] JS runtimes: none [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1856 extractors Usage: yt-dlp_x86 [OPTIONS] URL [URL...] yt-dlp_x86: error: You must provide at least one URL. Type yt-dlp --help to see a list of all options. and: yt-dlp_x86 -vF "jxm5zcK27qo" --js-runtime quickjs [debug] Command-line config: ['-vF', 'jxm5zcK27qo', '--js-runtime', 'quickjs'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT) [debug] yt-dlp version nicolaasjan/yt-dlp@2026.02.01.063416 (win7_x86_exe*) [debug] Python 3.14.2 (CPython AMD64 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.6.1 27 Jan 2026) [debug] exe versions: ffmpeg 5.0 (fdk,setts) [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.4.0 [debug] JS runtimes: quickjs-ng-0.11.0 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1856 extractors [debug] [youtube] [pot] PO Token Providers: none [debug] [youtube] [pot] PO Token Cache Providers: memory [debug] [youtube] [pot] PO Token Cache Spec Providers: webpo [debug] [youtube] [jsc] JS Challenge Providers: bun (unavailable), deno (unavailable), node (unavailable), quickjs [youtube] Extracting URL: jxm5zcK27qo [youtube] jxm5zcK27qo: Downloading webpage [debug] [youtube] Forcing "main" player JS variant for player 3510b6ff original url = /s/player/3510b6ff/player_es6.vflset/en_US/base.js [youtube] jxm5zcK27qo: Downloading android vr player API JSON [debug] [youtube] jxm5zcK27qo: android_vr player response playability status: UNPLAYABLE [youtube] jxm5zcK27qo: Downloading web embedded client config [debug] [youtube] jxm5zcK27qo: Detected experiment to bind GVS PO Token to video ID for web_embedded client [youtube] jxm5zcK27qo: Downloading player 3510b6ff-main [youtube] jxm5zcK27qo: Downloading web embedded player API JSON [youtube] jxm5zcK27qo: Downloading web safari player API JSON [debug] [youtube] jxm5zcK27qo: Detected a 6s ad skippable after 5s for web_safari [youtube] [jsc:quickjs] Solving JS challenges using quickjs [debug] [youtube] [jsc:quickjs] Using challenge solver lib script v0.4.0 (source: python package, variant: minified) [debug] [youtube] [jsc:quickjs] Using challenge solver core script v0.4.0 (source: python package, variant: minified) WARNING: [youtube] [jsc:quickjs] QuickJS-NG is missing some optimizations making this very slow. Consider using upstream QuickJS instead. [debug] [youtube] [jsc:quickjs] Running QuickJS: '<redacted>\yt-dlp\Builds\Nightly\nicolaasjan\py3.14\2026.02.01.63416\PyInst-6.18\qjs.EXE' --script 'C:\Users\<redacted>\AppData\Local\Temp\tmpfsvkg2za.js' [youtube] jxm5zcK27qo: Downloading m3u8 information [debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec, channels, acodec, lang, proto [debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec, channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id [info] Available formats for jxm5zcK27qo: ID EXT RESOLUTION FPS CH | FILESIZE TBR PROTO | VCODEC VBR ACODEC ABR ASR MORE INFO ---------------------------------------------------------------------------------------------------------------------------- sb3 mhtml 48x27 0 | mhtml | images storyboard sb2 mhtml 80x45 0 | mhtml | images storyboard sb1 mhtml 160x90 0 | mhtml | images storyboard sb0 mhtml 320x180 0 | mhtml | images storyboard 249 webm audio only 2 | 44.09MiB 51k https | audio only opus 51k 48k [en] low, WEB-E, webm_dash 250 webm audio only 2 | 57.96MiB 67k https | audio only opus 67k 48k [en] low, WEB-E, webm_dash 140 m4a audio only 2 | 112.28MiB 129k https | audio only mp4a.40.2 129k 44k [en] medium, WEB-E, m4a_dash 251 webm audio only 2 | 113.71MiB 131k https | audio only opus 131k 48k [en] medium, WEB-E, webm_dash 91 mp4 256x144 24 | ~153.75MiB 177k m3u8 | avc1.4D400C mp4a.40.5 [en] WEB-S 160 mp4 256x144 24 | 58.06MiB 67k https | avc1.4d400c 67k video only 144p, WEB-E, mp4_dash 278 webm 256x144 24 | 63.73MiB 73k https | vp9 73k video only 144p, WEB-E, webm_dash 394 mp4 256x144 24 | 61.83MiB 71k https | av01.0.00M.08 71k video only 144p, WEB-E, mp4_dash 92 mp4 426x240 24 | ~276.63MiB 319k m3u8 | avc1.4D4015 mp4a.40.5 [en] WEB-S 133 mp4 426x240 24 | 111.89MiB 129k https | avc1.4d4015 129k video only 240p, WEB-E, mp4_dash 242 webm 426x240 24 | 120.41MiB 139k https | vp9 139k video only 240p, WEB-E, webm_dash 395 mp4 426x240 24 | 101.99MiB 118k https | av01.0.00M.08 118k video only 240p, WEB-E, mp4_dash 93 mp4 640x360 24 | ~697.64MiB 804k m3u8 | avc1.4D401E mp4a.40.2 [en] WEB-S 134 mp4 640x360 24 | 196.77MiB 227k https | avc1.4d401e 227k video only 360p, WEB-E, mp4_dash 18 mp4 640x360 24 2 | ≈308.67MiB 356k https | avc1.42001E mp4a.40.2 44k [en] 360p, WEB-E 243 webm 640x360 24 | 247.24MiB 285k https | vp9 285k video only 360p, WEB-E, webm_dash 396 mp4 640x360 24 | 182.68MiB 211k https | av01.0.01M.08 211k video only 360p, WEB-E, mp4_dash 94 mp4 854x480 24 | ~919.27MiB 1060k m3u8 | avc1.4D401E mp4a.40.2 [en] WEB-S 135 mp4 854x480 24 | 357.67MiB 412k https | avc1.4d401e 412k video only 480p, WEB-E, mp4_dash 244 webm 854x480 24 | 327.75MiB 378k https | vp9 378k video only 480p, WEB-E, webm_dash 397 mp4 854x480 24 | 262.34MiB 303k https | av01.0.04M.08 303k video only 480p, WEB-E, mp4_dash 95 mp4 1280x720 24 | ~ 1.17GiB 1387k m3u8 | avc1.4D401F mp4a.40.2 [en] WEB-S 136 mp4 1280x720 24 | 621.36MiB 717k https | avc1.4d401f 717k video only 720p, WEB-E, mp4_dash 247 webm 1280x720 24 | 538.63MiB 621k https | vp9 621k video only 720p, WEB-E, webm_dash 398 mp4 1280x720 24 | 425.20MiB 490k https | av01.0.05M.08 490k video only 720p, WEB-E, mp4_dash 96 mp4 1920x1080 24 | ~ 3.12GiB 3685k m3u8 | avc1.640028 mp4a.40.2 [en] WEB-S 137 mp4 1920x1080 24 | 1.34GiB 1577k https | avc1.640028 1577k video only 1080p, WEB-E, mp4_dash 248 webm 1920x1080 24 | 830.37MiB 958k https | vp9 958k video only 1080p, WEB-E, webm_dash 399 mp4 1920x1080 24 | 641.86MiB 740k https | av01.0.08M.08 740k video only 1080p, WEB-E, mp4_dash Do note, though, that "my Vista" system (SP2 32-bit) is fully updated till Vista SP2's EoL, with very little WS2008 updates and no ESU ones ; but the Win10 UCRT update (a Vista SP2 one) is indeed installed here ...

Many thanks for your follow-up , which actually sets the record straight ; and thanks for the re-upload ! Best regards.

FWIW, I don't believe that the slproweb distributed binaries have been optimised to load on SSE-only CPUs (I don't have the ability to test this hypothesis, though ), which is the case with Reino's DLLs. Personally, I prefer his for TLS-fingerprinting reasons... During recent months, many popular web services have been put behind aggressive anti-bot/anti-AI filters run by Cloudflare ; these filters treat web requests by yt-dlp as originating from a non-browser client (this is true, of course ) and block them "with prejudice" . On supported platforms (Windows 64-bit >= Win7), these blocks can be mitigated (not always successfully) by using the optional curl_cffi yt-dlp dependency and the associated "--impersonate" cmdline flag; but on 32-bit, especially when < Win7, this method can't be used ... One has to try other means of modifying yt-dlp's web requests, so as for them to have TLS fingerprints slightly different from the values inside CF's blocklists; in some cases, the use of the "--legacy-server-connect" flag might be enough, but usually it's not... Another method is to load the web service in a sanctioned browser, then extract session cookies and pass them to yt-dlp, along with the exact --user-agent the cookies came from; doesn't always work. If you are in a position to update the OpenSSL version bundled with the CPython installation used to launch yt-dlp with, then you have best hopes of beating CF's block (because their blocklists contain values generated from "stock" CPython versions, containing whatever "default" OpenSSL version assigned by PSF; usually one of the 3.0.x LTS branch). It's under the above scenario that Reino's DLLs can prove most helpful, because a) with their "special" configuration, they generate TLS-fingerprints deviating (in a good way) from a standard/mainline OpenSSL binary (like the ones from slproweb/overbyte) b) the link to them is less "prominent" in the web, so less prone to be found by CF personnel/bots and their TLS-fingerprints added inside an anti-bot filter; I have found these DLLs to be quite successful in "tough" cases, like the "dailymotion.com" one; so, many thanks Reino for those ... Best regards.

Respectfully, this doesn't add up at all with my findings, which should be possible to reproduce by others (and why would I publicly post untruths in the first place? ) ... I'm always talking about the 3.6.1 (32-bit) DLLs contained in the following archive: https://rwijnsma.home.xs4all.nl/files/openssl/openssl-3.6.1-win32-shared-dev-xpmod-sse.7z As I've posted previously in this thread, I keep a 2017-era copy of MABS (media-autobuild-suite) and if the DLLs had indeed been stripped, then submitting them to a "second" strip-treatment wouldn't result in filesize reduction; however, as I've posted already, I noticed that: Proof from an actual mintty window: OTOH, your static openssl.exe (32-bit) binary contained inside archive https://rwijnsma.home.xs4all.nl/files/openssl/openssl-3.6.1-win32-static-dev-xpmod-sse.7z is indeed a "stripped" binary, because: Regards.

I investigated this myself and the reason appears to be that @Reino's DLLs haven't been "stripped" post successful compilation : https://en.wikipedia.org/wiki/Strip_(Unix) In an MSYS2 environment, $ strip libssl-3.dll will reduce the filesize from 1.22 MiB to just 890 KiB, while $ strip libcrypto-3.dll will reduce the filesize from 5.20 MiB to just 3.88 MiB Finally, as a general observation, different compilers will produce binaries with different filesizes, even when the source code is always the same; and, of course, using different compilation flags between two different compiler invocations will also produce binaries with (slightly?) different filesizes, even when the compiler and source remain unchanged... The DLLs obtained from slproweb were compiled using a "CL" compiler (MSVC C/C++), as you can see by running: openssl version -a => OpenSSL 3.6.1 27 Jan 2026 (Library: OpenSSL 3.6.1 27 Jan 2026) built on: Wed Jan 28 15:01:03 2026 UTC platform: VC-WIN32 options: bn(64,32) compiler: cl /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -D"OPENSSL_BUILDING_OPENSSL" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"NDEBUG" -D_USE_32BIT_TIME_T -D_WINSOCK_DEPRECATED_NO_WARNINGS -D_WIN32_WINNT=0x0501 OPENSSLDIR: "C:\Program Files (x86)\Common Files\SSL" ENGINESDIR: "C:\Program Files (x86)\OpenSSL\lib\engines-3" MODULESDIR: "C:\Program Files (x86)\OpenSSL\lib\ossl-modules" Seeding source: os-specific CPUINFO: OPENSSL_ia32cap=0x0000e39defebffff:0x0000000000000000:0x0000000000000000:0x0000000000000000:0x0000000000000000 These two are also linked to vcruntime140.dll (external MSVC dependency, thus this further reduces the DLLs's filesize). My educated guess is that Reino's DLLs were compiled with some flavour of MinGW/MSYS2 (as can be deduced from the linked GH issue ), and that compiler is known to produce larger binaries than MS's Visual Studio (but I could be wrong somewhere, without knowing all the finer details ) ...

... You'd also need to use "special" actions to: 1) explicitly request and setup adang1345's CPython mod (NT 6.0+ compatible); Microsoft's GitHub probably only knows of the official PSF versions (Win10+) 2) explicitly request and install a "special" version (fork) of PyInstaller to compile the yt-dlp "Win7" binaries (which are also compatible with Vista SP2). CPython versions, the PSF ones or even adang1345's, come with embedded OpenSSL binaries; IIUC, currently the swap of them with updated OpenSSL DLLs (e.g 3.6.1) is mainly a manual job; I can't imagine how this could be done in the context of a workflow, but what do I know? ... Many thanks, indeed ...

https://github.com/quickjs-ng/quickjs/pull/1324 has been merged into master: https://github.com/quickjs-ng/quickjs/commit/e85ae372edf32882c8b877cd770fe485f2b05147 Latest GHA workflow that has this implemented: https://github.com/quickjs-ng/quickjs/actions/runs/21545069744?pr=1324 win 32-bit binary (you only need the qjs-windows-x86.exe one): https://github.com/quickjs-ng/quickjs/actions/runs/21545069744/artifacts/5328824393 win 64-bit binary (you only need the qjs-windows-x86_64.exe one): https://github.com/quickjs-ng/quickjs/actions/runs/21545069744/artifacts/5328823672 Codewise, these artifacts correspond to a quickjs-ng-v0.11.0-77-git-20260131-g3213652 snapshot... Well, I never claimed any WinXP-compatibility myself ; the app authors officially support Win7+: https://quickjs-ng.github.io/quickjs/supported_platforms About the "InitOnceExecuteOnce" error thrown on WinXP: https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initonceexecuteonce So, I'm really "lucky" the app (even) runs on NT 6.0 (and "unofficial" Vista SP2 compatibility isn't a "given", as far as official support goes ) ...

@nicolaasjan : Positive `quickjs-ng` developments : https://github.com/quickjs-ng/quickjs/issues/1002#issuecomment-3826547072

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 : (the "appeal" of NodeJS vs quickjs is that the former is many times quicker (pun intended) compared to the latter ...)

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: 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 ... 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 ...) I'll probably will, but likely over the coming weekend ... Thanks for your precious time supporting "legacy" Windows OSes - you're a true hero ...

More bad news (wrt YT and yt-dlp) : https://github.com/yt-dlp/yt-dlp/issues/11868#issuecomment-2560431566 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 ) .

Thanks ; this does load and function OK under Vista SP2 32-bit : [debug] Python 3.11.14 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.6.1 27 Jan 2026) OTOH , that "XP_x86-backport" is another type of binary mod that uses specialised DLL-wrappers, targeting EXCLUSIVELY NT 5.x ; you haven't disclosed anything about the provenance of that mod, perhaps its creator(s) could be kindly asked for an NT 6.0 compatible variant (???) ; speaking about Node.js on NT 6.0, this relevant issue has stayed disappointingly "calm" for the last 3 months ... 2026 is definitely NOT a good year so far, it seems...

FTR, issue #15712 isn't constantly giving me 403s here (but it often does ), so, at this point, I'll say that the avc1 ANDR-S formats are unreliable (YMMV): yt-dlp -vf 136+140 "MKjJTjWwD0M" => [debug] Command-line config: ['--ffmpeg-location', 'FFmpeg', '--downloader-args', 'ffmpeg:-v 8 -stats', '-vf', '136+140', 'MKjJTjWwD0M'] [debug] Encodings: locale cp1253, fs utf-8, pref cp1253, out utf-8 (No VT), error utf-8 (No VT), screen utf-8 (No VT) [debug] yt-dlp version master@2026.01.28.035725 from yt-dlp/yt-dlp-master-builds [5bf91072b] (zip) [debug] Python 3.11.14 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.6.0 1 Oct 2025) [debug] exe versions: ffmpeg n8.1-dev-630-N-121254-g635cb45 (setts), ffprobe n8.1-dev-630-N-121254-g635cb45 [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.2.0, certifi-2026.01.04, curl_cffi-0.14.0b2, mutagen-1.47.0, requests-2.32.5, sqlite3-3.51.2, urllib3-2.6.3, websockets-16.0, yt_dlp_ejs-0.3.2 [debug] JS runtimes: none [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets, curl_cffi [debug] Plugin directories: none [debug] Loaded 1856 extractors [debug] [youtube] [pot] PO Token Providers: none [debug] [youtube] [pot] PO Token Cache Providers: memory [debug] [youtube] [pot] PO Token Cache Spec Providers: webpo [debug] [youtube] [jsc] JS Challenge Providers: bun (unavailable), deno (unavailable), node (unavailable), quickjs (unavailable) [youtube] Extracting URL: MKjJTjWwD0M [youtube] MKjJTjWwD0M: Downloading webpage WARNING: [youtube] No supported JavaScript runtime could be found. Only deno is enabled by default; to use another runtime add --js-runtimes RUNTIME[:PATH] to your command/config. YouTube extraction without a JS runtime has been deprecated, and some formats may be missing. See https://github.com/yt-dlp/yt-dlp/wiki/EJS for details on installing one [debug] [youtube] Forcing "main" player JS variant for player afc53320 original url = /s/player/afc53320/player_es6.vflset/en_US/base.js [youtube] MKjJTjWwD0M: Downloading android sdkless player API JSON [debug] Sort order given by extractor: quality, res, fps, hdr:12, source, vcodec, channels, acodec, lang, proto [debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec, channels, acodec, lang, proto, size, br, asr, vext, aext, hasaud, id [info] MKjJTjWwD0M: Downloading 1 format(s): 136+140 [debug] Invoking http downloader on "https://rr1---sn-4vguioxu-n3bz.googlevideo.com/videoplayback?expire=1769639064&ei=Nzh6af79Ouy-mLAPz_-AoAE&ip=redacted&id=o-AN2WuWsCRapljCXx-NzvLk0FJyf3S16eB0eRffxJ72RH&itag=136&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&cps=378&met=1769617463%2C&mh=ko&mm=31%2C29&mn=sn-4vguioxu-n3bz%2Csn-nv47zn7y&ms=au%2Crdu&mv=m&mvi=1&pl=22&rms=au%2Cau&initcwndbps=1185000&bui=AW-iu_oSrgWiRvoggXB19EsSbEPtHVfCQcogYlmRaDLtGwZoDJH0KheHLEPfwVBHMwhe0JzEnxq2r8Rn&spc=q5xjPM2yLwkT426_mKEsW2gKpkLEf5ihhZB3rkj8U4mM-6mfI6I&vprv=1&svpuc=1&mime=video%2Fmp4&rqh=1&gir=yes&clen=21180105&dur=173.633&lmt=1769570849768674&mt=1769616895&fvip=3&keepalive=yes&fexp=51552689%2C51565116%2C51565682%2C51580968&c=ANDROID&txp=5535534&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJEij0EwRAIgC-5m76CXAtOTZoXORPUm8OFZ4w0Gi5rvEBvznQXpJXICIANjiW3HfY5aQZfdhq-SSF80289rW5gHGfTEF-G6yv6V&lsparams=cps%2Cmet%2Cmh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Crms%2Cinitcwndbps&lsig=APaTxxMwRQIgEAcimmDf_-R9YW-Iiz5YVRu0uebhkOjF4kowaCjvzFcCIQCwzO32ij8Aa-cPl0Ss8lgCvF4cSeYIf6B9FCuZSj6-Yw%3D%3D" [debug] File locking is not supported. Proceeding without locking [download] Destination: Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].f136.mp4 [download] 100% of 20.20MiB in 00:01:27 at 237.57KiB/s [debug] Invoking http downloader on "https://rr1---sn-4vguioxu-n3bz.googlevideo.com/videoplayback?expire=1769639064&ei=Nzh6af79Ouy-mLAPz_-AoAE&ip=<redacted>&id=o-AN2WuWsCRapljCXx-NzvLk0FJyf3S16eB0eRffxJ72RH&itag=140&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&cps=378&met=1769617463%2C&mh=ko&mm=31%2C29&mn=sn-4vguioxu-n3bz%2Csn-nv47zn7y&ms=au%2Crdu&mv=m&mvi=1&pl=22&rms=au%2Cau&initcwndbps=1185000&bui=AW-iu_oSrgWiRvoggXB19EsSbEPtHVfCQcogYlmRaDLtGwZoDJH0KheHLEPfwVBHMwhe0JzEnxq2r8Rn&spc=q5xjPM2yLwkT426_mKEsW2gKpkLEf5ihhZB3rkj8U4mM-6mfI6I&vprv=1&svpuc=1&mime=audio%2Fmp4&rqh=1&gir=yes&clen=2812478&dur=173.731&lmt=1769568370627241&mt=1769616895&fvip=3&keepalive=yes&fexp=51552689%2C51565116%2C51565682%2C51580968&c=ANDROID&txp=5532534&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJEij0EwRAIgCH6ivDbp1B8Kc22SWFu9wo9bCr7bN-boqKP709JpNGcCIGyge-JkcDuKGVKw6PD6Ir0HA_SIk82rnzexFM7ZSxBc&lsparams=cps%2Cmet%2Cmh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Crms%2Cinitcwndbps&lsig=APaTxxMwRQIgEAcimmDf_-R9YW-Iiz5YVRu0uebhkOjF4kowaCjvzFcCIQCwzO32ij8Aa-cPl0Ss8lgCvF4cSeYIf6B9FCuZSj6-Yw%3D%3D" [download] Destination: Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].f140.m4a [download] 100% of 2.68MiB in 00:00:14 at 190.92KiB/s [Merger] Merging formats into "Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].mp4" [debug] ffmpeg command line: FFmpeg\ffmpeg -y -loglevel repeat+info -i "file:Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].f136.mp4" -i "file:Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].f140.m4a" -c copy -map 0:v:0 -map 1:a:0 -movflags +faststart "file:Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].temp.mp4" Deleting original file Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].f136.mp4 (pass -k to keep) Deleting original file Nebraska at Michigan | HIGHLIGHTS | Big Ten Basketball | 01?27?2026 [MKjJTjWwD0M].f140.m4a (pass -k to keep)

Most sadly, another end is pretty close : https://github.com/yt-dlp/yt-dlp/issues/15712 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) ...

@johk What you describe is perfectly normal now ; when one a) doesn't pass YT logged-in cookies b) doesn't enable a JS runtime, then ONLY the android_sdkless (ANDR-S) formats are being available; these don't include any HLS (m3u8) formats (BTW, the ANDR-S client doesn't work at all with YT logged-in cookies). OTOH, the web_safari (WEB-S) client formats (of the HLS type, only) were, up until a week ago, also accessible under the above scenario; but now, because Google have put them behind an n/sig JS challenge, they do require a JS runtime (e.g. quickjs) to be enabled for them to become available to yt-dlp. The IOS HLS formats are (at this time at least, can't vouch for how much longer ) accessible without a JS runtime, but they have to be explicitly requested with the --extractor-args "youtube:player_client=ios;formats=missing_pot" argument; this will also yield the https IOS formats, which are inaccessible without also providing a PO Token ... Hope it's clear to you now ...

Many thanks, indeed ; but the naysayers/doubters are again back at it, one of them even went as far as to downvote your comment; I posted one last "analysis" there, but, frankly, I'm totally disheartened by all those "experts of today", who leave no room for old-school volunteers like myself ... Well then, I, you, Reino (and possibly others) know that the IOS HLS formats do still work, let the masses on GH's issue tracker stick to their reservations ...

Best greetings @nicolaasjan ; may I bring to your attention the "youtube IOS-client M3U8 formats" discussion found in GH#15569: https://github.com/yt-dlp/yt-dlp/issues/15569#issuecomment-3770540275 https://github.com/yt-dlp/yt-dlp/issues/15569#issuecomment-3771419465 https://github.com/yt-dlp/yt-dlp/issues/15569#issuecomment-3780166034 @bashonly, one of the main, current, yt-dlp devs, is not inclined to acknowledge (repeated) claims that the IOS-client M3U8 formats are (at this time) actually downloadable without 1) YT cookies, 2) a JS runtime enabled, 3) a PO Token. Could you, please, add there your own genuine input (hopefully one that corroborates the "downloadable" claims) before that issue gets, eventually, locked for non-devs? Many thanks in advance ... All the best for you!

@johk What happens if you switch to the 32-bit yt-dlp variant for Win7 ? https://github.com/nicolaasjan/yt-dlp/releases/download/2026.01.19.143412/yt-dlp_x86_win7.exe That one doesn't come with the curl_cffi Python module bundled (it's currently only 64-bit); some sites require this module to work, but NOT youtube.com (yet) ... curl_cffi is a Python binding (wrapper) for curl-impersonate, not for "ordinary" curl ; curl-impersonate uses Google's BoringSSL crypto lib (not Libre/OpenSSL), making it incompatible with < Win7 (I have Vista) ... curl 8.15.0-IMPERSONATE (Windows) libcurl/8.15.0-IMPERSONATE BoringSSL zlib/1.3 brotli/1.1.0 zstd/1.5.6 c-ares/1.30.0 WinIDN nghttp2/1.63.0 ngtcp2/1.11.0 nghttp3/1.9.0 Release-Date: [unreleased] Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli ECH HSTS HTTP2 HTTP3 HTTPS-proxy HTTPSRR IDN IPv6 Largefile libz NTLM SSL SSLS-EXPORT threadsafe Unicode UnixSockets zstd

r3dfox (and firefox) will still upgrade the connection to HTTPS, even if the relevant setting, HTTPS-Only Mode, under "about:preferences#privacy", has been manually set to "Don’t enable HTTPS-Only Mode" ... https://support.mozilla.org/en-US/kb/https-only-prefs https://support.mozilla.org/en-US/kb/https-upgrades I had to first enable HTTPS-Only Mode in all windows, and then configure an exception just for "o.rthost.win" ...

The article I linked to, https://habr.com/ru/articles/856602/ is, supposedly, intended for free-tier users, with an addition in the end "For paid CloudFlare users" ; but I'm not sure disabling ECH works anymore, as this statement from June 2025 indicates: https://github.com/win32ss/supermium/issues/1485#issue-3189002561 ...

@Egorkaru. can you not access the PLAIN HTTP version of http://o.rthost.win/ (obviously, on a browser that doesn't enforce HTTPS) ? I found some relevant issues in the Supermium issue tracker: https://github.com/win32ss/supermium/issues/1485 https://github.com/win32ss/supermium/issues/997 and, possibly, https://github.com/win32ss/supermium/issues/1005 @roytam1, it appears you have ECH enabled: https://dns.google/resolve?name=o.rthost.win&type=HTTPS perhaps disabling it could restore access in Russia ?

... Sadly, I suspect those have been blocked even before ALL the free "VPNs"; Putin doesn't like to leave loopholes , does he? ...

Below link, http://acs.pandasoftware.com/Panda/FREEAV/Promo_pd/FREEAV.exe will afford a relatively big offline installer, sized ca. 162 MiB, with file version 15.14.5.0 and a digital file signature (SHA2 only) of Jan 11th, 2026; I wouldn't install it, but when opening that EXE with 7-zip, file FREEAV.exe\Program Files\Panda Security\Panda Cloud Antivirus\VERSION.INI reads: [VERSION] VERSION=23.00.00.0000 LINE=4.0 TYPE=Release NINST=20251127_PandaZone BRANCH=PandaZone REV=1 BUILD_DATE=08/01/2026 23:11:41 CID=BE719E91-B06D-4263-8AB5-BF70044CC02B [MODULES] INSTALLER=7.10.00.2104 NNS=7.0.0.638 PSBOOT=1.0.34.0 RKPAVPROC=2.0.11.0 so I assume it to be of version 23 ...

Panda Dome's support has to be also made aware that while they advertise Windows XP SP3 x86 support, some features of the application (e.g. activation, sign-in to a Panda account) on that OS require ProxHTTPSProxy (or equivalent), which is NOT part of a standard installation of that OS; perhaps they need to "relax" some of the cipher suites needed to establish those secure connections, when XP SP3 is being detected as the host OS; but given their response record so far , I'm not betting any money in them addressing the mentioned issue(s) ...