Who here has a Youtube-DL compile for WinXP?

[nicolaasjan]

1 hour ago, cmalex said:

Greetings

It search for "yt-dlp_win7_x86.exe" but "yt-dlp_x86_win7.exe" exists.

Please take look at _get_binary_name() in yt_dlp\update.py 

Best regards

You were right, there was an error in my `update.py` (Locally; not in the source on GitHub yet).

I have uploaded a new x86_win7 file.

[j7n]

So far the WinXP and Win7 versions have equal functionality, right?

"makes my antivirus solution go completely berserk"  That's the trouble with anti-virus, and it uses your computer power to display his berserk behavior.

[VistaLover]

2 hours ago, j7n said:

That's the trouble with anti-virus, and it uses your computer power to display his berserk behavior.

... Your generalised , yet unhelpful  , comment about AVs aside, what I actually meant with "berserk" was that the ZIP archive (and contained yt-dlp.exe binary) shared by nicolaasjan previously here was flagged, more specifically the wrapper DLL file "libxt.dll"; I'm sure this is a false positive, yet many AV engines won't "tolerate" well such wrapper DLLs, which hook and alter system file behaviour  ; on VT, half (31/67) the engines listed there ALSO flag the archive as "malicious": 

https://www.virustotal.com/gui/file/6ee52d1561e7ba3fc833eef35673d35b5325b2a5aad4efeeda5a1ae2c08aba41/detection

... but let's NOT turn this into an AV pros & cons discussion; MSFN has a dedicated forum/thread, oftentimes turbulent and cyber-bullied  ... I whitelisted the archive and binary, what I wanted to convey was that the binary wouldn't even launch  under Vista SP2, let alone perform a video download test  ...

[nicolaasjan]

13 hours ago, j7n said:

So far the WinXP and Win7 versions have equal functionality, right?

They should have equal functionality.

