[FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023

[Rémi Denis-Courmont]

Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a écrit :
> In the past, most developers in FFmpeg where primarly FFmpeg developers. But
> as FFmpeg is used by almost everyone now, that has changed and many
> developers in FFmpeg today are primarly developer of 3rd party projects
> using FFmpeg.

What does that even mean, really? FFmpeg is and has practically always been 
first and foremost a library. It is only natural that people involved will also 
be involved with one or several reverse dependencies. Already twenty years 
ago, the FFmpeg developer body was supposedly heavily overlapping with 
MPlayer's...

I would understand that sort of argument for projects that are mostly ad-hoc 
programs, and also happen to provide libraries, such as LLVM (incl. Clang) or 
VLC but FFmpeg, not so much.

Also FWIW, while I have probably contributed to FFmpeg more in the past 12 
months than in the 19 years prior, my first patch merged in FFmpeg goes way 
back over 10 years ago. And conversely, while I am often associated with VLC, 
the reality is that I have barely written any merged code in VLC in the past 
couple years.

> Should decissions in FFmpeg be made to maximize benefit / be optimal for
> FFmpeg ?

How do you define benefit for FFmpeg? This is real life, not an RPG. We can't 
simply do linear optimisation to find out what the right choices are. With that 
said, everybody will agree with that vague phrasing to maximise benefit to 
FFmpeg, and yet nobody will agree what that means and this won't change 
anything.

You really need to make more concrete suggestions on this particular point 
(and the rest of the email touches different issues, IMO).

> There has been a marked shift of project goals over the years. While long
> ago FFmpeg was "all of multimedia". With time the scope of the project has
> shrunk.

AFAICT it is rather that FFmpeg failed to capture the bits of multimedia that 
its reverse dependencies had already implemented decently well first - audio 
and video outputs, and user interfaces, being the obvious elephants in the 
room. I don't think FFmpeg should waste time trying to reinvent SDL and 
Placebo at this point, even less a web browser.

Also FFmpeg *did* expand into filtering with some success.

And now would probably be a good time to expand into WASM platform support 
(especially SIMD).

> FFserver was removed not improved, not replaced.
> the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*,
> rv* and others and at the time was the best encoder available (not anymore
> now, no) but after mpeg4-asp, modern video encoders where no longer added
> to ffmpeg. In one case a advanced encoder for a fringe format was rejected.
> AI based filters are neglegted at a time everything is shifting to neural
> networks and AI. Clientside / "in browser" also has become very important
> but is absent from our documentation, our fate tests, and so on

This is more of a question of whether FFmpeg should have subpar 
implementations vs no implementations.

But as much as many (including myself) will agree that it is better to 
implement stuff in FFmpeg than add new dependencies to it. Yet it's all cheap 
talk unless somebody actually does the work.

As a counter example, I certainly won't be implementing EVC or VVC in FFmpeg 
myself, and even the HEVC implementation leaves to be desired according to 
many.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/