[Feature Request]: Add yt-dlp intergration

[KerballOne]

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

#4178 #8966 #9572 #8543

Description

This adds the feature request from #4178 which was closed when it was decided to remove the built in download capability. But the feature request is now needed MORE because the native download feature is gone.

This implementation follows was initially based on @absidue's last comment on the subject #4178 (comment)

Screenshots

Testing

• If yt-dlp is not installed, pressing a button action will show a toast error and clicking that will take you to the new settings page.

Configure:

1. Go to Settings > External Downloader
2. Enable Downloads
3. (optional) Click the Download yt-dlp button
4. (if not detected in $PATH) Choose the executable file
5. (optional) Set an output directory
6. (optional) Set custom arguments (blank will work with yt-dlp defaults)

Download:

1. Click the Download button in the Player window
2. (optional) Choose a time span option
3. Click Video or Audio button
4. (if output directory not set) Choose a Download directory from the popup
5. View the terminal output for any errors or warnings
6. Go to the Output folder to check the file that was created

Desktop

• OS: Windows
• OS Version: Windows 11
• FreeTube version: v0.25.2 Beta

Additional context

Should work for MacOS or Linux builds. The executable chooser button should filter on exe only on Windows. And the arguments for yt-dlp should be the same. Although not tested on any thing other than Windows 11.
Update: Tested on Fedora 43 (xfce) too.

[PikachuEXE]

Download dropdown looks strange when there is nothing displayed (just buttons on the left
Inputs of timestamps doesn't look like inputs
Pressing buttons with invalid settings should only get a toast which redirects to settings page on press instead of redirecting users right away
I can download without setting download folder? (It downloads to my FT folder

My custom build: https://github.com/PikachuEXE/FreeTube/actions/runs/31294106398
(I am using --merge-output-format mp4 --remux-video mp4 -S vcodec:av01:h264,lang,quality,res,fps,hdr:12,acodec:mp4a for mp4 download)

Can we add a button to list formats and another to allow custom format download (or maybe another PR for that I guess?

[KerballOne]

Inputs of timestamps doesn't look like inputs

Fixed.

Pressing buttons with invalid settings should only get a toast which redirects to settings page on press instead of redirecting users right away

Done.

I can download without setting download folder? (It downloads to my FT folder

Fixed. Now the output directory is auto-populated with the user's default Downloads folder. Still allows user to change.

4ba728d

---

Download dropdown looks strange when there is nothing displayed (just buttons on the left

Could not replicate. At what point is there nothing displayed?

Can we add a button to list formats and another to allow custom format download (or maybe another PR for that I guess?

I thought the objective was to keep options in FT to the minimum needed to just be a frontend wrapper for yt-dlp? So FT doesn't need to keep up with changes or maintain a list of options? The defaults just work, but users can go to the yt-dlp README for any and all guidance on custom formats, bitrates, and other options.

[absidue]

Now the output directory is auto-populated with the user's default Downloads folder. Still allows user to change.

We cannot use a hardcoded path like that, we always need to prompt the user as in flatpak builds for example the app is only granted access to paths/folders that the user selected in a file picker. You can follow what we do for the screenshot folder (if it is unset or the folder does not exist or freetube doesn't have write access when the user takes their first screenshot we prompt them to pick a new folder).

Can we add a button to list formats and another to allow custom format download (or maybe another PR for that I guess?

I thought the objective was to keep options in FT to the minimum needed to just be a frontend wrapper for yt-dlp? So FT doesn't need to keep up with changes or maintain a list of options? The defaults just work, but users can go to the yt-dlp README for any and all guidance on custom formats, bitrates, and other options.

This pull request already does more that I am personally comfortable merging with the separate audio and video buttons, the timestamp selector, download folder management and ffmpeg management. Part of the reason we got rid of the downloader was that I didn't want to maintain it and consider it out of scope for FreeTube, not just the calls to YouTube but everything around it.
My original suggestion, which you claimed this pull request was based on, was for a single download button on the watch page and just fields for the yt-dlp executable path and args in the settings. FreeTube would then just call the yt-dlp executable with the users args + the video URL and unref the child process so FreeTube is no longer responsible for it. If the user wants to do any customisations they should add their custom args to their yt-dlp config file or in that args field in the FreeTube settings.

[efb4f5ff-1298-471a-8973-3d47447115dc]

I agree with absidue, the scope of this PR has been expanded too much. I would be comfortable with the original suggestion

was for a single download button on the watch page and just fields for the yt-dlp executable path and args in the settings. FreeTube would then just call the yt-dlp executable with the users args + the video URL and unref the child process so FreeTube is no longer responsible for it. If the user wants to do any customisations they should add their custom args to their yt-dlp config file or in that args field in the FreeTube settings.

[PikachuEXE]

Download dropdown looks strange when there is nothing displayed (just buttons on the left

Sorry, I mean the button placement is off to the left side fo no reason

e.g. Share dropdown got centered buttons

[absidue]

@PikachuEXE That dropdown shouldn't even exist, so layout issues inside it are irrelevant to getting this pull request into a mergable state.

[KerballOne]

I mean the button placement is off to the left side for no reason

Fixed. See above screenshot in OP.

We cannot use a hardcoded path like that, we always need to prompt the user as in flatpak builds for example the app is only granted access to paths/folders that the user selected in a file picker. You can follow what we do for the screenshot folder (if it is unset or the folder does not exist or freetube doesn't have write access when the user takes their first screenshot we prompt them to pick a new folder).

Fixed. It now behaves similar to the Screenshots feature, complete with write perm check.

This pull request already does more that I am personally comfortable merging with the separate audio and video buttons, the timestamp selector, download folder management and ffmpeg management. Part of the reason we got rid of the downloader was that I didn't want to maintain it and consider it out of scope for FreeTube, not just the calls to YouTube but everything around it.
My original suggestion, which you claimed this pull request was based on, was for a single download button on the watch page and just fields for the yt-dlp executable path and args in the settings. FreeTube would then just call the yt-dlp executable with the users args + the video URL and unref the child process so FreeTube is no longer responsible for it. If the user wants to do any customisations they should add their custom args to their yt-dlp config file or in that args field in the FreeTube settings.

Acknowledged. I did originally attempt a barebones implementation based on your original comment. But that can actually be mostly done already by just overriding any option with the yt-dlp binary. No PR needed.

But... the user experience is extremely poor and would not handle the common use cases.

Unfortunately, the user expectations for FreeTube calling an external player, is pretty different than a downloader program like yt-dlp.
For a player, it is fine to only pass along the video id and the current timestamp.
For a downloader, the user will often need different options depending on the video. A separate button for audio is a must since getting songs is a common use case. And the time span option is critical for users who can't be expected to download entire hours long, gigabytes of video just to get a short snippet. These are not needed for an external player of course.

For a proper downloader integration, it's fine for the vast majority of options like file format, encoding, bitrate, etc... to be defined as Global arguments in the settings, the user won't likely need to change them in-between videos.
But per-video dropdown options for audio and time span are needed to meet the minimum viable expected behavior.

I removed the ffmpeg handling entirely, since you're right, it would add unnecessary management that yt-dlp already does and shows the user if needed. What remains, are the dropdown options for timespan and audio/video buttons, which doesn't create additional maintenance since it still only passes different arguments when calling the yt-dlp executable. Fire and forget similar to the exec + args passed for named External Players. And the UI elements of the dropdown are similar to the Share Dropdown.