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.
@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.
@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).
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?
@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...
@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 I prototyped a gtk4 video player 2-3 tears ago when we were playing with the new designs for it, but while doings so I became even more sure that there isn't a need for anything new or different and we could should just work on totem instead.
There isn’t anything wrong with totem, the codebase is great even after all these years, it just needs a person with time to spent on it.
@alatiera@rmader from the design side, I can see some things we would probably want to revisit. But at the very least, yeah, a GTK4 port would be nice.
I know there are questions about the utility of the plugins (e.g. does anyone with an Internet connection actually watch movie trailers in Totem versus a website?), and maybe the library view versus being focused on playback (do people keep local libraries of video files and want to browse them in the Videos app instead of the Files app?).
@alatiera@rmader so I guess my question is: what’s preventing forward progress with Totem? If it’s without a maintainer, can we more loudly publicize that/call for maintainers? If the worry is designs for a GTK4 port, can the design team brush off and update any existing designs/work with someone to do the port?
I’m personally invested in this because we have talked about it a bit from the design side and we ship Totem on Endless OS, but I’m not really aware of any other happenings around it.
@cassidy@alatiera I think it's worth mentioning that for a long time there wasn't much interesting happening on this front. But now #Wayland (and thus proper, desktop integrated zero-copy playback) is becoming mature and HDR is around the corner.
@alatiera@cassidy We #Wayland folks are hard on it I'd say - and given how bad the state is on other OSs it's an area where we have a chance to shine - especially if we manage to get lots of the infrastructure work paid by television vendors, google, amazon or car makers.
@cassidy@rmader It’s not exactly without a maintainer. The vibe I have is that Bastien is very much still passionate about it and tries his best to take care of things, but there also no people that have showed up to help with either.
Redhat recently decided to make an example out of certain people cause they dared to unionize, so we certainly not going to see any paid time to work on it soon, but those people still care and I am sure would welcome any help with project.
@cassidy@alatiera I wonder if the usefulness of such tools actually increased with #LinuxMobile (hopefully) becoming a thing (if the app as a whole was fully adaptive) - but in generally I agree that it'd be fine to drop stuff if it helps to make the core more maintainable.
@rmader@alatiera ah true, a “gallery” sort of view could be nice on a phone, but then again, I feel like that could be yet another app (oh no!) because I would want my photos and videos that I took on said phone listed together somewhere other than the Files app… hrm.
Gallery app for viewing the library, then open items in the default file handler (e.g. Loupe or Totem)? 🤔 Have I just reinvented something old and created more work? 🤔🤔
@alatiera@rmader yep, it isn’t relevant to us at Endless OS and I think Fedora made a similar decision recently for codecs (e.g. they should be automatically installed on update versus prompted at playback time). Maybe that would simplify it… 🤷♂️
@alatiera Thanks, that pretty good to hear - I wonder if such a port could also make use #gtk4 s GtkVideo / GtkGstSink which are used for the gtk demo player (gtk4-demo --run=video_player)
That would mean an even bigger part of the technical base could just live in gtk, which possibly would make HDR upbringing easier.
@alatiera@rmader@slomo as somebody very clueless about gst, what prevents GtkGstMediaFile from doing what the Rust paintable sink is doing? I.e. why is there a need for an external paintable sink over what's built into gtk? Could the Rust paintable think be un-RiiR'ed and incorporated into GtkGstMediaFile?
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 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. :)
Add comment