VistaLover
MemberVistaLover last won the day on November 13
VistaLover had the most liked content!
About VistaLover

Profile Information
-
OS
Vista Home Premium x86
Recent Profile Visitors
39,062 profile views
VistaLover's Achievements
3.1k
Reputation
-
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 ...
-
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 ...
-
My Browser Builds (Part 5)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
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.