On Mon, Jun 17, 2024 at 8:34 PM Michael Niedermayer <mich...@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 stefa...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
