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

[Andreas Cadhalpun]

On 09.12.2016 10:26, wm4 wrote:
> 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.

You could skip that commit and mention it in the TODO/FIXME/UNMERGED
section of doc/libav-merge.txt.

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

Prediction is very difficult, especially about the future.

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

According to our code of conduct this should not be part of FFmpeg's
developer culture.

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

I wouldn't be so sure about that, as these warnings aren't particularly
urgent and other parts of the code base produce similar warnings.

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

If these symbols get removed from libavformat/libavformat.v and are thus
not exported in the shared library anymore, ffserver can't use them
(except when linked statically).

> or if there are other hidden internal or deprecated API uses, but yeah.

Since there is now ffservertest it should be easy to check if something
important breaks when the major bump happens.

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

That's not an accurate description of my position[1] on this.

> you could just spend time on fixing it instead.

That's exactly what I did. [2][3][4]

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

It mainly works by sending patches to the mailing list, where they are
discussed based on technical arguments.

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203575.html
2: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203672.html
3: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203670.html
4: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203671.html