[Feature Request]: Use youtube dlp as a backend to extract videos

[Destroyinator69420]

Guidelines

• I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
• I have searched the documentation for information that matches the description of the feature request I want to file, without success.
• This issue contains only one feature request.

Problem Description

Often the local API does not work, and the invidious api can be slow. ytdlp has a proven track record for downloading youtube videos, and it has an option to pipe the stream to a media player, this can be freetube. ytdlp us written in python, and python code can be packaged as a zip archive the python interpreter can execute using zipapp. Inbuilt ytdlp will provide a compelling alternative to the local api and invidious, which is not maintained as frequently as ytdlp.

Proposed Solution

A zipapp of ytdlp will be packaged with Freetube, and the python interpreter installed on the OS will execute it. The zipapp will be installed with the program files of Freetube and the freetube app will run the zipapp to pipe the url into the Freetube player.

Alternatives Considered

One possible alternative would be to fork invidious and develop this fork specifically for Freetube. The freetube community would run instances, and instances that follow privacy and security best practices would be built into freetube as options. Another idea would be to use the newpipe extractor, which does the same thing as ytdlp, as well as extracting peertube, soundcloud, media.ccc.de and bandcamp along with youtube.

Issue Labels

new feature, new optional setting, support for external software

Additional Information

No response

[absidue]

Shipping a specific version of yt-dlp with FreeTube wouldn't fix the local API issue at all, because when YouTube changes stuff yt-dlp breaks too, just like the local API. It would still require a new FreeTube release to get an updated version of yt-dlp. So all it would really do, is significantly increase the amount of work needed to maintain FreeTube, as we would now need to ship and keep a Python runtime (last time I checked the download statistics on GitHub etc, majority of FreeTube users are using Windows, which doesn't have Python built-in) and multiple Python dependencies up to date, in addition to maintaining the already existing local API and everything else in FreeTube.

[absidue]

Embedding the NewPipeExtractor would have the same issues as yt-dlp, as the NewPipeExtractor is written in Java, so we would need to ship a Java runtime with FreeTube.

Also forking Invidious is not going to benefit anyone, if you want changes made to Invidious, you are much better off making pull requests upstream instead of fragmenting the Invidious development efforts resulting in a worse time for everyone, as we would have to split our time between working on FreeTube and a custom Invidious fork, so this would actually be a disadvantage to FreeTube users and the Invidious community.

[ChunkyProgrammer]

@Destroyinator69420 I think this is the solution that you are looking for https://git.sr.ht/~cadence/NewLeaf

It should theoretically work with FreeTube but I have not tested to make sure

[ChunkyProgrammer]

Closing as:

• this would likely cause issues with some OS
• we'd need to ship runtimes with the application which can bloat it.
• this will be a lot of effort
• The local api for the next version of FreeTube has changed completely and should be more resilient to breaking.
• NewLeaf should work (which is an invidious compatible api that uses ytdlp in the background)
• we have an issue for supporting Piped Support for Piped (Invidious alternative) #1527