VistaLover

Thank you a bunch for spoiling us ... The new shared build runs OK here (Vista SP2 32-bit) ; compared to the previous Vista+ shared offering (ffmpeg-n8.1-dev-891-git-20251025-gdefd5f3), I see that below libs (rather, buildconfig flags) have been removed: --enable-cuda --enable-cuvid --enable-d3d12va --enable-nvenc --enable-ffnvcodec --enable-nvdec --enable-mediafoundation --enable-libvpx --enable-libaom --enable-librav1e --enable-libkvazaar --enable-libxavs --enable-vulkan --enable-libvvenc --enable-libcelt --enable-opencl This has reduced the size of the extracted archive by ca. 23 MiB (from 127 to just 104); really indebted! Best wishes.

I wasn't aware ; if that is the case, shouldn't this forum glitch be posted in https://msfn.org/board/forum/23-site-amp-forum-issues/ ? (Or is one now completely unable to?) Are any of the admins/mods made aware? At what exact stage does the "new topic" fail to be submitted? FWIW, the "Create New Topic" button seems to work OK here, but I haven't proceeded in actually submitting one ... @Dave-H, do you happen to have any insight on this?

... I think you've hit issue #185 , which the Chrome++ author (Bush2021) closed as "wontfix/not planned" ... Yes, I also believe "change/update" isn't always for the best , but what can one do ...

