Interesting. I ran the script to extract the json - that part was almost instant, then i used the first `url` field of `streamingData.adaptiveFormats`. I then ran

    curl 'https://...googlevideo.com...' --output video.mp4

for me the download is throttled to "768k", i assume thats in bits per second and not bytes which is very low: the random video i tried would take 8 minutes.

on the other hand,

    yt-dlp videoIdHere

does its processing then downloads the whole thing in about 5 seconds.

Does that curl command run much faster for you? Or do you do something else?

TBH, I never use the "adaptiveFormats"; I only ever use itag=22 or itag=18. YouTube has too many options, IMHO. As the old software meme goes, something like, "80% of a software program's users only use 20% of its options".

Is 768k too slow to watch the video from the URL. If not, then I would not call that throttled. Don't need 500 MB/s to watch a video. From what I've seen, when people discuss YouTube throttling online they are referring to max speeds of 60-70k. That's too slow to watch the video from the URL. Not too slow to download, though. And that's why this idea that YouTube is "preventing" downloads doesn't make any sense.

Use this post-data and should get higher speeed, e.g., 1.5 MiB/s. Test it and see if yt-dlp is faster. It shouldn't be.

    {"context": {"client": {"clientName": "ANDROID", "clientVersion": "17.31.35", "androidSdkVersion": 30 }}, "videoId": "$x", "params": "CgIQBg==", "playbackContext": {"contentPlaybackContext": {"html5Preference": "HTML5_PREF_WANTS"}}, "contentCheckOk": true, "racyCheckOk": true}

I do not use curl, except in HN examples. I generally do not download from YouTube. I use the URLs in the JSON to watch the video.

I should add that with respect to the download URLs in the HTML of every /watch?v= page some will not work at all, namely, in the case of heavily commercialised videos, videos using DASH and some other uncommon cases. But I always found this is minority of linked YouTube videos one encounters on the web.

iOS and Android clients do not yet have URLs with the "n" parameter. This is why specifying the clientName as "IOS," along with the specific YouTube key, currently yields URLs that remain unthrottled.

However, acquiring this key requires decompiling the mobile application, monitoring requests through a proxy, or relying on values discovered by others. It's not necessarily straightforward.

I do agree that the code is simpler this way.

I also find it interesting that, by default, yt-dlp calls the YouTube API three times, initially as an Android client, then as an iOS client, and finally as a Web client. Depending on the video and certain other parameters, YouTube provides different formats to different clients.

"However, acquiring this key decompiling the mobile application, monitoring requests through a proxy or relying on values discovered by others."

This is again not true. The key is in the HTML of every /watch?v= YouTube page. It's a public key; it's not hidden in any way.

Further, it's possible, up until today at least, to use the "WEB" key with clientName "ANDROID" of "IOS" and receive unthrottled URLs. The key in the shell script is in fact the WEB key. The key for IOS is different.

   curl -40s https://www.youtube.com/watch?v=aqz-KE-bpKQ \
   |grep -o \"INNERTUBE_API_KEY...[^\"]*\"