On Mon, Jun 17, 2024 at 11:02:31PM +0200, Rémi Denis-Courmont wrote: > > > Le 17 juin 2024 20:34:39 GMT+02:00, Michael Niedermayer > <mich...@niedermayer.cc> a écrit : [...] > >We should turn ffplay into a fully competetive player. > > No. First there is no such thing as "a fully competitive player". You would > need at least one mobile player, one smart TV and STB player and one desktop > player, on top of the existing crude CLI player. And that's if you manage > Android and iOS, mac and Windows, together. Otherwise it's even more players.
Maybe "fully competetive player" was a bad term I think ffplay is quite close to being fully competetive. I do use it 95% of the time and iam not feeling like iam missing something > > Then you would need each of them to have features that FFmpeg doesn't have as > a back-end, notably media library management. we support various playlists. That could be extended but i agree some kind of playlist display and editing / (media library management seems a fancy term for that) is important for some users > > That's a lot of work, mostly GUI work. No offence but you and most other devs > here don't strike me as GUI devs. VLC is pretty much dead now for > under-estimating how hard it was to rewrite the desktop UI. How will you find > and keep motivated the developers for all that UI work? They are not going to > manifest spontaneously, even less so in a community with a deservedly > horrible reputation as FFmpeg's. I have written basic GUIs in some toy projects long prior ffmpeg, I remember having had a multi level menu and a animated raytraced mouse cursor in one ;) it was just a few lines of C + ASM code but looked quite good for the time. And in the software defined radio code i had written there was a vissualization with the decoded channel/artist/song names drawn on the spectrum waterfall plot thingy. If one wants to write a GUI with 10 differnt high level APIs, its going to be alot of code and hard to maintain (keeping up with each platforms / lib GUI APIs and all the bugs) I see nothing wrong with making it easy for people to do this if one wants to maintain a specific GUI for a specific platform. But supporting 10 GUI libs wasnt what i had in mind Instead really we need just one GUI, and 2 variants (one for touchscreens and one for non touchscreens) implementing this with nothing but ANSI C and a framebuffer / 2d array of pixels is very doable. It can be made to look quite good, it depends on no APIs, and its not alot of code. One can of course also instead use some portable GUI library, i think whoever works on such GUI would decide how to do it. > > Unless you just won the Euromillion or something like that, this is not going > to happen. No ifs or buts about it. I think we where thinking of different things thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