Which r3dfoxESR 140? NB, 140.5.0esr has been LibreWolf-ified (read above), while previous ESR, 140.2.0, has NOT... That one, too, is LibreWolf-free ... Hard to tell these days ... Since I always use the "portable" r3dfox variants (the browser profile is created inside a "Profile" dir adjacent to (r3dfox | r3dfox_esr).exe), I couldn't possibly have noticed your findings ; based on your findings, though, this is how I would migrate from r3dfox-139 to r3dfox-140esr: 1. Launch 140esr a first time and let it write/populate its default fresh profile in the "new" location (in "%AppData%\Eclipse Community\R3dfox ESR" ?) ; 2. I suppose you've already done this, but with 140esr open, load "about:support" => Profile folder (where you can see the absolute path to the ESR profile) => Open Folder 3. Exit r3dfox-140esr; then, erase all contents of the fresh ESR profile (already open in an Explorer window in step 2, above) 4. Inside the (now empty) 140esr profile folder, transfer/place all contents of your r3dfox-139 (release) profile (NOT the profile dir itself, just what it contains); 5. Launch 140esr anew; it SHOULD now load what was previously your r3dfox-139 profile... (Disclaimer: I haven't actually performed such a profile migration myself, my "guide" is based on educated guesses )

You are right, of course, but that "exact and precise finite control of these associations" is in practice left for "advanced" users, not "average" Windows user "Joe" (at least that's how I see it myself ) ... Like you, I was introduced to the PA.com format many years ago, and, actually, after an "accident" that happened during my WinXP era, when sister ran a "wipe whole C drive" virus on then "family" desktop; after a Windows reinstall (no C drive back-ups were being taken at that time ), I had to reconfigure all re-installed programs from scratch... PA.com format appealed to me, because I could "install" many programs on a second, D, disk partition, where both the applications' binaries and their settings would reside; in the unfortunate event of a second C partition "demise", all my "portable" programs on D partition would survive... I think most take "portable" to signify "have the app's settings alongside the app's main (binary) files, not save settings in %appdata% and/or the registry"; but "portable" also means "be able to store the app and its settings/configuration to a suitable external storage medium (USB stick, ExtHDD/SSD, etc.) and be able to transfer the storage device and use said "portable" app across many different hosts, without permanently impacting (and/or leaving traces in) each host's fie system/registry/etc. ; this is why most portable app authors advise not to establish associations of any kind with the host system the portable app is currently running on; yes, I've come across very "smart" portable launchers that clean up the host system after the app has been exited, but that depends on the exact launcher; during the years, I have seen portable-application users associating portable launchers with the host system, and this has less risk overall, but, TBH, I don't do that myself either... Now I'm thinking of it, my advice "not to associate" was particular to the simple "Sm-Portable.cmd" batch file I posted previously ; this isn't a proper "portable launcher" per se, so if you clicked on a URL link inside a PDF file and expected that to be opened in the "portable" Supermium "Profile", then I couldn't offer an "easy" way to do that (you'd probably have to mess with the registry, and so on) ; and the "--disable-encryption --disable-machine-id" switches were specifically added so that the portable "Profile" remains unlocked and accessible/readable across hosts ...

IIRC, the "nonsetup" zip versions were created for "special" cases (namely WinXP machines without all SPs and/or partially updated), where the provided ".exe" installers wouldn't run; FTR, the first "*_nonsetup.zip" release asset saw the light of day with the 124-r4 release: https://github.com/win32ss/supermium/releases/tag/v126-r4 As posted by NHTPG, these are NOT "portable" packages; Supermium "portable" packages were once offered as part of a paid for Patreon subscription: https://www.patreon.com/posts/supermium-122-r2-103469536 If you don't mind the registry being written to, a simplistic "portable" approach would be to write a "Sm-Portable.cmd" batch file: place it adjacent to Sm's main executable (chrome.exe) and ALWAYS launch Sm via that (you can alternatively create a Windows shortcut with the same cmdline args) ; be mindful: "portable" apps are NOT meant to be associated with other protocols/files/applications etc. ...

Apparently, pastebin moderation has approved nicolaasjan's yt-dlp log and yesterday's 403 error is now gone: ... Just something to keep in mind in the event of future pastebin uploads (i.e., they might not be immediately visible, for reasons only known to pastebin themselves ) ...

Thanks ; that one works ...

... But :

Yet another case of site admins arbitrarily blocking less than current User Agent Strings... Yet the site loads when a SSUAO is used to impersonate latest FxESR-140 on Win10x64: general.useragent.override.zdoom.org;Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:140.0) Gecko/20100101 Firefox/140.0 Using an extension to impersonate latest Chrome DEV (v144) makes it open in Sm-126, too : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 PS: Sm-126 by default reports itself as being Cr-132 ...

As told, you don't have to install node system-wide; of the linked zip archive, for yt-dlp purposes, you only need the standalone (portable) "node.exe" binary ... Even simpler, just place "node.exe" (67.8 MiB) next to your yt-dlp 64-bit binary and issue/configure --js-runtimes node; if you're overly concerned about "security", you can let yt-dlp launch NODE in JIT-less mode via --js-runtimes node --extractor-args "youtube-ejs:jitless=true" (provides better security at the cost of performance/speed) ; according to online testimonies, Node takes just 1-2s to solve YT's challenges, while QuickJS, depending on how powerful your machine is, may take from 8-15s (and this relic of mine (32-bit OS, 3GB RAM, Core2 Duo from late 2007), can take anything from 15-30s, depending on how busy the machine is when qjs.exe starts ) ... I keep an eye on two things : 1. This; QuickJS-ng may, in due course, end up with "rope strings", too, so its speed (when used with yt-dlp) may become on par with upstream QuickJS 2. That; the astring library is an external dependency of the yt-dlp-ejs JS component which, together with a suitable JS runtime, performs the task of solving YT's JS challenges; hopefully, this PR will be accepted and merged into the astring repo and a future yt-dlp-ejs version will pick that updated version up, making the use of QuickJS-ng with yt-dlp equally "practical" ... Reference: here ...

Not my fault, really, but here you go: https://board.eclipse.cx/viewtopic.php?p=7539#p7539 https://board.eclipse.cx/viewtopic.php?p=7542#p7542 https://board.eclipse.cx/viewtopic.php?p=7593#p7593 There was this r3dfox bug and the author (thought he) found the solution in one of LibreWolf's special "policies", but while he was "there", he decided to also implement several other LW policies/settings into r3dfox; this is implied in the bolded wording of every new "LW-ified" r3dfox release, e.g. 128.14.1esr: Testimonies of breakage can be found in the linked Eclipse Forum thread and in the GH issue tracker (recent open/closed issues), e.g. https://github.com/Eclipse-Community/r3dfox/issues?q= is%3Aissue state%3Aopen sort%3Aupdated-desc https://github.com/Eclipse-Community/r3dfox/issues?q=is%3Aissue state%3Aclosed sort%3Aupdated-desc What made me furious the most was this ; but, as I wrote already, I'm only speaking for myself here; it may well be that the majority of the r3dfox users are still very happy to have got new releases with the latest security patches, courtesy of Mozilla .. As you often write, "moving on" ...

... Eclipse Board is now back in business (technically, it never went off-line) ... .. But I'd be very wary of ; both have been LibreWolf-ified ; I'd make a profile back-up prior to updating, in case one decides to revert to the previous ESRs (128.12.0rc2 and 140.2.0, respectively); just sayin' , not suggesting people shouldn't update...

Well, since your custom path to the QuickJS binary doesn't contain any whitespace, I feel no quotation marks of any type are needed after all ; personally, I'd only use "..." in the value part of the --js-runtimes flag, something like: --js-runtimes quickjs:"H:\path to\qjs-windows-x86_64.exe" For the sake of even more simplicity, I'd a) rename the QuickJS binary to just "qjs.exe" b) place it adjacent to "yt-dlp-win7-x64.exe" (which could also be renamed to just "yt-dlp.exe"); then, one would simply need issue --js-runtimes quickjs in the cmdline (or set an equivalent permanent setting inside yt-dlp's config file); more in https://github.com/yt-dlp/yt-dlp/issues/15012 https://github.com/yt-dlp/yt-dlp/wiki/EJS The use of QuickJS-ng is strongly discouraged, because they haven't yet implemented this ; since you're on Win7 SP1 64-bit, for even quicker n/sig deciphering you may want to switch to this NodeJS fork: https://github.com/vladimir-andreevich/node.js-windows-7/blob/main/v20/node-v20.19.2-win-x64.zip (node isn't enabled by default in yt-dlp, you need to issue --js-runtimes node (or use a custom path to the binary, if you must)) PS: It appears https://www.youtube.com/watch?v=Kzb6Vih7wrU is geo-fenced here ...

