Is download speed throttled by YouTube?

[DzenanJupic]

pytube (#1033) and youtube-dl (#29326) have open issues regarding YouTube throttling the download speed.

It would be interesting to know if that also affects us!

This comment from youtube-dl has a potential solution.

[fabi321]

Probably ever since I have used this library, I occasionally had downloads that ran at speeds of ~65k, and just restarting the download (thanks to closing the channel), fixed this problem every single time. I can't really tell if the frequency of those slow downloads has increased lately.

[fabi321]

After reading through the youtube-dl issue I got to this working implementation and a notable comment from the pytube maintainer.

[DzenanJupic]

@fabi321 thanks for the links, looks interesting. I'll have a look at it to see if we can integrate that in rustube.

[DzenanJupic]

Just found this while reading some youtube-dl code:

https://github.com/ytdl-org/youtube-dl/blob/a8035827177d6b59aca03bd717acb6a9bdd75ada/youtube_dl/extractor/youtube.py#L1674-L1678

Edit, since GitHub doesn't show the code:

[mehmetkursataydin]

I would really be happy if you guys implemented a solution to this, currently my app makes its users wait more than 5+ minutes on average for a video that could be downloaded in 30 secs or so. I wish I knew enough rust to help but I am so new so all I can do currently is to wish you all the best and try and take more attention to this issue from some helpful people

[jewlexx]

I gonna have a look into a possible fix, like the one in youtube-dl.

[nednoodlehead]

Is this issue fixed?

edit: forked repo has fix: https://github.com/Discursif/rustube

Edit: I dont think this fork is fixed anymore, downloads are still quite slow compared to pytube

[cjburkey01]

edit: forked repo has fix: https://github.com/Discursif/rustube

When I use this fork, the download "completes" immediately without actually downloading any part of the video, is it just me?

[ccgauche]

@cjburkey01 The fix I provided works well on audio but I haven't tested on video so can't really tell but it seems to work for others and passes tests.

[niek-peters]

The provided fix doesn't seem to work at all for me. Videos don't really download at all and just complete instantly. Downloading audio only streams is just as slow as without the fix.

It seems like pytube and ytdl-core don't have this issue anymore.

[ccgauche]

@MrValk My Youtube Music terminal player uses my fork and works well (On audio only). Audio downloading shouldn't be slow from my experimentation. I don't know if YT-dl or pytube found a better fix but that's probable.

[AhsanSarwar45]

I am still facing extremely slow downloads. A 1MB webm audio file takes an entire minute to download, whereas ytdl-core does it in 1 or 2 seconds.

[ccgauche]

Note that the fix that was used in Ytermusic doesn't work anymore there is probably some more reverse engineering to do on my side

[linuxfight]

Is this fixed? I've used forked repo, but it's not working for me

[nednoodlehead]

has there been any development on this? Downloads are still extremely slow, and maybe worth mentioning, that sometimes when downloading a few videos consecutively (or from a playlist, like my repo) it will pull a 403 error, which is quite inconvenient to work around

[ssddOnTop]

To save bandwidth, google (YT) only loads some part of the video based on your internet connectivity (I suppose).

I forked the repo and tried downloading it in parts, and it is MUCH faster, with just 4 parts it becomes 3.6x faster and with 8 parts, it is around 7.1x faster.. it will just speed up with the number of parts you enter (based on your internet speed).

If anyone wants this feature.. lmk I'll formalize stuff and create a PR.

Edit: My approach: download it in parts (parallelly or even asynchronously should work) and wait for all of them to finish task and merge them in single file.

To optimize it further, we can make a complete pipeline to parallely try to merge the parts as soon as they finish downloading (but this won't give much advantage as the parts in the middle might now have finish downloading before other parts).

One more edit: I misinterpreted the issue.. but I don't think my comment is far off :p

[nednoodlehead]

To save bandwidth, google (YT) only loads some part of the video based on your internet connectivity (I suppose).

I forked the repo and tried downloading it in parts, and it is MUCH faster, with just 4 parts it becomes 3.6x faster and with 8 parts, it is around 7.1x faster.. it will just speed up with the number of parts you enter (based on your internet speed).

If anyone wants this feature.. lmk I'll formalize stuff and create a PR.

Edit: My approach: download it in parts (parallelly or even asynchronously should work) and wait for all of them to finish task and merge them in single file.

To optimize it further, we can make a complete pipeline to parallely try to merge the parts as soon as they finish downloading (but this won't give much advantage as the parts in the middle might now have finish downloading before other parts).

One more edit: I misinterpreted the issue.. but I don't think my comment is far off :p

that would be great. the speed is the main issue for this repo tbh

[ssddOnTop]

The above SS shows download time for 1. "failed attempt" to download in parts, 2. default implementation 3. my wrapper to download in parts (10 parts in this case)

@nednoodlehead I blindly implemented my solution.. but that does not seems to work... I'll have to dig in to fix this but I do not have much time in hand.. I'll try my best to create a PR asap

[Mintype]

Is this issue still not fixed yet? I ask because I tried this library today and my code was just not exiting! I even picked a video shorter than 1 minute to try to get the download to finish, but it just takes so long!

[cjburkey01]

Is this issue still not fixed yet? I ask because I tried this library today and my code was just not exiting! I even picked a video shorter than 1 minute to try to get the download to finish, but it just takes so long!

Unfortunately I don't see this getting fixed (unless someone wants to convert all the yt-dlp logic in Rust). The best bet in my head for compatibility is just making a cli wrapper around that instead, a lot of work goes into keeping that up to date

[nednoodlehead]

use rusty_ytdl. it is so much faster @Mintype @cjburkey01