Interestingly I found that YouTube's web UI actually requests range URLs rather than range HTTP headers, allowing it to seek around the video faster than mpv with yt-dlp (and conveniently avoiding throttling as well). I suspect this may be related to DASH: https://github.com/mpv-player/mpv/issues/10601
throttling is not avoided. the YouTube web client generates a JavaScript signature that disables the throttling, same as what the code in the article does.
&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:
"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."
throttling is not avoided. the YouTube web client generates a JavaScript signature that disables the throttling, same as what the code in the article does.