Though the Windows 7 version, built with Python 3.13 might be somewhat faster (didn't check).

P.S.

I've fixed the update issue with the .exe versions; no errors and warnings any more:

[debug] Fetching release info: https://api.github.com/repos/nicolaasjan/yt-dlp/releases/latest
[debug] Downloading _update_spec from https://github.com/nicolaasjan/yt-dlp/releases/latest/download/_update_spec
[debug] Downloading SHA2-256SUMS from https://github.com/nicolaasjan/yt-dlp/releases/download/2025.08.16.082053/SHA2-256SUMS
Current version: nicolaasjan/yt-dlp@2025.08.14.072314
Latest version: nicolaasjan/yt-dlp@2025.08.16.082053
Current Build Hash: 3becb2e3a07da4635929c347ef2c2499e30ab1752b55154d7168a47eca0bff66
Updating to nicolaasjan/yt-dlp@2025.08.16.082053 ...
[debug] Downloading yt-dlp_x86_win7.exe from https://github.com/nicolaasjan/yt-dlp/releases/download/2025.08.16.082053/yt-dlp_x86_win7.exe
Updated yt-dlp to nicolaasjan/yt-dlp@2025.08.16.082053

 

[j7n]

Today DL works again without SABR.

[j7n]

YouTube has something new on their end again. No mention of SABR at all anymore. There is new line in the app that says "Sleeping for 5 seconds as required by the site." No big deal about that.

Requesting 720p or 1080p h.264 video gives extremely poor quality compared to how it was before. The bitrates for a talking head segment are 240 kbit/s and 860 kbit/s respectively.

Requesting no/default format gives VP9 in extremely large size and demand for the computer. Best that they have 3840*2160 @ 30 fps, 9500 kbit/s. Google really wants to push their VP9. When nothing works, this still does.

[VistaLover]

7 hours ago, j7n said:

Requesting 720p or 1080p h.264 video gives extremely poor quality compared to how it was before. The bitrates for a talking head segment are 240 kbit/s and 860 kbit/s respectively.

I've also observed this  myself; the other day I DLed a BBC-made 30min documentary off their official YT account (videoID=Pxozxj03l18) and though I initially wanted the 720p25 variant (in h264), I went, in the end, for the 1080p25 one (h264, ca. 1600kbps), because 720p25 was a measly 500kbps  ...

7 hours ago, j7n said:

Best that they have 3840*2160 @ 30 fps, 9500 kbit/s. Google really wants to push their VP9.

... They're probably targeting ChromeOS laptops and/or Android-based UHD SmartTVs; little do they care for "legacy" OS/HW setups; and h264 still costs them patent fees, whereas their own VP9 codec (and av01) is royalty-free...

Edited Wednesday at 05:50 PM by VistaLover

[j7n]

Is ChromeOS powerful enough or has GPU to decode VP9? It gives basically the highest possible resolution, sometimes 60fps.

Example of current quality:

http://j7n.sytes.net/temp/ytqual/

Video 10 MB, audio 5 MB.

[user57]

do i understand this right ? the youtube downloader for xp (aka yt-dlp) only could get the h.264 format in windows xp ?
but the chrome-player (thats the thing what plays the video from youtube ect.) seems very capable to do the "h.265 codec" one of the h.265 decendent´s is called VP9 - in xp the browser (like supermium) it also could not handle VP9 ?
when i tryed the "KI" the KI did the same thing to nicolaasjan what the KI did to me, it pretended like to know the problem

but everybody could say something like the KI say like "it is because the fluctuation in the internal functions" -> but basicly that says nothing, rather to write something like this describe "he/KI dont know either" 
the KI did the same to me i asked it up what REG_MULTI_SZ_APPENDED is and why these can have 2 constand´s 
then it firstly say "that is right" - but the correct answers would be that it is not - the inf installer has a own set of constand´s 
that´s why it has 2 constands - it has nothing to do with a c++ compiler or the registry constand´s nor the registry functions
so the KI told me some bullcr.. and i was more confused then before (but we get the point the KI´s answer said it like it knows that, but actually the KI dont)

VP9 would be doable it is open source, openssl if it has a age-problem would also be doable - there would be the possiblity to write the cryptografic instructions 
if they are in SSE - then you still could translate them to normal instruction, that also would be possible

in sence of vista-10 function - we would have some on our list - one example would be the SRW-locks, those dont exits in XP but there implementations that works (they are function tested)

it would depent on how many functions python would be asking 

from what i understand it was going like "hmm python 9.11 + didnt compile up anymore" now we done !?

so do we know the problem more precisely ?
openssl ? vista functions (in this case what ones) ? vp9 ?

the thing with the frames should be mentioned, a video is not a game
in a game i could not even play with 60 frames even with 80 frames i could reconize that framerate with 100 frames it was ok
but a video this is however not the case often 24-30 are enough - the motion blur rather depents on the shutter-speed 
a shutter speed is not a framerate a shutter speed is how many pictures are taken in a certain speed like 1/60 thats 0,016 seconds to take 1 frame
you dont need 60 frames to make this happen you can take 24-30 frames of 1/60 frames either (in 1 second intervals = 24 frames with 1/60 taken pictures)
if you dont want the motion blur at all you take at least 1/500 for barly motion blur, 1/1000 for close to none , 1/2000 for no motion blur at all
for fight scenes that look well (then you just take 24 frames that was taken in 1/2000 speed) 

1 thing to tell here is that often for 24 frames also 1/24 shots are used

1/24 can make the picture to wash (not only motion blur) - higher speeds here dont have that problem so much or not at all if very fast

- but they do not depend having 60 frames - in this case you can also have lets say 24 pictures/frames taken with 1/1000 speed 

what you can say about a faster shutter speed is : it tends to sharpen the picture (if the iso dont has to be increased)

sharpen the picture also means the video looks sharper or better - a video is just a picture repeated 24 times (sometimes 50 or 60)

but in a video that is often not as reconizeable as with a game - that would remind a 3d-object discussion and a 2d video discussion - while 2d would do just fine for a video

more frames are not bad ... but the benefits are mostly (at least for video) are not that high anymore - and not to compare with the frame discussion from a game

 

however for shutter speeds of that level you need a fast lens the so called t-stop or f-stop, an alternativ would be to be in a good light (like sunlight) (in older movie´s you often see that they used outdoor lights to have a better iso, that was when FILM was still around - i saw them and even in a shadow scene the video looked very bright - that was because a outdoor light was used)
if either you have a slow lens or a bad light you have to increase the iso - and increasing the iso means less pixels and less dynamic range! (dynamic range means that the texture in bright and dark parts have more detail - a problem special small sensors have - thats why they use tricks - one trick is to take multiple pictures at different shutter speeds - and overlap them) 

so far i have not seen what is really missing, so more information would be very welcome

Edited yesterday at 01:22 AM by user57

[Reino]

Can you please use some punctuation marks? This is unreadable!

[jumper]

The video plays smoothly in Chrome 103 on my older Chromebook, but without audio. Where is the audio?

[j7n]

You write many thoughts that are only tangentially connected. What formats YT gives differ from title to title. I ask it to give me h.264 video for ease of decoding (I surprise myself to say this) with fallback to other best video. For an example of 25 vs 50 frames, open a DVD that has a feature as well as behind the scenes extras. When a person speaks waving his arms around at 50 or 60 fps, I feel like I could reach into the computer screen as if it was a window.

I only uploaded the literal video to demonstrate its quality. The audio is rather poor coming from a musician who seems to have a stuffed throad but I don't know what to  blame for that. It's 128 kbit/s. When I download from YT, I get separater video and audiio files.

[VistaLover]

23 hours ago, user57 said:

do i understand this right ?

... Probably not, so let me summarise the gist of what @j7n was talking about in his recent posts: 

1. The H.264 codec is probably the best choice when you're about to playback video on a system with low H/W resources (weak CPU, low-end GPU) and a legacy OS like Win7 SP1; the decoder is natively supported by the OS (not the case in XP SP3) and via implementations like WMF/MSE, an MP4 video can be played back within a compatible browser with hardware acceleration and hardware decoding (not the same things); most Win7-era graphics cards have H.264 decoding support built-in, so even when the MP4 video is being played back in a standalone media player, video decoding is performed by the GPU, not CPU...

2. Google have recently started producing their h.264 (aka avc1) youtube encodes at very low video bitrates, even for "high" resolutions, such as 720p/1080p; thus, while the h.264 YT encodes should be preferred for downloading (because they need less computer resources to be played back once downloaded), the stingy bitrate results in sub-optimal visual experiences (blurry moving images, video artifacts of various sorts, etc.).

3. OTOH, Google continue to produce their VP9 YT encodes at exceptional bitrates, especially for the FHD/UHD resolutions (>=720p); these are large files to download, to begin with, but, once downloaded, playback on low-end machines puts a heavy toll on the CPU, because VP9 is being software-decoded; I've not researched this properly, but graphics cards with integrated, native, VP9 decoding support (aka VP9 hardware decoding) only came in the later 2010s, as part of mostly Win10 machines... 

TL;DR: To have the best visual experience, j7n has to fetch the VP9 YT encodes, but these are detrimental to his under-resourced machine (mostly the CPU is being utilised for video playback, resulting in excess heat and energy consumption, etc.).