[FFmpeg-devel] [GSoC] FFserver further development direction

Nicolas George george at nsup.org
Thu Apr 26 13:47:58 EEST 2018


Josh de Kock (2018-04-26):
>	   It's also not impossible, nor irrational to be removing code which
> doesn't fit or could be written better if an alternative is provided, the
> need was never there or removal can otherwise be justified.

Then justify. But you will need to address all the arguments that were
given three years ago.

The policy of this project has always been that for its core features it
must not depend on external libraries, apart from system libraries. What
exactly constitutes a "system library" is up for discussion, but in this
particular case there is no doubt.

What constitutes a "core feature" is also up for debate, but ffserver
have been part of the project for much more time than not, have many
users that are upset by its removal, and was only removed because the
code was an obsolete mess and nobody had the courage to rework it. It
seems unambiguous to me that ffserver IS a core feature of the project.

I will add two considerations:

First, the actual objections to having an HTTP server in the project are
about the maintenance burden, are they not? In that case, it seems to me
that the most weight in the decision should be given to people who have
an accurate idea of what it involves. So I ask: Do you consider yourself
skilled in network programming? Are you familiar with the RFCs
describing the HTTP protocol? Have you in the past implemented HTTP
servers?

Second, the habit of endlessly going back on past decisions is really
hurting the project. I know I have several ambitious goals for FFmpeg,
including a fully-typed option system with minimum string escaping. But
under the current conditions, there is no way I would ever start working
on them: we could decide today that the goal is worthy, but by the time
the first batch of development is done, some people will start
bieshedding it to death, and if it ever gets applied they will start
yapping "revert, revert" each time it causes a tiny bug.

Speaking for myself, I can say this: I will not perform anything more
than basic maintenance on code under my responsibility as long as this
project has this "one step forward, two steps on the side, one step
backward" mentality; that would be a waste of my time. So if you think
that my past work (especially the rework of the lavfi scheduling) had
merit, you should help finding a solution.

Electing a leader that can make final decisions and give the project
direction (no steps backward) would be one.

I will finish by saying the same thing in a shorter way:

Shut up, work and let people work.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180426/94180c68/attachment.sig>


More information about the ffmpeg-devel mailing list