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

[Michael Niedermayer]

On Sun, Oct 22, 2017 at 12:15:25PM +0200, 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!

calm down please, the only thing ive said in the whole thread was
asking for a list of "technical problems that require dropping ffserver"
and for reference posting the uncut text from the last years vote.
Which used exactly that phrase.
Which was not written by either me nor carl.

I had not intended to offend anyone by posting this.

I will also post a patch that hopefully fixes partial fate tests for
ffserver as that was one of several things suggested.
Beyond that i have no plans ATM about ffserver.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171022/63f4ea7f/attachment.sig>