[FFmpeg-devel] [PATCH 0/6] Patchset to remove ffserver

[James Almer]

On 10/22/2017 7:15 AM, Paul B Mahol wrote:
> On 10/22/17, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> On Sun, Oct 22, 2017 at 10:37:28AM +0200, Clement Boesch wrote:
>>> On Sun, Oct 22, 2017 at 02:55:38AM +0200, Michael Niedermayer wrote:
>>>> On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
>>>>> On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
>>>>>> This patchset removes the long-deprecated ffserver program and all
>>>>>> its privately exposed things from libavformat.
>>>>>>
>>>>>> Rostislav Pehlivanov (6):
>>>>>>   Remove the ffserver program
>>>>>>   libavformat: remove the ffmenc and ffmdec muxer and demuxers
>>>>>>   libavformat: unexpose the ff_inet_aton function
>>>>>>   libavformat: remove the ff_rtp_get_local_rtcp_port function
>>>>>>   libavformat: unexpose private ff_ functions needed by ffserver
>>>>>>   libavformat/mpjpeg: use "ffmpeg" instead of "ffserver" as boundary
>>>>>> tag
>>>>>
>>>>> This set will be applied a month or so from now, when the unstable
>>>>> ABI
>>>>> period is over.
>>>>>
>>>>> If you can do in a month what was not done in a year plus, anyone is
>>>>> welcome to fix all ffserver issues or preferably replace it
>>>>> altogether
>>>>> with a new tool with a more user friendly syntax/interface.
>>>>
>>>> Can you list the technical problems that require dropping ffserver,
>>>> so that someone interrested in fixing them can do so ?
>>>
>>> It's probably too late, one month is not enough. We already had that
>>> discussion:
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203482.html
>>>
>>
>>> The goal was ZERO internal API usage + at least partial FATE coverage. We
>>> gave it a year and nothing changed because no one cared.
>>
>> For reference, the votes text was: (uncut)
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203561.html
>>     I propose, and put to the discussion, that the decision to drop
>> ffserver
>>     is revoked, conditioned to the fixing of the technical issues that lead
>>     to it.
>>
>>     In other words, if the technical problems that require dropping
>> ffserver
>>     are resolved at the time it is about to be dropped, then it must not be
>>     and the patch is not applied.
>>
>>     I support the decision. Pros:
>>
>>     ffserver has users, if there are no reason to drop it, doing so is a
>>     gratuitous annoyance to them.
>>
>>     Apparently James Almer opposes the decision. Cons, if I understand
>>     correctly:
>>
>>     A decision was made, a project should stick to it stubbornly.
> 
> You and Carl should step out as leaders, or we will FORK!

Paul, please keep your "funny" remarks on IRC. Develop a sense of time
and place for jokes and sarcasm already.