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

[Paul B Mahol]

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!