Video Downloader: a GTK front end for yt-dlp, with the options hidden in GSettings

A window around a command line tool

Video Downloader is described as downloading videos from websites like YouTube and many others, based on yt-dlp, with an easy-to-use interface.

That base matters. Almost every capability the application has comes from yt-dlp, which is the component that knows how to talk to a site's API, how to handle the various manifests and signatures, and how to piece a stream together. The application is the part that makes it approachable: a file chooser, a quality picker, a list of a playlist's items, and a progress indicator.

The feature list in the README is short and each entry is a yt-dlp capability with a user interface in front of it. It converts videos to MP3. It supports password-protected and private videos. It downloads single videos or whole playlists. And it automatically selects a video format based on your quality demands.

That last one is the interesting design decision. The underlying tool exposes a large set of formats, and the application reduces that to a quality choice. The cost is that the choice is made for you, and the benefit is that you do not have to learn what a container format identifier means before your first download.

The audience is somebody on a Linux desktop who wants the file, not the pipeline. The licence is GPL-3.0, and the source is built with meson, with the interface in src, the translations in po, the flatpak manifest at the root under the application id com.github.unrud.VideoDownloader, and a snap directory alongside it.

Four packaging channels for the same application

The primary installation route is Flathub, with the application id com.github.unrud.VideoDownloader, and the README carries the badge for it. The alternative methods are listed separately: the Snap Store, Fedora with sudo dnf install video-downloader, and the Arch User Repository.

sudo dnf install video-downloader

Four channels is a distribution decision, and the shape of it is familiar. A Flatpak is the most likely to work on any distribution, because it carries its own runtime, and the Flathub listing is presented first for that reason. The Snap is the second most portable. The native packages, Fedora and the AUR, are for people who would rather not sandbox the application and would rather have it integrated with their system.

There is a practical difference between the channels that the README shows later and does not state up front. The configuration instructions are given separately for Flatpak and for Snap, because the way you reach GSettings from inside a sandbox is not the same as the way you reach it from a normal session. A user who installs the Flatpak and then tries the Snap command will get nowhere, and the README is structured so that this is a documentation problem rather than a mysterious one.

The application is also translated through Weblate, with a translation status badge, and the README asks people to contribute translations there.

The options that matter are in GSettings, not in a window

The section on hidden configuration options is the most useful part of the README, and it is where the application stops being a point-and-click tool.

The behaviour of the program can be tweaked with GSettings, which is the desktop configuration system, and the first example is automatic subtitles. The entry is a list of additional automatic subtitles to download, the entry all matches all languages, and the default is an empty list.

The commands are given per packaging format, because that is how the setting is actually changed.

For Flatpak:

flatpak run --command=gsettings com.github.unrud.VideoDownloader set com.github.unrud.VideoDownloader automatic-subtitles "['de','en']"

And for Snap:

snap run --shell video-downloader -c 'gsettings "$@"' '' set com.github.unrud.VideoDownloader automatic-subtitles "['de','en']"

Setting a GSettings key from outside the application, through the flatpak or snap wrapper, is the only way to do it, and that is why the README documents it this way rather than as a checkbox in the interface. It is a common pattern in desktop applications, where the window is a thin layer and the real configuration surface is the settings database.

The second reason to read that section is the debugging section, which is where the application tells you what it is doing. To display messages from yt-dlp, run the program with the environment variable G_MESSAGES_DEBUG=yt-dlp. And to display information about GOBject references, start the program with the environment variable G_MESSAGES_DEBUG=gobject-ref.

Those two variables are the difference between a support question that can be answered and one that cannot. The first turns the underlying downloader's diagnostics on, which is what you want when a site stops working, and the second surfaces object reference information, which is what you want when the application misbehaves in a way that looks like a memory problem.

The alternative is to run yt-dlp yourself

The obvious alternative to this application is yt-dlp on the command line, and since the application is built on it, the comparison is a comparison of interfaces rather than of capabilities.

Running the tool directly gives you the whole of it. The format selection is explicit, the output template is yours to define, the post-processing options are available, and a download becomes a line you can put in a script, a systemd timer or a Makefile. Everything the application does is available, and more.

The application gives up that control and buys three things with it. You get a file picker instead of a template string, so a download is a dialog rather than a line of shell. You get a format choice phrased as a quality decision instead of a list of container identifiers, which is the single biggest usability gap in the command line tool. And you get a playlist view where selecting a hundred items is a click rather than a loop.

The trade is the usual one. A window is easier and a script is more capable, and a person who already knows yt-dlp will find the application slower and less flexible, while a person who does not will find the command line impenetrable.

The packaging channels make the same trade in a second dimension. A Flatpak or a Snap isolates the application and makes it installable everywhere, and it also means the application runs with its own copy of yt-dlp, so a site that breaks the downloader is fixed by a package update rather than by anything you do.

And there is the question underneath both. The tool will fetch whatever a site serves to a logged-in or anonymous client, which is exactly what makes it useful for legitimate archiving and exactly what makes it a problem when the content is somebody else's. The application takes no position on that, and neither does the tool it wraps.

Editorial conclusion

Video Downloader fits a desktop user who wants to pull a video or a playlist for offline use without learning yt-dlp's flags, and who wants the same behaviour on Flatpak, Snap, Fedora and Arch. It does not fit a pipeline, because it is a windowed application and its options are per-user desktop settings rather than a scriptable interface. Before you install, check the packaging you want against the sites you use, and read the licensing position of the content you intend to download, since the tool is neutral about it and the responsibility is not.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Unrud/video-downloader on GitHub