... And un-archived now : https://github.com/Eclipse-Community/r3dfox

The redfox-old GitHub repo was (also) archived today, but this was probably to be expected; no clue as to why its successor suffered the same fate today ... As for the Eclipse Board , they mention "Temporary maintenance" (stress on "temporary" is mine ) ... That ; and those "proposals" did materialise into a Librewolf-ification of r3dfox that many, myself included, never asked for ... As @Jody Thornton put it, ... and I'll add Vista SP2 to the OS mix above ; yes, close to "stock" Firefox but with the ability to launch on older WinOSes! This is what most site admins expect, this is what most extension authors expect and target... I was never part of the "extreme web privacy" crowd to demand a change of route towards Librewolf (or similar forks); I understand a small portion of the LW code was needed to address a specific r3dfox technical issue, but that is different to incorporating large chunks of LW code "while we're at it" ... As if it wasn't enough to deal with Mozilla "breaking" things (and locking down the browser) with each major version update, an "average" r3dfox user has to deal with "r3dfox-specific" changes, too (ones that not always meet with said user's "approval") ... And my own words on DRM/EME: I found r3dfox maintainer's "obsession" about DRM simply "blown out of proportion"; he goes to extreme lengths to disable EME at buildtime, but the browser itself provides an easy way to disable EME at runtime, if one objects to it for whatever ideological reason... Let's face it; with Google practically owning the Web, they have leveraged the use of their own CDM (Widevine) in most media services, even the most obscure, but still free, ones... Yes, I totally understand the argument about "black-boxed code" etc., but DRM has become a necessary evil in the web era of 2025 and beyond... A lot of focus has been put on the VMP (Verified Media Path) requirement associated with the majority of the prominent/commercial DRM'ed Video+Audio services (e.g. Netflix, Disney+, Paramount+, Spotify, Tidal, Apple Music, etc.) as a reason NOT to implement DRM on r3dfox (because VMP entails a very large sum of money, paid to Google, for certifying the browser for VMP purposes), but what about the rest of the lesser known services that don't impose VMP with DRM? Jody's example of https://www.cp24.com/now/ is such a case, there are many others... The whole thing kind of reminds me, in some twisted way, of Moonchild and his own browser, Pale Moon, where he vehemently refused to implement DRM of any kind; but while Basilisk was still his, he allowed the DRM functionality inherited from his FxESR-52 forkpoint to stay enabled; that is, until the point he could no longer shoehorn-in upstream (Mozilla) DRM patches and, one day, DRM in Basilisk was declared such a big Evil that had to be completely excised! (NB: Latest Widevine CDM (a .dll) needs Win8+ to properly function; on Vista/Win7, some wrapper DLLs (e.g. borrowed from the Supermium project ) are actually needed to make it work there (and only on non-VMP services)). I believe so; he probably had a "hissy fit" and decided to "now I'll show you all", or I could be totally wrong and the GitHub repo archival was an inadvertent mishap ... ... You can count me as one (though I did not post in that thread...). Personally, I'll stick to older r3dfox-140.0.4; it will become my new "KafanMiniBrowser" for GitHub; I'm not that concerned about security patches, as long as GH works there (and it'll continue to work until 140esr becomes deprecated), I'll keep using it... In closing, I'm not being entitled or ungrateful towards the r3dfox author; huge thanks from my side for what he has offered to me over the last two years or so ...

