On 10/22/2017 7:15 AM, Paul B Mahol wrote: > 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!
Paul, please keep your "funny" remarks on IRC. Develop a sense of time and place for jokes and sarcasm already. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel