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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2494 bytes --]

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

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.

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



thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".