I can confirm; it's a "less heavy" G-Search iteration, probably more gentle to older/under-resourced H/W ; below, a glimpse of what an Image Search looks like: Should you wish to revert to the "full-blown" G-Search implementation, targeting so called "recent" web engines, just use a SSUAO for Google: general.useragent.override.google.com;Mozilla/5.0 (Windows NT 10.0; rv:140.0) Gecko/20100101 Firefox/140.0 And then, above image search will turn into:

Detailed explanation of this issue on WinXP SP3: https://github.com/3dyd/pyinstaller-builds/issues/2#issuecomment-3464525813 Excerpt form PyInst-6.0.0 documentation: https://pyinstaller.org/en/v6.0.0/CHANGES.html#incompatible-changes The psapi.dll in question (with the missing function) is the system one, while the one inside the "_internal" dir (which isn't being loaded when PyInst-6.16.0-xpmod has been used) is PSAPI.DLL, one of the four wrapper DLLs (kernelXP.dll, ntextl.dll, psapi.dll, ws2_xx.dll) that are used to backport py3.11.4 to XP ...

I had just completed my initial testing of your latest build on this old and under-resourced Vista SP2 32-bit laptop and, thankfully , I couldn't possibly reproduce your initial miserable qjs execution times ; FTR, this machine has a (2007-era) Intel Core2Duo T5250@1.50GHz CPU and 3GiB of DDR2 RAM; I used my stopwatch to time below yt-dlp command: yt-dlp_x86 --ies youtube --js-runtimes quickjs -vF "yrcIdXBwVww" and it actually took just 43s from when I clicked ENTER to full completion: [debug] Command-line config: ['--ies', 'youtube', '-vF', 'yrcIdXBwVww', '--js-runtimes', '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 local@2025.10.27 [937b84ddb] (win_x86_exe) [debug] Python 3.14.0 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.0.18 30 Sep 2025) [debug] exe versions: none [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.1.0, certifi-2025.10.05, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.5.0, websockets-15.0.1, yt_dlp_ejs-0.2.1 [debug] JS runtimes: quickjs-2025-09-13 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1 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: yrcIdXBwVww [youtube] yrcIdXBwVww: Downloading webpage [youtube] yrcIdXBwVww: Downloading tv client config [youtube] yrcIdXBwVww: Downloading player 25f1a420-main [debug] Saving youtube-sts.25f1a420-main to cache [youtube] yrcIdXBwVww: Downloading tv player API JSON [youtube] yrcIdXBwVww: Downloading web safari player API JSON [debug] [youtube] [jsc:quickjs] Using challenge solver lib script v0.2.1 (source: python package, variant: minified) [debug] [youtube] [jsc:quickjs] Using challenge solver core script v0.2.1 (source: python package, variant: minified) [debug] [youtube] [jsc:quickjs] Running quickjs: qjs --script 'C:\Users\<redacted>\AppData\Local\Temp\tmpp_d3itxv.js' [youtube] yrcIdXBwVww: 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 yrcIdXBwVww: 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 1 | mhtml | images storyboard sb1 mhtml 160x90 1 | mhtml | images storyboard sb0 mhtml 320x180 1 | mhtml | images storyboard 140 m4a audio only 2 | 3.60MiB 129k https | audio only mp4a.40.2 129k 44k medium, TV, m4a_dash 251 webm audio only 2 | 103.22KiB 4k https | audio only opus 4k 48k medium, TV, webm_dash 91 mp4 256x144 30 | ~ 3.43MiB 123k m3u8 | avc1.4D400C mp4a.40.5 WEB-S 160 mp4 256x144 30 | 801.69KiB 28k https | avc1.4d400c 28k video only 144p, TV, mp4_dash 278 webm 256x144 30 | 806.96KiB 28k https | vp9 28k video only 144p, TV, webm_dash 92 mp4 426x240 30 | ~ 5.41MiB 195k m3u8 | avc1.4D4015 mp4a.40.5 WEB-S 133 mp4 426x240 30 | 1.47MiB 53k https | avc1.4d4015 53k video only 240p, TV, mp4_dash 242 webm 426x240 30 | 1.22MiB 44k https | vp9 44k video only 240p, TV, webm_dash 93 mp4 640x360 30 | ~ 11.03MiB 397k m3u8 | avc1.4D401E mp4a.40.2 WEB-S 134 mp4 640x360 30 | 2.83MiB 102k https | avc1.4d401e 102k video only 360p, TV, mp4_dash 18 mp4 640x360 30 2 | 4.15MiB 149k https | avc1.42001E mp4a.40.2 22k 360p, TV 243 webm 640x360 30 | 2.36MiB 85k https | vp9 85k video only 360p, TV, webm_dash 94 mp4 854x480 30 | ~ 20.21MiB 728k m3u8 | avc1.4D401F mp4a.40.2 WEB-S 135 mp4 854x480 30 | 4.91MiB 177k https | avc1.4d401f 177k video only 480p, TV, mp4_dash 244 webm 854x480 30 | 4.22MiB 152k https | vp9 152k video only 480p, TV, webm_dash 95 mp4 1280x720 30 | ~ 41.07MiB 1479k m3u8 | avc1.64001F mp4a.40.2 WEB-S 136 mp4 1280x720 30 | 10.33MiB 372k https | avc1.64001f 372k video only 720p, TV, mp4_dash 247 webm 1280x720 30 | 9.39MiB 338k https | vp9 338k video only 720p, TV, webm_dash 96 mp4 1920x1080 30 | ~ 81.20MiB 2923k m3u8 | avc1.640028 mp4a.40.2 WEB-S 137 mp4 1920x1080 30 | 20.18MiB 727k https | avc1.640028 727k video only 1080p, TV, mp4_dash 248 webm 1920x1080 30 | 16.53MiB 596k https | vp9 596k video only 1080p, TV, webm_dash 271 webm 2560x1440 30 | 41.46MiB 1494k https | vp9 1494k video only 1440p, TV, webm_dash Those 43s include the time the PyInst binary took to extract its content inside the %TEMP% folder of my Windows User Account ; and this was for the FIRST yt-dlp invocation, next ones took even less ; TL:DR: QuickJS is totally workable here, thanks a lot to you, to the yt-dlp devs and to a certain GitHub member (barracuda156) who actually "fought" to have QJS included as a supported external JS runtime! Below, an actual successful DL log: yt-dlp_x86 --ies youtube --js-runtimes quickjs -vf 140 "yrcIdXBwVww" [debug] Command-line config: ['--ies', 'youtube', '--js-runtimes', 'quickjs', '-vf', '140', 'yrcIdXBwVww'] [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 local@2025.10.27 [937b84ddb] (win_x86_exe) [debug] Python 3.14.0 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 (OpenSSL 3.0.18 30 Sep 2025) [debug] exe versions: ffmpeg 5.0 (fdk,setts) [debug] Optional libraries: Cryptodome-3.23.0, brotli-1.1.0, certifi-2025.10.05, mutagen-1.47.0, requests-2.32.5, sqlite3-3.50.4, urllib3-2.5.0, websockets-15.0.1, yt_dlp_ejs-0.2.1 [debug] JS runtimes: quickjs-2025-09-13 [debug] Proxy map: {} [debug] Request Handlers: urllib, requests, websockets [debug] Plugin directories: none [debug] Loaded 1 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: yrcIdXBwVww [youtube] yrcIdXBwVww: Downloading webpage [youtube] yrcIdXBwVww: Downloading tv client config [debug] Loading youtube-sts.6e4dbefe-main from cache [youtube] yrcIdXBwVww: Downloading tv player API JSON [youtube] yrcIdXBwVww: Downloading web safari player API JSON [youtube] yrcIdXBwVww: Downloading player 6e4dbefe-main [debug] [youtube] [jsc:quickjs] Using challenge solver lib script v0.2.1 (source: python package, variant: minified) [debug] [youtube] [jsc:quickjs] Using challenge solver core script v0.2.1 (source: python package, variant: minified) [debug] [youtube] [jsc:quickjs] Running quickjs: qjs --script 'C:\Users\<redacted>\AppData\Local\Temp\tmp8kc1jvmr.js' [youtube] yrcIdXBwVww: 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] yrcIdXBwVww: Downloading 1 format(s): 140 [debug] Invoking http downloader on "https://rr1---sn-4vguioxu-n3bz.googlevideo.com/videoplayback?expire=1761596706&ei=woD_aJTNJ_eG0u8Psu7R0AE&ip=<redacted>&id=o-ABLy9SDAL9azDltc64Qry1Wjfc2T-ukUkgAK7YIGNBjU&itag=140&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&met=1761575106%2C&mh=e1&mm=31%2C29&mn=sn-4vguioxu-n3bz%2Csn-nv47lnsk&ms=au%2Crdu&mv=m&mvi=1&pl=22&rms=au%2Cau&initcwndbps=1093750&bui=AdEuB5S9H_ZLOx4DhWandbVVoE2T23TniDsH9dzuJWA1A2BTXilW4PS4MvJfCH8rm5PYm_rkKk1bNbUl&vprv=1&svpuc=1&mime=audio%2Fmp4&ns=3j_zEDpH1UcvQ1PnFTnBiuoQ&rqh=1&gir=yes&clen=3769997&dur=232.896&lmt=1758938329553945&mt=1761574619&fvip=3&keepalive=yes&lmw=1&fexp=51557447%2C51565115%2C51565682%2C51580970&c=TVHTML5&sefc=1&txp=6208224&n=Uyc5Xoc53RETOw&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cvprv%2Csvpuc%2Cmime%2Cns%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJfQdSswRAIgYqAE1n3WKMewWR3MOnwuPURtZm5QnMnZlMtNJQaTmV0CIDbOyrrvXFyR2m1kUheTy_ik6DIXA9UXoZzbOs1ffk3a&lsparams=met%2Cmh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Crms%2Cinitcwndbps&lsig=APaTxxMwRQIgGZIroMcG7xUvn-eLhnLxe3FP_A-zu5lRB5wrz3pjoEoCIQChTmzqkvfj8R_MXFuYDQ5u9h56fAQdFtIm902IyqUrCg%3D%3D" [debug] File locking is not supported. Proceeding without locking [download] Destination: Patching yt-dlp (silent) [yrcIdXBwVww].m4a [download] 100% of 3.60MiB in 00:00:04 at 782.66KiB/s [FixupM4a] Correcting container of "Patching yt-dlp (silent) [yrcIdXBwVww].m4a" [debug] ffmpeg command line: ffmpeg -y -loglevel repeat+info -i "file:Patching yt-dlp (silent) [yrcIdXBwVww].m4a" -map 0 -dn -ignore_unknown -c copy -f mp4 -movflags +faststart "file:Patching yt-dlp (silent) [yrcIdXBwVww].temp.m4a" ... Which is where I pointed people to in my previous post : So, does the latest QJS (32-bit) launch on WinXP SP3? FWIW, I don't like adding stuff to PATH unless I can't do otherwise; placing the qjs.exe (with its DLL dependency) adjacent to the yt-dlp_x86.exe binary was all it took here ... And a slight word of caution: Of the four external JS runtimes supported by yt-dlp, QJS is the least secure one ; it has no sandbox, needs to write to the host machine's TEMP dir and is subject to some exploits related to Temp files: https://github.com/coletdjnz/yt-dlp-wiki-dev/blob/ejs/EJS.md#notes-3 Myself, I'd ONLY invoke it from the cmdline when I need to use YT, not permanently enable it via a config setting; call me paranoid ... Kind regards.

... Indeed ; I still keep an old (2018) version of MABS on an external disk, I used that to "strip" the DLL, $ cd ~ $ strip "libfdk-aac-2.dll" and filesize was reduced from 2.11 MiB to 1.73 MiB (but still larger than the 1.34 MiB of the "xpmod-P4" variety ) ...

1. This one does launch OK under Vista SP2 32-bit . 2. Instead of the cmdline flag/config setting "--remote-components ejs:github" you could've built the PyInstaller binary with the EJS components bundled, as will upstream do : https://github.com/coletdjnz/yt-dlp-wiki-dev/blob/ejs/EJS.md#step-2-install-ejs-challenge-solver-scripts You can install them via PyPI prior to PyInst compilation: python -m pip install -U yt-dlp-ejs and, hopefully, they'll be integrated into the produced executable, just like the rest of the default Python modules... 3. " --remote-components ejs:npm" applies ONLY to deno/bun, NOT to node used on Win7 : https://github.com/coletdjnz/yt-dlp-wiki-dev/blob/ejs/EJS.md#option-2-enable-ejs-script-downloads-from-npm 4. At the time the binary was compiled, quickjs support hadn't yet arrived, thus: yt-dlp_x86 --ies youtube -vF "yrcIdXBwVww" --remote-components ejs:github --js-runtimes quickjs => ... WARNING: Ignoring unsupported JavaScript runtime(s): quickjs. Supported runtimes: deno, node, bun. ... [debug] [youtube] [jsc] JS Challenge Providers: bun (unavailable), deno (unavailable), node (unavailable) ... [info] Available formats for yrcIdXBwVww: ID EXT RESOLUTION FPS | FILESIZE TBR PROTO | VCODEC ACODEC MORE INFO ----------------------------------------------------------------------------------- sb3 mhtml 48x27 0 | mhtml | images storyboard sb2 mhtml 80x45 1 | mhtml | images storyboard sb1 mhtml 160x90 1 | mhtml | images storyboard sb0 mhtml 320x180 1 | mhtml | images storyboard 91 mp4 256x144 30 | ~ 3.43MiB 123k m3u8 | avc1.4D400C mp4a.40.5 WEB-S 92 mp4 426x240 30 | ~ 5.41MiB 195k m3u8 | avc1.4D4015 mp4a.40.5 WEB-S 93 mp4 640x360 30 | ~11.03MiB 397k m3u8 | avc1.4D401E mp4a.40.2 WEB-S 94 mp4 854x480 30 | ~20.21MiB 728k m3u8 | avc1.4D401F mp4a.40.2 WEB-S 95 mp4 1280x720 30 | ~41.07MiB 1479k m3u8 | avc1.64001F mp4a.40.2 WEB-S 96 mp4 1920x1080 30 | ~81.20MiB 2923k m3u8 | avc1.640028 mp4a.40.2 WEB-S Best regards.

Most sadly, this is only part of the story ; probing the v20.19.2 (32-bit) binary (a whooping 61.3 MiB in filesize) with DependencyWalker, I found a total of six (6) Vista-incompatible function calls: in advapi32.dll: EventSetInformation in kernel32.dll: K32GetModuleBaseNameW K32GetProcessMemoryInfo ResolveLocaleName TryAcquireSRWLockExclusive TryAcquireSRWLockShared The first one can also be a thing on a partially updated Win7 SP1 install (see this); thank you for already raising a Vista-support issue with Vladimir ...

Breaking news: https://github.com/yt-dlp/yt-dlp/issues/14404#issue-3444474002 https://bellard.org/quickjs/binary_releases/?C=M;O=D For my Vista SP2 32-bit laptop: https://bellard.org/quickjs/binary_releases/quickjs-win-i686-2025-09-13.zip ... and: qjs -h QuickJS version 2025-09-13 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) -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 Though, this might still mean nothing, as I haven't gotten around to actually trying https://github.com/yt-dlp/yt-dlp/pull/14157 on this machine... Wiki (WIP): https://github.com/coletdjnz/yt-dlp-wiki-dev/blob/ejs/EJS.md

Some additional details : --enable-cuda --enable-cuvid --enable-nvenc --enable-nvdec I only have an Intel iGPU which H/W decodes MPEG-2 only, no external NVIDIA gfx card either, so I couldn't possibly use those inside FFmpeg ... --enable-mediafoundation Despite Vista SP2+Platform Update Supplement (PUS) having a working form of WMF, backported from Win7 and installed as a MS Update, I've found, via using other FFmpeg builds with that flag enabled, that I can't use the WMF encoders (h264/aac) in FFmpeg for transcoding purposes; probably this specific flag requires a Win7+ OS, where the WMF feature is fully matured ... --enable-d3d12va --enable-vulkan AFAIK, these both are not compatible with/offered on Vista SP2... --enable-libvpx --enable-libkvazaar --enable-libxavs --enable-libdav1d --enable-libaom --enable-librav1e I don't see myself using the encoder part of those video codecs on this specific, under-resourced, "vintage" 32-bit machine ; however, if the decoder part of any of them can't be substituted with a native FFmpeg implementation, then, I guess, it should stay (?) ... --enable-libmysofa Well. in RL scenarios I haven't had the need myself to use SOFA files with HRTF content, however, since this is related to acoustics (audio) and assuming it doesn't add much to binary filesize, I guess it can stay enabled/included after all ... Please, keep it enabled ; the native AAC encoder isn't fully, yet, on par with the Fraunhofer one (and, correct me if wrong, doesn't allow for HE-AACv1/v2 transcoding profiles); BTW, below: https://forum.videohelp.com/threads/414767-ffmpeg-7-0-1-and-Windows-7/page2#post2771491 I'm seeing archive "libfdk-aac-v2.0.3-158-gd8e6b1a-x86.7z" intended for Win7SP1_x86; this one affords a DLL much larger (2.10 MiB) than the DLL extracted from archive "libfdk-aac-2.0.3-158-d8e6b1a-win32-xpmod-P4.7z" (1.33 MiB) ; I've probed the former with DepWalker and it appears to be Vista-compatible, though I haven't yet used it in an audio transcoding job... In closing, I'm not the sole Vista user around here and if your Vista-compat FFmpeg offerings are to benefit a broader Vista+ community, then you can still include any external lib you see fit - I initially only requested a shared_x86 compile, my wish has been granted and I'm extremely grateful to you ! Kindest regards .

Thanks! Launches OK here: ffmpeg version N-121515-gdefd5f3f64-WINVISTA Copyright (c) 2000-2025 the FFmpeg developers built with gcc 15.2.0 (Rev8, Built by MSYS2 project) configuration: --disable-autodetect --enable-amf --enable-bzlib --enable-cuda --enable-cuvid --enable-d3d12va --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-nvenc --enable-zlib --enable-sdl2 --enable-ffnvcodec --enable-nvdec --enable-mediafoundation --enable-gmp --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-libfdk-aac --enable-fontconfig --enable-libass --enable-libbluray --enable-libfreetype --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-librav1e --enable-libsrt --enable-libzmq --enable-libgsm --enable-chromaprint --enable-frei0r --enable-libaribb24 --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfribidi --enable-libgme --enable-libilbc --enable-libkvazaar --enable-libmodplug --enable-librubberband --enable-libxavs --enable-libzvbi --enable-openal --enable-libcodec2 --enable-ladspa --enable-vulkan --enable-libuavs3d --enable-libjxl --enable-libxeve --enable-libxevd --enable-libvvenc --enable-libharfbuzz --enable-liblc3 --enable-libaribcaption --enable-libcelt --enable-lcms2 --enable-libdvdread --enable-libdvdnav --enable-liboapv --enable-libqrencode --enable-libquirc --enable-opencl --enable-opengl --enable-gnutls --enable-gpl --enable-version3 libavutil 60. 14.100 / 60. 14.100 libavcodec 62. 16.100 / 62. 16.100 libavformat 62. 6.101 / 62. 6.101 libavdevice 62. 2.100 / 62. 2.100 libavfilter 11. 9.100 / 11. 9.100 libswscale 9. 3.100 / 9. 3.100 libswresample 6. 2.100 / 6. 2.100 Universal media converter usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... Use -h to get full help or, even better, run 'man ffmpeg' Some remarks: 1. The extracted .7z archive yields a folder sized 125 MiB, i.e. ca. 100 MiB less compared to using both static FFmpeg.exe+FFprobe.exe binaries ... 2. --enable-libfdk-aac : I take it this means I can still use the "libfdk-aac-2.dll" file from inside the "libfdk-aac-2.0.3-158-d8e6b1a-win32-xpmod-P4.7z" archive to enable that (non-free) audio encoder? 3. This is just an observation, but this build configuration still contains a lot of flags/libs either not applicable to my platform (e.g. --enable-d3d12va) or ones I'd never use myself: --enable-cuda --enable-cuvid --enable-d3d12va --enable-nvenc --enable-nvdec --enable-mediafoundation --enable-libvpx --enable-libdav1d --enable-libaom --enable-libmysofa --enable-librav1e --enable-libkvazaar --enable-libxavs --enable-vulkan But I see what you did there ; this is not tailored specifically to an old Vista SP2 32-bit machine with iGPU (Intel), but is a full-fledged compile (full set of libs/filters/etc.), with minimum OS requirement lowered to NT 6.0; all those extra libs can still be used efficiently on a more recent WinOS, with more powerful H/W ... 4. N-121515-gdefd5f3f64 : For those who prefer a slightly different git-versioning scheme, this is equal to n8.1-dev-891-git-2025-10-25-gdefd5f3 i.e. built from a master branch code snapshot (commit defd5f3) authored today, which is the 891st commit after tag "n8.1-dev" was cut ... Really impressive, am much obliged! The retrocomputing communities are in high need of altruistic persons such as yourself! Take the best of care...