[FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Fri, 9 Dec 2016 00:30:24 +0100
Andreas Cadhalpun <andreas.cadhalpun at googlemail.com> wrote:

> On 08.12.2016 15:53, wm4 wrote:
> > (I'm still waiting for related work to be merged from Libav).  
> 
> Why don't you merge it yourself instead of waiting for others?

The commit to be merged next appears to have some intrusive h264 decoder
changes. I'm not going to touch that.

> > So yes, removing things can mean progress.  
> 
> However, removing ffserver now doesn't, because the libraries
> have to keep backwards-compatibility until the next major bump
> anyway.

I'd agree with this, except I know that if the time comes for a major
bump that necessitates immediate removal of ffserver, a new discussion
about ffserver will break out, and the bump (or removal of the
deprecated things ffserver relies on) would be delayed. If this is how
development work (maybe it does, maybe it doesn't), then shitflinging
is an inherent part of the project's developer culture and the only way
to achieve something. Blergh.

Maybe this is not a problem anymore. ffserver.c still brings up some
deprecation warnings, but surely michaelni will send a patch soon to
fix those.

This discussion is worth leading in general anyway.

> > Nobody would care if ffserver actually used the ffmpeg libs correctly.
> > But it still requires ffserver-specific code in libavformat. And even
> > after all of michaelni's oddly-timed hard work to cleanup ffserver,
> > ffserver itself uses internal libavformat stuff (see
> > libavformat/libavformat.v - it also includes internal headers).  
> 
> Yes, that's the last point that needs to be fixed before the next
> major bump if ffserver is to be kept.

I didn't check whether the internal libavformat would break ffserver on
the next bump, or if there are other hidden internal or deprecated API
uses, but yeah.

> > This project is frustrating because it puts features (even broken,
> > half-implemented ones) over robust implementation and ease of use, and
> > on top of it is unable to enforce any policy or decisions the community
> > may have made. You have to waste your time discussing about nothing to
> > overly... self-confident... people when trying to make a change.  
> 
> You don't have to waste everyone's time complaining like that.
> It'd be much better if you'd instead spend the time working on reducing
> the backlog in the merges from Libav.

I could as well say: you don't have to waste everyone's time defending
ffserver, you could just spend time on fixing it instead.

You don't have to say anything about the general way ffmpeg development
works?

> The next bump, which is already discussed on the Libav mailing list, will
> be merged that much sooner.