Recent searches
Search options
Administered by:
For #GNOME app folks: IMHO we need to think about what to do with Totem / Gnome Videos. It has not yet been ported to #gtk4, which is increasingly becoming an issue.
Apart from not fitting nicely UI wise, it prevents us from using the newly introduced #wayland hardware offloading (zero-copy playback) and, crucially, from (properly) supporting HDR content going forward.
I.e. we either need a port - or should consider making an alternative a core app to focus on.
Short 
If we go for an alternative, the main requirement is surely #gtk4 / #libadwaita with adaptive UI. For distros it's probably also important to have some kind of dependency management to install missing codecs.
The language could probably be anything from c, rust, vala or gjs.
I wonder about the backend - should sticking with #GStreamer be a requirement or is something based on #ffmpeg / #mpv ok as well?
One option based on #GStreamer and #gjs would be Clapper (https://github.com/Rafostar/clapper).
IMO a solid choice, but surely needs some polishing.
Another option I see would be Celluloid (https://celluloid-player.github.io/), a #gtk4 frontend for #mpv
We'd need to check if the offloading support from #gtk4 can be well integrated and if it generally would be a good fit for a #gnome core app.
End
P.S.: I was just made aware of glide (https://github.com/philn/glide) which has some compelling features:
- Written in Rust which is quite popular in the app community I hear.
- Seems to already support most stuff we need, could just use some UI refresh.
- Explicitly supported on MacOS. That's interesting because the hardware offloading in gtk4 so far only supports Wayland, but was written in a way to work on other platforms as well.
@rmader mpv is just wonderful
@rmader Clapper is by far the winner UI design wise
@rmader My dream scenario would be to use whichever has the best base of Clapper and Celluloid, and then take the best features/UX elements from the other and integrate into the first. They are both really nice, there's no need to do all the work to port Totem IMHO, but they are both also lacking a bit, and a blend of the two could be perfect. :)
@rmader In my opinion it's by far the best choice, the application is popular, stable and the developer seems to be polishing the API with his own Gstreamer-based libraries
→ See 
️ https://github.com/Rafostar/clapper/pull/374
@rmader GStreamer should absolutely be a requirement. GStreamer is used throughout the rest of the GNOME stack. Splitting developer effort into a project like MPV and FFMPEG seems like a bad idea to me. Now instead of implementing the features we want into GStreamer, the community would need to implement them in FFMPEG / MPV as well. The benefit of this is unclear to me...
(Continued)
@rmader IIRC, the MPV project also doesn't have a great track record. From memory:
- Hostile to XDG base dir specs. At one point support was intentionally disabled by the maintainer
- At one point MPV would intentionally abort if it detected GNOME
- MPV was building a custom build system. This is *always* a bad idea. As a packager, this tells me they had no idea what they're doing
IIRC the maintainer that did all this was kicked out. But I'd still avoid MPV because of this history. Bad look...
@rmader To the people that care about MPV: I mean no harm! If I got something wrong I'm just misremembering what happened and you should correct me. I've never really been involved with the MPV community and am going off my limited view as an outsider.
I have zero idea the shape MPV is in nowadays after removing that maintainer. But from what I recall, MPV wasn't the most GNOME-friendly project. Maybe this has changed. I am still skeptical...
@rmader Something I forgot to mention in my other reply. While something based on mpv (or even just another UI for VLC ?) would likely work well functionality-wise, you'll have a hard time getting this shipped by RHEL/Fedora/Ubuntu at least in a way that is actually useful for users.
Thanks to software patents in the US, you'll either have them not ship the application at all or an effectively useless version that only supports free codecs. And then people will just get VLC from some other place anyway so they can actually play their movies.
With GStreamer these other codecs could be provided separate from the application, and there's even infrastructure available in GStreamer to make discovery and installation of those easier (although especially RHEL/Fedora go out of their way to make this as useless as possible too, to appease their lawyers).
@rmader Also to be clear, this is still a big problem with a GStreamer-based player and one of the many reasons why nobody uses totem.
User wants to play a video, video does not play, no information why or how to solve that, first Google result tells them to install VLC, problem solved.
Until that is addressed, any GNOME video player can be as nice as possible, most people are not going to use it. And addressing that is apparently a very hard problem because of legal reasons, especially if you're RH.
What would be needed is that after "video does not play" above, the user just has to click a button to make it play and that's also the experience you get on Debian, for example. Anything harder that would involve searching something on the Internet means that most likely the user is going to switch to something else.
@rmader That's an extra step though, and at that point you will already have lost many people towards VLC.
It's the same with totem from flathub FWIW (minus useful hardware-decoding support).
@rmader See also https://gitlab.gnome.org/GNOME/totem/-/merge_requests/356
> The only way to distribute totem we support is through Flathub's
Flatpak
and
> the process was always very dependent on end-users having prior knowledge of where to get codecs
@rmader thinking about distributions - using GStreamer would probably make some things easier because it's more flexible and modular.
for example, using ffmpeg is quite awkward on Fedora because the version we can ship has all sorts of codecs patched out . replacing it with a full featured version from third-party repos is possible but frequently broken due to version mismatches.
with GStreamer, you can just pull in more codec support via additional plugins, which is quite nice in comparison.
@decathorpe FWIW., I personally am fully convinced now/again that #GStreamer is the way to go. For me the main arguments are:
- Things can easily be reused by apps - Gst does an incredible job in that regard.
- It shares the technical base with the rest of the Gnome ecosystem, integrates well. Including on the community level.
- It has well working hw decoders for basically everything, including V4L2 stateful and stateless.
But that's just my 2 cents.
@rmader @decathorpe This is one of the things I wish @kde also did. Unfortunately, there's little to no GStreamer advocacy or expertise in the KDE community, which makes life difficult if you would prefer a good framework for multimedia.
@rmader I'd love to see Celluloid fill this role. They even have an open RFC for a complete UI overhaul, and it's been a joy for actual production use for years in my experience now: https://github.com/celluloid-player/celluloid/issues/696
@rmader As others have already said we've long wanted this from the design side, but so far there hasn't been a successful effort to get a port over the line (or a replacement in shape), and a new design implemented.
In case anyone wants to give it another try, Allan updated the mockups very recently: https://gitlab.gnome.org/Teams/Design/app-mockups/-/blob/master/videos/videos-experiments-aday.png
@vixalientoots @tbernard That would be great - and probably a nice project to learn form! The open question is just still: which one?
If you want to look at glide: see https://hachyderm.io/@philn/111453578784670337
@tbernard @rmader Interesting! livi (https://gitlab.gnome.org/guidog/livi) used the older ones as a baseline. Time for me to catch up.
@agx Interesting - I wonder if we could make a player that works for you as well so you maybe just have to maintain a small fork?
In any case, I guess the gtk4 hardware plane offloading would be interesting for the librem5 as well - and could increase battery life quite a bit, assuming the video hardware decoder produces something compatible with display hardware (which *should* be the case).
@rmader I have looking at GTKs new hw offloading on my list, it currently just keeps slipping. Filed https://gitlab.gnome.org/guidog/livi/-/issues/5 to make that more obvious. (wouldn't only benefit the Librem 5 but also the mnt reform and MobileLinux in general).
@rmader IMO from a distro perspective GStreamer is a more flexible option.
@rmader I think Clapper and Glide are probably the most compelling options. I use Clapper on my Pinephone because it was the first with hardware acceleration and looks great but idk how well it's maintained, Flatpak keeps telling me that it's unmaintained. I don't know much about Glide and haven't actually used it but I found that a few months ago and it looks promising to me and checks all requirements I can think off.
@rmader We have up to date mockups for anyone who wants to work on a core video player (totem or otherwise): https://gitlab.gnome.org/Teams/Design/app-mockups/-/blob/master/videos/videos.png
@rmader Oh, I thought Daikhan would replace Totem 