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

[wm4]

On Thu, 26 Apr 2018 12:47:58 +0200
Nicolas George <george at nsup.org> wrote:

> 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.

So the whole argument is: we need a HTTP server, because a "core
feature" (which is really a separate program that uses that libav*
libs) needs it? That's a pretty rigid rule.

There are other external libraries we're relying on for relatively
important functionality, and which can not really be called system libs:
we support 3 or 4 TLS wrapper libs for HTTPS, libass for subtitle
rendering, some libs for reading and rendering MIDI-like file formats,
libx264 for h264 encoding (the most commonly used codec!), SDL for
ffplay, and some other codec libs for which we have builtin
implementations, because the builtin ones were too bad (AAC encoding
used to be one). There's probably more.

> 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?

The HTTP _client_ in lavf is rather bad. I know because I get to use
it with a lot of websites. And it doesn't even support HTTP 2. Just
using libcurl or such would probably have saved us a lot of pain. API
users can't just use their own HTTP client btw., because other lavf
components depend on the native one too much.

I have no doubt the server code would end up with even poorer support.
The server code seems even barely used and was probably not
battle-tested with a large number of different clients.

Besides, it's a bad idea to extend the server APIs while the
libavformat I/O API is in its current state that is much in need for
cleanup, especially API-wise. Isn't the argument that we should not
add premature API up your alley?

In general badly NIH-ing something sufficiently complicated and that is
not quite in the central focus of the project will end up worse than
relying on completed external components that have spend a lot of time
to complete it, including fixing any bugs and issues.

> Second, the habit of endlessly going back on past decisions is really
> hurting the project. I know I have several ambitious goals for FFmpeg,

It was because the past decisions were not actually unanimous, so the
contra-forces, who didn't accept or even recognize the past decisions,
sometimes win back ground later. This happens because FFmpeg is a
project full of in-fighting.

> 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

Well I don't think you're entirely innocent in that.

> that my past work (especially the rework of the lavfi scheduling) had
> merit, you should help finding a solution.

That's some kind of passive aggressive threat. Please don't do this,
because things like that only make the project more... difficult.

> 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.

You never follow that though. You participate in endless flames, until
the other side is tired and gives up.

> Regards,
>