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

[Vittorio Giovara]

On Mon, Jun 17, 2024 at 8:34 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Tue, Apr 30, 2024 at 07:42:53PM +0200, Michael Niedermayer wrote:
> > On Mon, Apr 22, 2024 at 01:32:27PM +0200, Lynne wrote:
> > > Apr 22, 2024, 13:07 by stefasab at gmail.com:
> > >
> > > > On date Sunday 2024-04-21 22:12:56 -0300, James Almer wrote:
> > > >
> > > >> On 4/17/2024 10:58 AM, Michael Niedermayer wrote:
> > > >>
> > > > [...]
> > > >
> > > >> A full rewrite of ffserver, using only public API, and with modern
> streaming
> > > >> in mind. It would give a lot of code in lavf some use.
> > > >>
> > > >
> > > > If this is going to happen, my advice is to use "ffstream" to stick
> to
> > > > the ffVERB convention (with the exeption of ffmpeg, which might still
> > > > be converted to ffconvert with some proper aliasing) and to avoid
> > > > association with the old incompatible tool .
> > > >
> > >
> > > That's basically what txproto is, only that it also does transcoding
> > > and filtering. It can accept incoming streams and output them to
> > > multiple destinations via remux or transcode. It was built as an
> > > ffmpeg.c with a scriptable interface and with dynamic switching.
> > > It doesn't do this out of the box, it's something you have to script,
> > > but that was largely the case that ffserver had.
> > >
> > > What is missing is something that ffserver had, which was that
> > > it was able to express exactly what lavf had in its context on both
> > > the sender and receiver, for which it needed private APIs.
> > > AVTransport can largely fill that niche.
> >
> > hmm
> > how would we (assert(people agreeing)) go from what you describe
> > to a (very easy to use) ffserver "2.0" in something on the ffmpeg.org
> download page
> > ?
>
> also if you look at google trends, even today more people search for
> ffserver
> than txproto. In fact at every point in time more people searched for
> ffserver
> than txproto.
>
> https://trends.google.com/trends/explore?date=all&q=txproto,ffserver
>
> So even though ffserver is dead, removed and unmaintained, it has more
> users
>

https://trends.google.it/trends/explore?date=now%201-d&q=ffmpeg,vlc&hl=it
By that reasoning we should stop working on ffmpeg and move off to working
on VLC

or mpv
https://trends.google.it/trends/explore?date=now%201-d&q=ffmpeg,mpv&hl=it


> And this comes back to what i said many times. We should use the name
> FFmpeg, our domain and NOT push every bit of new inovation out into
> sub projects.
>

https://trends.google.it/trends/explore?date=now%201-d&q=ffmpeg,gpac&hl=it
so you agree that we shouldn't have had gpac at the ffmpeg booth?


> We should put a newly developed ffserver into the main ffmpeg git.
> We should put wasm build support into the main ffmpeg git.
> We should turn ffplay into a fully competetive player.
>

We should move to a patch review system with a modern UI, like
github/gitea/gitlab, everything else is secondary
-- 
Vittorio