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

[Michael Niedermayer]

On Fri, Sep 08, 2023 at 06:42:49PM +0300, Rémi Denis-Courmont wrote:
> Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a écrit :
[...]
> > 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.

I think i really only meant the part "everybody will agree with", i dont
think the exact definition is that important. Because i think something
"good" will be good under most definitions that optimize something tangible

But for sake of academic argument, we could consider more specific definitions
like:
"maximise the time and money people safe" so if you fork planet earth
and one has one kind of FFmpeg and the other has another which side on average
safes people more money and time

from this, optimization follows, bit also bug freeness and also being maintainable
and clean and well structured because otherwise code just becomes shitty and so
does user experience ...


> 
> 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.

i do think libplacebo functionality belongs in and is needed inside FFmpeg.


> 
> 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).

yes


> 
> > 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.

I think theres not one awnser that fits all cases here.
Having a simple and clean implementation thats good enough can be usefull especially
for areas where the "goodness" doesnt matter much and things require no real
maintaince
OTOH an implementation thats not "good enough" is bad

I mean if for a fringe game format we had an encoder thats 5 pages of C code
and achives 95% of the compression of the best. And the 100% one would be
1000 pages of code in an external lib. Id say the 5 page encoder is good
enough to include and support.
OTOH 95% compression of the best for a major format like h264 i think is not good
enough and we should not do that.
All this of course is subjective

thx
[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.
-------------- 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/20230909/3ed7e280/attachment.sig>