[FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

Matthieu Bouron matthieu.bouron at gmail.com
Mon Nov 28 12:36:56 EET 2016


On Mon, Nov 28, 2016 at 02:22:48AM +0100, Michael Niedermayer wrote:
> On Sun, Nov 27, 2016 at 05:31:39PM -0500, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Sun, Nov 27, 2016 at 1:46 PM, Michael Niedermayer <michael at niedermayer.cc
> > > wrote:
> > 
> > > On Sun, Nov 27, 2016 at 07:30:24PM +0100, Clément Bœsch wrote:
> > > > On Sun, Nov 27, 2016 at 06:49:35PM +0100, Michael Niedermayer wrote:
> > > > > On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> > > > > > On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> > > > > > [...]
> > > > > > > ffserver had 14 commits to it in about the last month
> > > > > >
> > > > > > That's also pretty close to the number of commits in the last years.
> > > > > >
> > > > > > Good will in the last weeks is not enough of a technical
> > > > > > merit/justification to prevent the removal of junk code scheduled for
> > > > > > deletion for a long time now.
> > > > >
> > > > > why do you call it junk ?
> > > >
> > > > because it's highly dependent on internal stuff, very limited, completely
> > > > untested, unmaintained for several years but still contains a ton of
> > > code.
> > > >
> > > > > and the sheduling for deletion was conditional on it not being fixed
> > > > > IIRC.
> > > > > Why the hurry to remove it while people work on fixing it ?
> > > > > its not blocking anything ATM AFAIK
> > > >
> > > > There is no hurry, but piling up a bunch patches to fix small things just
> > > > to use it as an argument to say "hey look now it's maintained" in order
> > > to
> > > > save it from being killed is really annoying. The people interested in it
> > > > had years to act.
> > > >
> > >
> > > > You can fix a ton of little things in it, but unless the fundamental
> > > > problems are addressed (ZERO internal API usage + at least partial FATE
> > > > coverage) it's pointless
> > >
> > > of course the goal is ZERO internal API usage + at least partial FATE
> > > coverage.
> > > Well in fact the lack of fate tests have been the primary reason
> > > why i didnt fix some of the API issues years ago. I felt uneasy
> > > changing it without regression tests
> > >
> > >
> > > > and will be seen as yet another case of "KEEP
> > > > EVERYTHING FOREVER" toxic mentality.
> > >
> > > The opposit is toxic too
> > 
> > 
> > I'm perfectly fine with keeping the code, just not in the ffmpeg tree.
> > Please move it to its own tree.
> > 
> 
> > Everybody wants it out. Please follow majority.
> 
> Some people want it out yes, how many and what the majority want i do
> not know.
> Some people also wanted all tools treated equally and moved out (again
> i dont know how many support that)
> 
> Spliting just ffserver out means more work for whoever maintains it
> setting up seperate infrastructure, seperate coverity, coverage, fate,
> ...
> theres a lot of work in all this, its long term continuous effort
> and this is time that wont be spent on FFmpeg.
> 
> I dont know if people want me and reynaldo to spend less time on
> FFmpeg, but time is a finite resource. If ffserver is maintained
> externally it would mean a noticable hit in maintaince man hours of
> FFmpeg. Now it might be that ffserver being pushed out would kill it.
> But really as dumb as i am, i dont belive theres a majority who wants
> to kill FFserver when there are people who actively work on it and
> care about it.

Just a thought, maybe ffserver could live in a separate branch for some time ?

[...]


More information about the ffmpeg-devel mailing list