pytube VS yt-dlp

Quicker explanation of how Youtube is doing it is at the source code of pytube: https://github.com/tfdahlin/pytube/blob/bb890af3b271a616bbe1...

This is linked from the description of PR 30184 of youtube-dl but @varenc linked to a specific comment (talking about patching Windows builds, AFAICT) which might confuse some people.

I'll even save you the click:

> YouTube's strategy to restrict downloading videos is to send a ciphered version

There are workarounds (detailed very nicely in dirkf’s pull request for youtube-dl):

https://github.com/ytdl-org/youtube-dl/pull/30184

Pasting the content here for convenience:

Since summer 2021, YouTube has started serving media URLs with a query parameter such as …&n=SXiXBH-xzrjeioPN&…. This now appears to be the default behaviour. Unless the value of this parameter is transformed according to an algorithm delivered in the site player JS, the download speed for the URL is throttled to ~50kB/s.

Solutions for this include:

• implementing a more complete JS interpreter, eg based on PR [jsinterp] Actual JS interpreter¹ #11272;

• using an external JS interpreter (PhantomJS, now unmaintained, is used by some extractors);

• spoofing the Android or iOS client to acquire unthrottled links, as successfully implemented in yt-dlp².

This PR takes a different approach derived from the successful solution used in VLC's youtube.lua (also implemented differently in pytube³). The approach relies on the fact that the challenge algorithm is served in a mini-language within the minified player JS and therefore the specific algorithm can be extracted and executed by interpreting the mini-language without actually running the JS itself. [In parallel with this PR, a separate implementation of this approach was added to yt-dlp⁴.]

The implementation of the mini-language interpreter is directly translated from VLC's n_descramble() Lua function⁵. The result sufficiently resembles the original that it should be straightforward to share changes between the two implementations.

――――――

¹ — https://github.com/ytdl-org/youtube-dl/pull/11272

² — https://github.com/yt-dlp/yt-dlp/commit/c888ffb95ab0ab4f4cd1...

³ — https://github.com/tfdahlin/pytube/blob/bb890af3b271a616bbe1...

⁴ — https://github.com/yt-dlp/yt-dlp/commit/404f611f1c4aa516fbc4...

⁵ — https://code.videolan.org/videolan/vlc/-/blob/4fb284e5af69aa...

You can put these options in a config file and they will become the default: https://github.com/yt-dlp/yt-dlp?tab=readme-ov-file#configur...

Yep. yt-dlp and youtube-dl

https://github.com/yt-dlp/yt-dlp

https://github.com/ytdl-org/youtube-dl

Will also start to feel the impact. My theory is that we will see a bunch of new video hosting sites as youtube itself attempts to lock down its ecosystem. They haven't paid attention in any adversarial way as far as I can tell.

When they do, it wont be great.

The points you make aren't unreasonable.

It is necessary to establish clear boundaries of what can and can be provided by the maintainers. If not done at an earlier stage of the project, the support burden becomes too much to bear at which point the maintainer transfers ownership, and the project suffers from catastrophic consequences such as the xz backdoor we're talking about here, or other cases where the project mostly stalls and serves as an ego-boosting platform for the new maintainer, as was the case with PhantomJS[6].

This can also happen in your life, where a "friend" sees that you possess a certain skill, and then gradually tries to push an inordinate amount of their personal work related to this field onto you.

Personally, I think it's best to use an approach with extremely clear communication as to what the maintainer can and cannot provide. This can be seen, for example, in yt-dlp[1], where the consumer is clearly informed upfront that not providing detailed information as requested will lead them to block said consumer; or sqlite where their position regarding contributed patches[2] and support[3] is similarly made clear.

Having a shouty BDFL like Torvalds can also help improve code quality[4] and questionable contributions[5], though it is better that the shouty BDFL makes statements that are professional and do not show as much aggression; so for example, "Mauro, shut the fuck up"[7] would become "Mauro, your response is completely unbecoming for a Linux kernel maintainer, and is not in line with the promise of not breaking userspace."

[1] https://github.com/yt-dlp/yt-dlp/issues/new?assignees=&label...

[2] https://www.sqlite.org/copyright.html

[3] https://www.sqlite.org/support.html

[4] https://www.theregister.com/2024/01/29/linux_6_8_rc2/

[5] https://cse.umn.edu/cs/linux-incident

[6] https://github.com/ariya/phantomjs/issues/14541

[7] https://lkml.org/lkml/2012/12/23/75

Or just "yt-dlp "

yt-dlp ( https://github.com/yt-dlp/yt-dlp ) still works pretty well at the current state of Twitter.

To download audio from YouTube videos, you'll utilize the widely used yt-dlp library, which can be installed using the pip command as follows:

Use: `yt-dlp with --write-comments --no-download --batch-file FILE`

- FILE is a text file with a list of YouTube id's/URL's

- https://superuser.com/a/1732443/4390

- https://github.com/yt-dlp/yt-dlp

> Then youtube-dl wasn't a thing anymore (maybe it is again?)...

yt-dlp is definitely a thing: <https://github.com/yt-dlp/yt-dlp>