[FFmpeg-devel] Sorry state of AVOptions

[Nicolas George]

Paul B Mahol (12024-07-04):
> The AVOptions state is extremely ugly.
> 
> It is insane to request from library users to convert non-strings option
> values from/to strings to be able to read/change them, it is ugly,
> inefficient, and slow. This becomes more relevant for recent array options
> extension for which av_opt_ptr() hack does not work at all.

You are right, and it will not change soon.

AVOptions is both about communicating with applications through
type-safe APIs and about communicating with users through generic APIs.
That last point is done through text, the universal API of humans.

Thus, a good AVOption overhaul requires a good strings API.

Unfortunately, the people who do not understand the project but have
decided they can dictate its future, who have been breathing down your
neck and mine as if they were our managers and made working on FFmpeg
totally un-fun, have rejected the idea of a good strings API with
idiotic arguments such as “we do not need it”, “it does not belong in
FFmpeg”, “make it a separate library and maybe we will use it”.

We will not be having a better strings API, therefore we will not have a
better options system.

If we had not constant obstruction by people who are here for profit
more than for fun and only value the work of others only when they see
it benefiting themselves in the short term, this is what we could have
with options:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184525.html

Also blocked by the lack of a good strings API:

- exfiltration of structured data (statistics, detection…) from filters;

- rich built-in documentation;

- API for error reporting (≠ logging);

- list not exhaustive.

Regards,

-- 
  Nicolas George