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

James Almer jamrial at gmail.com
Mon Nov 28 02:06:54 EET 2016


On 11/27/2016 8:53 PM, Andreas Cadhalpun wrote:
> On 28.11.2016 00:37, James Almer wrote:
>> On 11/27/2016 8:23 PM, Andreas Cadhalpun wrote:
>>> This can't happen while ffserver still uses internal API, and when it doesn't
>>> making it standalone isn't really useful, in particular because a standalone
>>> version can't be tested with FATE.
>>
>> We don't care about testing it with FATE.
> 
> Who is "we"?

The majority of developers that waited years for someone to try and make this
thing usable and got tired of doing it.

> 
> On 27.11.2016 19:30, Clément Bœsch wrote:
>> unless the fundamental problems are addressed (ZERO internal API usage +
>> at least partial FATE coverage)

Re-read his email. That paragraph is about work aimed at fixing ffserver if
it were to remain in the tree. Which it wont.

> 
> Apparently Clément cares about FATE coverage and so do I.
> 
>> It appears to me that you still don't get that ffserver is being *dropped*.
>> It is, as discussed and announced, no longer part of the project.
> 
> The main reason for deciding to drop ffserver was that it uses internal APIs
> and thus blocks the library development. Should that get fixed, the decision
> needs to be re-evaluated.

No. It will not be reviewed just because one or two people came out of the
woodworks years after requests for help and maintainers flew by unheard and
right when the final decision to drop the whole thing was made.

If you were interested, you had *years* to make that known. That time is now
past.

> 
>>> Why do you think removing it has any benefit, if it doesn't come together
>>> with the library cleanup?
>>
>> The "benefit" would be finally following through with a project decision for
>> once, even if late, but at least not embarrassingly late.
> 
> Do I understand you correctly that there is no technical benefit?

It goes the other way around. There are no technical reasons that block the
removal something that has been decided must go. Or rather, must have been
gone weeks ago.

> The project decision can be followed by removing ffserver at the next major
> bump, if it still uses any of the internal APIs that will be made private then.

No "if".



More information about the ffmpeg-devel mailing list