On 10/22/17, Michael Niedermayer <mich...@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! _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel