[FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()

[Nicolas George]

Le quintidi 5 messidor, an CCXXIII, Derek Buitenhuis a écrit :
> The 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150623/2c691682/attachment.asc>