[FFmpeg-devel] [RFC] 5 year plan & Inovation

[Michael Niedermayer]

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 <michael at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240618/c640c611/attachment.sig>