[FFmpeg-devel] Project orientation

[Nicolas George]

Jean-Baptiste Kempf (12020-07-05):
> Also in this example, noone is telling them to fork, just to use the
> API to register their custom protocol.

About this, I think there are two separate issues.

One is that recent effort to get rid of mutable global state.
Registering custom protocols involves modifying global state, and
therefore has been made impossible by efforts to be able to add "const"
whenever possible.

This issue is actually easy to solve. The patch about
avrefcount_template.h was actually the first step towards my solution to
it: to have potentially multiple mutable states, with protocols,
formats, codecs, filters lists. That way, we can bring back the dynamic
lists of components without the drawbacks we wanted to eliminate. And
there are a few extra benefits: no interference if different parts of a
huge application register different components; a more reliable way of
enabling only a few selected components (the systems of whitelist used
now is an afterthought, afterthoughts are terrible for security; and we
will have to rename them anyway).

It is a bit tricky, because it spans several libraries (this always
makes things harder), but I have solutions. If I can explain these
solutions to somebody in charge and have them pre-approved in general
principle, I can work on the code rather quickly. But if I code with the
risk of it getting bikeshedded to death immediately, it is debilitating.

So again: not a very hard issue, but requires something at the helm, to
decide the orientation of the project.

The other issue is much more burdensome.

If you remember, at the beginning of libavfilter, applications could
register custom filters. We ended up making it private to be able to
evolve it.

The problem is API stability. Changing an internal API is easy: just
change it, and fix all the build failure, or grep for all uses of the
function. Changing a public API is much more trouble.

Anton could probably never have achieved the change from AVBufferRef to
AVFrame in libavfilter if all the internal filtering APIs had been
public and required careful compatibility. Same for me reworking the
scheduling to make it by message instead of recursive.

There are partial solutions yet:

- The internal API have somewhat stabilized. Things that seemed a good
  idea at the time but were too complex have been eliminated. That will
  help.

- We can make the public API less powerful than the internal API. No
  direct rendering or other extra optimizations to avoid data copy. No
  fancy format negotiation. No access to ultra-optimized computation
  building blocks.

- We can make the public API less stable. I am serious, it is an
  entirely acceptable solution. These are just applications, not
  life-and-death situations, "do it at your own risk" is not worse than
  "don't do it". We can have headers that clearly indicate "if you use
  something from this header, we do not guarantee it will keep working,
  you will have to check if it still works after each update.

  And if people are not happy about lack of stability, they can come and
  help.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200707/d8580278/attachment.sig>