2 ms·
When I tried using aria2 to work around the throttling you mentioned, I noticed that simply using aria2 at all (no parallelism with -j/-s) fixed the download ra
by pdkl95 8y ago
When I tried using aria2 to work around the throttling you mentioned, I noticed that simply using aria2 at all (no parallelism with -j/-s) fixed the download rate. The primary difference was the User-Agent header; the standard youtube-dl User-Agent[1] was throttled, but "aria2/1.30.0" was full speed.
The throttling also seemed to depend on which server was sending the file; a bunch of recent uploads were throttled, while an obscure video from 8 years ago with <100 views only had the usual small slow-start delay that was common with videos that probably needed to be fetched completely uncached from from a remote data center.
The throttling problem seemed to go away after a few weeks, and returned again for a few hours a . Is it possible the "throttling" was actually some type of bug or configuration error in Google's network and/or data archives?
[1] https://github.com/rg3/youtube-dl/blob/master/youtube_dl/utils.py#L85 https://github.com/rg3/youtube-dl/blob/master/youtube_dl/uti...
- predakanga 8y agoIt's been my experience that only the split audio/video streams are throttled - it's possible that your obscure video didn't have those available for some reason, meaning that you got the unthrottled combined file. You can force this behaviour by using the "-f best" options, though that means you won't get certain resolutions (1080p) or codecs (opus). It's possible that this behaviour was designed to be pro-user; I can imagine a circumstance where a DASH (Dynamic Adaptive Streaming over HTTP) client hit a patch of network congestion, dropped to a lower quality, then the network cleared up and it downloaded the rest of the video in low quality before it could switch back. Throttling the speeds to just above the bitrate of the video would solve that. Mind you, that doesn't explain the user-agent targeting described in other comments...