&n= is not "same as what the code in the article does". Article talks about old signatureCipher/sp/s/sig code. Without signatureCipher urls return 403, with signatureCipher but without decoded &n= urls return fine, but start throttling after just over ~1MB. My comment from Oct 2021:
https://github.com/ytdl-org/youtube-dl/issues/29326#issuecom...
"server heavily throttles any request to same URL after initial 2-4MB regardless of retries.
&n is only part of the puzzle. While bad or no &n will indeed trigger 50KB/s throttling, even correct &n only lets you download at most couple megabytes at good speed. Try any video in official YT client and you will see repeated URL request with different &range= parameters all use same &n, but trying to download that URL all at once will always throttle after initial ~2-4MB.
The correct solution (after generating correct &n) is to start using custom URL &range= parameters instead of normal HTTP range headers and default to downloading in 2MB chunks."
That was the case in 2021. I just checked newest "fixed" yt-dlp and if you change chunk size from default 10MB to 100MB you will quickly notice throttling is STILL there kicking right around that 2-4MB mark, but instead of brutal 50KB/s its somewhere around 1MB/s. Default Chunk size of 10MB somewhat helps to mask/hide it by smoothing jumping up and down transfer. youtube-dl (im shocked its still updated, cant download .exe, have to download zip and run "python.exe __main__.py"?) just silently ignores "--http-chunk-size 100000000" altogether and keeps downloading in 10MB chunks to hide the problem. "--print-traffic" shows 10MB chunks.
This is for all stream types other than 22 (mp4 1280x720 avc1.64001F, 30fps, mp4a.40.2). 22 seems to be special and with proper &n= you can slurp whole file with one connection without additional throttling, probably for backward compatibility with older clients?
TLDR: You can still download YT videos IF you chop them up into small chunks. Playing back without chopping up into chunks somewhat "works" because 1MB/s=10Mbit is still above thickest juiciest bitrate YT would ever serve, but problems become obvious when you start fast forwarding/skipping around the video (1-3 second pauses in mplayer). Playing type 22 works great and seeking is instant.
"Personally I use mplayer to stream YT and am currently on a lookout for a simple proxy server I could modify to do the above (divide into chunks, rewrite HTTP range header into URL parameter) for me transparently in the background."