[southerntofu]

I think a lot of people are looking for that. This is especially true for folks with lower-end hardware where hardware decoding may be supported by the system but not (well) by the browser, or at least the rest of the browser runtime would use way too much resources.

NewPipe on Android is somewhat popular because it's much lighter than other Youtube clients (browser included) and enables features which Youtube official clients prevent on purpose (audio-only, download). We don't have an equivalent to that on the desktop. gtk-pipe-viewer [0] is close to that, but is not widely available yet.

A problem you need to tackle when distributing a 3rd party client for a centralized network is you have to deal with constant micro-changes in the public-facing API, which the silo does on purpose to break 3rd party clients. youtube-dl from distro repos is almost unusable all the time because of that except on rolling-release (most people use pip version instead), and Newpipe had to make their own F-Droid repository because f-droid.org vetting/build process is too slow for that particular usecase. [1]

EDIT: If you're looking for solutions to distribute your client, packaging for every distro out there is "hard" (better leave that to distro maintainers, except for your favorite distros of course) but there's a few distro-agnostic formats that are very easy to automate builds for: 0install, AppImage, Flatpak, guix, nix. The first two are statically linked (and PGP signed) and 0install is even compatible with Mac and Windows build (and any other platform, theoretically). Flatpaks are more Linux specific (some *BSD support in progress) and require a bit more setup to interface with other parts of the system escaping the sandbox (eg. for VAAPI), see the Portals mechanism. nix/guix are intended for reproducible builds: you need to package your dependencies first so it's definitely easier to get started if most of your dependency tree is already packaged there.

All in all, supporting those 5 build systems should keep you busy for a few days at the start of your project but will be a huge win for portability and maintainability in the long run. If your project's architecture is not too complex and the dependencies are easy to package, some external contributors (me?) could help with that.

Good luck on your project!

[0] https://github.com/trizen/pipe-viewer [1] As a user i'm happy f-droid.org default repo goes to great length to ensure quality of apps on there and that no antifeature are silently introduced by updates, but i'm also happy apps with specific needs for rapid upgrades like Newpipe can develop their own repo, and a simple QRCode can help bootstrap the repository entry + PGP key without having to mess around with repo settings manually

[Orionos]

> I think a lot of people are looking for that. This is especially true for folks with lower-end hardware where hardware decoding may be supported by the system but not (well) by the browser, or at least the rest of the browser runtime would use way too much resources.

That's what I'm trying to archieve with a C++ client. I feel like picking C++ with Qt is the best in terms of portability and performances. As a Youtube binge watcher I feel like I'm wasting resources by going through a browser. Honestly that's still really basic. A few API calls for search and recommended, and then delegate the core functionalities (playing and downloading media) to vlc and youtube-dl (need to switch to the new and maintained equivalent btw)

> If your project's architecture is not too complex and the dependencies are easy to package, some external contributors (me?) could help with that.

I plan on doing some cleanup and post an MVP on HN, I'll keep you updated!

[southerntofu]

> I feel like picking C++ with Qt is the best in terms of portability and performances

It is! I personally have a personal preference for Rust (though i've never done anything GUI with it) but i'm really glad to hear you're not building yet another electron horseshit that's unusable if you don't have the highest-end hardware :)

> wasting resources by going through a browser

We are. I personally don't use Youtube (though all my friends do) but when i really need to, i use an invidious instance. When it works, it works fine... but in my experience some videos require trying from different invidious instances, not entirely sure why.

I also took part in a web-based lightweight peertube client that works well with noscript [0] and here the experience is much more convenient because there is no private API and you can just hit (ActivityStreams) JSON to figure out everything about videos. I sure hope your client will support Peertube videos, too!

Back to the topic of wasting resources: ideally a video client would support local proxies like apt does for packages. Especially in places with slow uplinks, folks can get creative with their LAN setup, but deploying your own CA's public key on every connected device (for HTTPS MitM proxy) is not realistic.

> (playing and downloading media) to vlc

As a tech person, i love that. Just pipe stuff into stuff, and keep everything simple stupid. However, for non-tech people that kind of UX pattern is not always straightforward. There's already many ytdl->vlc/mplayer CLI pipelines, but nothing i can recommend to my friends unfortunately, at least not those who are not familiar with command-line.

If you'd like to build a popular client (i don't mean famous, i mean accessible to most people) i would recommend to consider a single-window experience where people familiar with a youtube.com browser tab will feel at home.

> youtube-dl (need to switch to the new and maintained equivalent btw)

What's the new and maintained equivalent? I thought ytdl was well maintained, although it also has popular forks which change some CLI behavior.

> I plan on doing some cleanup and post an MVP on HN, I'll keep you updated!

Please do! If by any chance i'm not on HN just drop me a mail my user name @ thunix .net or you can find me on many selfhosting/anarchism Jabber/IRC chatrooms.

[0] https://tildegit.org/southerntofu/simpleertube/src/branch/le...