[FFmpeg-devel] Sorry state of AVOptions

[FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

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.

Get this fix ASAP!
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[James Almer]

On 7/4/2024 11:44 AM, Paul B Mahol wrote:
> 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,

av_opt_{get,set,eval}_{int,double,etc}?

> inefficient, and slow. This becomes more relevant for recent array options
> extension for which av_opt_ptr() hack does not work at all.
> 
> Get this fix ASAP!
> _______________________________________________
> 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".
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

On Thu, Jul 4, 2024 at 4:54 PM James Almer <jamrial@gmail.com> wrote:

> On 7/4/2024 11:44 AM, Paul B Mahol wrote:
> > 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,
>
> av_opt_{get,set,eval}_{int,double,etc}?
>

Does not work with arrays.


>
> > inefficient, and slow. This becomes more relevant for recent array
> options
> > extension for which av_opt_ptr() hack does not work at all.
> >
> > Get this fix ASAP!
> > _______________________________________________
> > 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".
> _______________________________________________
> 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".
>
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

> 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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Nicolas George]

Paul B Mahol (12024-07-04):
> Modern humanoids use GUI interfaces and there text interface is reserved
> only for actual text - STRING AVOptions and some aliases for other
> AVOptions types.

GUI can only exist for types that are known by the application or the
GUI toolkit it uses. If you are using a 2026 FFmpeg with an application
from 2024, all the types introduced in FFmpeg between 2024 and 2026 will
be and cannot have a specific GUI, unless they are trivial enumerations.

This is why you need powerful text manipulation even with GUIs.

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

On Thu, Jul 4, 2024 at 8:34 PM Nicolas George <george@nsup.org> wrote:

> Paul B Mahol (12024-07-04):
> > Modern humanoids use GUI interfaces and there text interface is reserved
> > only for actual text - STRING AVOptions and some aliases for other
> > AVOptions types.
>
> GUI can only exist for types that are known by the application or the
> GUI toolkit it uses. If you are using a 2026 FFmpeg with an application
> from 2024, all the types introduced in FFmpeg between 2024 and 2026 will
> be and cannot have a specific GUI, unless they are trivial enumerations.
>
> This is why you need powerful text manipulation even with GUIs.
>
>
Nobody sane uses text manipulation in GUIs.

You just 'invented' this nonsense now.


> --
>   Nicolas George
> _______________________________________________
> 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".
>
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Nicolas George]

Paul B Mahol (12024-07-04):
> Nobody sane uses text manipulation in GUIs.

Then how would you do it?

	} else if (opt->type == AV_OPT_TYPE_COLOR) {
		create_color_picker_widget(opt);
	} else if (opt->type == AV_OPT_TYPE_DATE) {
		create_calendar_widget(opt);
	} else {
		???
	}

What do you put in the else clause when you already handled all types
you know how to handle?

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

On Thu, Jul 4, 2024 at 9:33 PM Nicolas George <george@nsup.org> wrote:

> Paul B Mahol (12024-07-04):
> > Nobody sane uses text manipulation in GUIs.
>
> Then how would you do it?
>
>         } else if (opt->type == AV_OPT_TYPE_COLOR) {
>                 create_color_picker_widget(opt);
>         } else if (opt->type == AV_OPT_TYPE_DATE) {
>                 create_calendar_widget(opt);
>         } else {
>                 ???
>         }
>
> What do you put in the else clause when you already handled all types
> you know how to handle?
>

Application vendor will issue new free-update with handling for newly
introduced AVOption type.


>
> --
>   Nicolas George
> _______________________________________________
> 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".
>
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Nicolas George]

Paul B Mahol (12024-07-04):
> Application vendor will issue new free-update with handling for newly
> introduced AVOption type.

So you mean your users have tu update your application to have it handle
new types in more recent FFmpeg?

How do they do if you moved to another project and do not update?

What do they do if in the meantime you raised your prices?

My version is superior: I put the unknown options in a text entry
widget, as text, and they work immediately. If later I update the
application, they will work nice, but they already work now.

This is the kind of thing you have to think about when you design an
API.

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

On Thu, Jul 4, 2024 at 9:49 PM Nicolas George <george@nsup.org> wrote:

> Paul B Mahol (12024-07-04):
> > Application vendor will issue new free-update with handling for newly
> > introduced AVOption type.
>
> So you mean your users have tu update your application to have it handle
> new types in more recent FFmpeg?
>
> How do they do if you moved to another project and do not update?
>
> What do they do if in the meantime you raised your prices?
>
> My version is superior: I put the unknown options in a text entry
> widget, as text, and they work immediately. If later I update the
> application, they will work nice, but they already work now.
>

Superior only for you, no GUI users use text widgets for non-text.


> This is the kind of thing you have to think about when you design an
> API.
>
> --
>   Nicolas George
> _______________________________________________
> 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".
>
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Nicolas George]

Paul B Mahol (12024-07-04):
> Superior only for you, no GUI users use text widgets for non-text.

Users prefer an application that works now, even if its with a text
widget, to an application that does not work now and might work when
updated.

This is getting nowhere, so end of this for me.

-- 
  Nicolas George
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

On Thu, Jul 4, 2024 at 10:12 PM Nicolas George <george@nsup.org> wrote:

> Paul B Mahol (12024-07-04):
> > Superior only for you, no GUI users use text widgets for non-text.
>
> Users prefer an application that works now, even if its with a text
> widget, to an application that does not work now and might work when
> updated.
>
> This is getting nowhere, so end of this for me.
>

Yes, trolls always wins here.


>
> --
>   Nicolas George
> _______________________________________________
> 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".
>
_______________________________________________
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".

Re: [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
_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1174 bytes --]

On Thu, Jul 04, 2024 at 04:44:39PM +0200, Paul B Mahol wrote:
> 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.

maybe reverting this, will make array somewhat work with av_opt_ptr()

@@ -1794,7 +2016,9 @@ const AVClass *av_opt_child_class_iterate(const AVClass *parent, void **iter)
 void *av_opt_ptr(const AVClass *class, void *obj, const char *name)
 {
     const AVOption *opt= av_opt_find2(&class, name, NULL, 0, AV_OPT_SEARCH_FAKE_OBJ, NULL);
-    if(!opt)
+
+    // no direct access to array-type options
+    if (!opt || (opt->type & AV_OPT_TYPE_FLAG_ARRAY))
         return NULL;
     return (uint8_t*)obj + opt->offset;
 }

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] Sorry state of AVOptions

[Paul B Mahol]

On Fri, Jul 5, 2024 at 10:09 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Thu, Jul 04, 2024 at 04:44:39PM +0200, Paul B Mahol wrote:
> > 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.
>
> maybe reverting this, will make array somewhat work with av_opt_ptr()
>
> @@ -1794,7 +2016,9 @@ const AVClass *av_opt_child_class_iterate(const
> AVClass *parent, void **iter)
>  void *av_opt_ptr(const AVClass *class, void *obj, const char *name)
>  {
>      const AVOption *opt= av_opt_find2(&class, name, NULL, 0,
> AV_OPT_SEARCH_FAKE_OBJ, NULL);
> -    if(!opt)
> +
> +    // no direct access to array-type options
> +    if (!opt || (opt->type & AV_OPT_TYPE_FLAG_ARRAY))
>          return NULL;
>      return (uint8_t*)obj + opt->offset;
>  }
>
> thx
>

It is very bad and fragile API. It needs to go.


>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Complexity theory is the science of finding the exact solution to an
> approximation. Benchmarking OTOH is finding an approximation of the exact
> _______________________________________________
> 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".
>
_______________________________________________
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".