Post by Derek BuitenhuisThe crux of the issue here is that there is disagreement on whether some features
should be in libav* at all. It's separation of functionality. It's not really
possible to show something satisfactory when it's the wrong place for it in
the first place, in someone's mind. I speak for myself here, only, of course.
Take it with a grain of salt.
As someone who pushed for a project that had similar opposition (the HTTP
server), I believe I must intervene.
First, let us try to agree on a few basic points.
Statement: you only get to decide on what you spent your own time. Other
developers decide for themselves. You can try to persuade them that
optimizing a codec is more important than writing a spell checker, but in
the end, if they want to write a spell checker, they will write a spell
checker, for FFmpeg or for another project.
Agreed?
Second, and this is rather a big point, so it will be itemized; please read
to the end before replying:
What actual harm does it do if someone works on something that you believe
is outside the scope of the project? I understand that you do not want to
endorse committing "lavu: add a spell checker", and even less spend time on
it, but why actually oppose it?
I can see a few reasons, let us discuss them.
1. It looks silly. Yes it does. And for that reason, nobody will actually
support adding a spell checker to lavu. But that does not apply to
exposing extra features of protocols that are already implemented.
2. It is a waste of valuable developer time. See my first statement: you
do not get to decide that, each person decide for themselves. If
someone decides to implement it now, if someone else decides to
maintain it later, that is their decision, they do so because they find
value in it. And if nobody does, you can let it bitrot and have the
pleasure of removing it when it has become obvious it was useless.
3. It pollutes the code. That, I can agree with, but that can be
mitigated: separate source files, optional compilation, well-defined
entry points. You can insist on such things.
Note that the notion of maintainership applies: AFAIK, you never wrote
a line about the libssh client, so your say in what happens in it is
limited. Limited, I would say, to the parts of the code that can be
reached by your use cases.
In other words: if it does not affect the code you actively work on and
if it does not change the run path of the features you really use, let
it be.
4. It wastes compilation time. That, I could agree too, having worked on
under-powered boxes. But let us be realistic: all these features we are
talking about are tiny. All together, they take less time building than
the file for the optimized DSP code of a single major codec.
5. It wastes limited resources, in particular funding and sponsorship.
Does it? Did we have a promising candidate that did not get a slot
because of one of these project? As far as I can see, the limiting
factor until now was the number of motivated candidates.
6. Anything else?
There is another point I wish to make before ending this too long mail: I
believe we can agree on a few very generic guidelines about what should be
accepted in the project. In other words, I wish to explain why I support the
directory listing API and the HTTP server but I would oppose
libavspellcheck.
I believe any of at least three conditions can make a new feature
acceptable:
1. A feature that is similar, in essence, to an already widely accepted
feature. New codecs are ok, because FFmpeg already has a lot of codecs.
We already have a X11 screen capture device, that means a windows
screen capture device or a Wayland capture device would have its place.
2. If we already have code that we need, then exposing the feature as a
clean API makes sense. With a caveat: exposing a public API freezes it,
so the evolution must be considered carefully.
An example: we need FFTs for the codecs. Then exposing a public AVFFT
interface makes sense.
Another example: hashes, we need them for some the checksums in some
formats, they have a rather natural an well-delimited interface, it
would be absurd not to expose them.
Well, we already have a HTTP server! It is hidden in ffserver and
duplicates some of the HTTP client code. If Stephan can merge the code
and give it a good overhaul, how is that bad?
Same goes for the output devices in lavd: ffplay needs a window to
display the video, other apps would benefit from it too. It does not
look very good currently because the work is only less than halfway
done: the devices are added, but they are not used in ffplay because
the API has some missing features. But theoretically it would look
really good.
3. If it makes existing feature cleaner and more orthogonal, then it
deserves to be considered.
For example, we already have a libsmb client (I know you objected to
it, but I was not convinced by your objections, and it brings us back
to my previous point: what harm does it do?), we also have a globbing
feature to turn a list of images into a video. But we can not use
globbing with files accessed through libsmb. How silly is that? The
directory listing API fixes that.
You complain about creeping featurism in FFmpeg, but the creeping
featurism is not in FFmpeg, it is in the multimedia world. The multimedia
world is incredibly complex because it is used by end-users that enjoy
fancy features.
I, personally, am perfectly happy of having my video collection identified
by directory and path name and run MPlayer on them by command lines. Most
end-users are not satisfied by that, they want fancy features, browsing
with preview, seamless migrating from their phone to their tablet to their
home cinema, etc. To support all these needs, eventually a multimedia
framework must encompass a whole lot of things.
Even a spell checker.
Yes, even a spell checker, and I prove it. There are bitmap subtitles
formats; there are also text subtitles formats. Bitmap subtitles are
easier to use together with video, but text subtitles formats are more
convenient to edit. Therefore, we need something to convert between text
and bitmap subtitles. For the text to bitmap direction, we need a font
rasterizer; FFmpeg can already use Freetype. For the other direction, we
need an OCR, and an OCR needs a spell checker to polish the result.
Yes, libavspellcheck! I used it as an absurd example, but if you think
carefully on it, it is not actually absurd.
Well, now it has really been too long, but I hope I did manage to sway you a
bit.
Regards,
--
Nicolas George