Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol <onemda@gmail.com>]

> NG reply:
> > 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.

Text, the ASCII used by CLI ffmpeg as interface for humanoids is irrelevant
here.

Modern humanoids use GUI interfaces and there text interface is reserved
only for actual text - STRING AVOptions and some aliases for other
AVOptions types.
From the programming perspective text aka "  char * " manipulations should
be reserved for actual text only, not for colors,integers,floats,flags...
etc.

Your last point is relevant for direct CLI ffmpeg usage mostly, ffmpeg and
its libraries in modern days are also used via automated process.
So writing some another iteration of generic text manipulations is waste of
time and resources, the current CLI text manipulations can stay and are
enough good in current state.
I'm not interested in text transcoding from/to as that is already done fine
in current libraries.

When you have GUI application which allows users to change filter
parameters via various widgets, there are no string anywhere unless one
needs to type actual strings.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".