[FFmpeg-devel] [PATCH] lavu/opt: Clarify that AVOptions is not indended for general use

[FFmpeg-devel] [PATCH] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

---
 libavutil/opt.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index e6013662f6..795accb363 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -54,7 +54,11 @@
  * semantics of those fields without breaking API compatibility.
  *
  * @section avoptions_implement Implementing AVOptions
+ *
  * This section describes how to add AVOptions capabilities to a struct.
+ * It is intended for developers of FFmpeg itself - AVOptions can technically
+ * be used as a more general toolkit, but is neither intended nor expected
+ * to be good fit for other use cases.
  *
  * All AVOptions-related information is stored in an AVClass. Therefore
  * the first member of the struct should be a pointer to an AVClass describing it.
-- 
2.43.0

_______________________________________________
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] [PATCH] lavu/opt: Clarify that AVOptions is not indended for general use

[Stefano Sabatini]

On date Monday 2024-04-22 09:49:45 +0100, Andrew Sayers wrote:
> ---
>  libavutil/opt.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index e6013662f6..795accb363 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -54,7 +54,11 @@
>   * semantics of those fields without breaking API compatibility.
>   *
>   * @section avoptions_implement Implementing AVOptions
> + *
>   * This section describes how to add AVOptions capabilities to a struct.

> + * It is intended for developers of FFmpeg itself - AVOptions can technically
> + * be used as a more general toolkit, but is neither intended nor expected
> + * to be good fit for other use cases.
>   *

Nit: I'd make this statement somehow milder:

Use of AVOptions is intended for development of FFmpeg itself, but use
outside of FFmpeg is also possible.

the rationale being that it is very difficult to know in advance the
use case - in case the FFmpeg are the ones and only employed libraries
(as in the case of the FFmpeg tools themselves) this might even be a
good choice if you want to keep a small dependencies footprint and you
don't plan to switch to a different multimedia library.

Also:
developers => development
since an FFmpeg developer might work on other libraries as well, so
"FFmpeg development" defines the scope more exactly.
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

---
 libavutil/opt.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index e6013662f6..4c0e7d9223 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -54,7 +54,10 @@
  * semantics of those fields without breaking API compatibility.
  *
  * @section avoptions_implement Implementing AVOptions
+ *
  * This section describes how to add AVOptions capabilities to a struct.
+ * It is aimed at people adding new interfaces to internal FFmpeg functionality,
+ * but may also be of interest to programs that depend on FFmpeg.
  *
  * All AVOptions-related information is stored in an AVClass. Therefore
  * the first member of the struct should be a pointer to an AVClass describing it.
-- 
2.43.0

_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Stefano Sabatini]

On date Monday 2024-04-22 13:09:25 +0100, Andrew Sayers wrote:
> ---
>  libavutil/opt.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index e6013662f6..4c0e7d9223 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -54,7 +54,10 @@
>   * semantics of those fields without breaking API compatibility.
>   *
>   * @section avoptions_implement Implementing AVOptions
> + *
>   * This section describes how to add AVOptions capabilities to a struct.
> + * It is aimed at people adding new interfaces to internal FFmpeg functionality,
> + * but may also be of interest to programs that depend on FFmpeg.
>   *
>   * All AVOptions-related information is stored in an AVClass. Therefore
>   * the first member of the struct should be a pointer to an AVClass describing it.
> -- 
> 2.43.0

Looks good, thanks.

Let's wait one day in case there are comments from other people.

Note: I'll be offline for one week or so starting from tomorrow,
someone else might need to push this - or I'll do it when I'll be
back.
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Anton Khirnov]

> lavu/opt: Clarify that AVOptions is not indended for general use

They _are_ intended for general use though.

-- 
Anton Khirnov
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > lavu/opt: Clarify that AVOptions is not indended for general use
> 
> They _are_ intended for general use though.

In that case I'm confused...

Let's say I make a desktop app to transcode videos.  Obviously I would use
AVOptions to display configuration options for different encoders.  And it's
possible to create AVOptions objects for my UI.  But how strongly is that use
case recommended?

To provide a particularly difficult example - let's say I want to let the user
choose between interface themes, and I want to show both some text and a
picture of the theme.  AVOption doesn't include a "text + picture" option,
so how would I extend it to meet my needs?
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Anton Khirnov]

Quoting Andrew Sayers (2024-04-23 11:51:00)
> On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > lavu/opt: Clarify that AVOptions is not indended for general use
> > 
> > They _are_ intended for general use though.
> 
> In that case I'm confused...
> 
> Let's say I make a desktop app to transcode videos.  Obviously I would use
> AVOptions to display configuration options for different encoders.  And it's
> possible to create AVOptions objects for my UI.  But how strongly is that use
> case recommended?
> 
> To provide a particularly difficult example - let's say I want to let the user
> choose between interface themes, and I want to show both some text and a
> picture of the theme.  AVOption doesn't include a "text + picture" option,
> so how would I extend it to meet my needs?

If they fit your use case, then use them, otherwise don't - that's true
for pretty much all APIs we provide.

-- 
Anton Khirnov
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> Quoting Andrew Sayers (2024-04-23 11:51:00)
> > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > 
> > > They _are_ intended for general use though.
> > 
> > In that case I'm confused...
> > 
> > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > AVOptions to display configuration options for different encoders.  And it's
> > possible to create AVOptions objects for my UI.  But how strongly is that use
> > case recommended?
> > 
> > To provide a particularly difficult example - let's say I want to let the user
> > choose between interface themes, and I want to show both some text and a
> > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > so how would I extend it to meet my needs?
> 
> If they fit your use case, then use them, otherwise don't - that's true
> for pretty much all APIs we provide.

Ah ok, so how about if I changed "intended" to "optimized" in the subject?
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

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

On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > 
> > > > They _are_ intended for general use though.
> > > 
> > > In that case I'm confused...
> > > 
> > > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > > AVOptions to display configuration options for different encoders.  And it's
> > > possible to create AVOptions objects for my UI.  But how strongly is that use
> > > case recommended?
> > > 
> > > To provide a particularly difficult example - let's say I want to let the user
> > > choose between interface themes, and I want to show both some text and a
> > > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > > so how would I extend it to meet my needs?
> > 
> > If they fit your use case, then use them, otherwise don't - that's true
> > for pretty much all APIs we provide.
> 
> Ah ok, so how about if I changed "intended" to "optimized" in the subject?

If FFmpeg which is a multimedia tool in no place needs or wants to store
pictures through its option API in a way not curently supported.
I would say thats not going to qualify as "general use" outside specialized
software thats already dealing with a lot of pictures

still you certainly can handle binary data (like a bitmap picture) through
AVOption

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 

[-- 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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

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

On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > 
> > > > > They _are_ intended for general use though.
> > > > 
> > > > In that case I'm confused...
> > > > 
> > > > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > > > AVOptions to display configuration options for different encoders.  And it's
> > > > possible to create AVOptions objects for my UI.  But how strongly is that use
> > > > case recommended?
> > > > 
> > > > To provide a particularly difficult example - let's say I want to let the user
> > > > choose between interface themes, and I want to show both some text and a
> > > > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > > > so how would I extend it to meet my needs?
> > > 
> > > If they fit your use case, then use them, otherwise don't - that's true
> > > for pretty much all APIs we provide.
> > 
> > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> 
> If FFmpeg which is a multimedia tool in no place needs or wants to store
> pictures through its option API in a way not curently supported.
> I would say thats not going to qualify as "general use" outside specialized
> software thats already dealing with a lot of pictures
> 
> still you certainly can handle binary data (like a bitmap picture) through
> AVOption

And if you disagree, which you probably do :)
send a patch to improve AVOption to cover more general use

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

[-- 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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 01:18:28PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > > 
> > > > > > They _are_ intended for general use though.
> > > > > 
> > > > > In that case I'm confused...
> > > > > 
> > > > > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > > > > AVOptions to display configuration options for different encoders.  And it's
> > > > > possible to create AVOptions objects for my UI.  But how strongly is that use
> > > > > case recommended?
> > > > > 
> > > > > To provide a particularly difficult example - let's say I want to let the user
> > > > > choose between interface themes, and I want to show both some text and a
> > > > > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > > > > so how would I extend it to meet my needs?
> > > > 
> > > > If they fit your use case, then use them, otherwise don't - that's true
> > > > for pretty much all APIs we provide.
> > > 
> > > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> > 
> > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > pictures through its option API in a way not curently supported.
> > I would say thats not going to qualify as "general use" outside specialized
> > software thats already dealing with a lot of pictures
> > 
> > still you certainly can handle binary data (like a bitmap picture) through
> > AVOption
> 
> And if you disagree, which you probably do :)
> send a patch to improve AVOption to cover more general use

Not sure if that's aimed at the real me, or the hypothetical me that wants to
make a desktop app.  The hypothetical me wants not to throw away a week's work
because he did everything through AVOptions then came across some edge case
that doesn't fit into the AVOptions model.  The real me doesn't want to throw
away a week's work because I avoided AVOptions then found some bit of interface
that needs me to express my program in an AVOptions-compatible way.  Neither of
us mind what the answer is, so long as it's written down somewhere we would
spot during the design stage.

It sounds like the consensus is that people are *allowed* to implement their
own AVOption interfaces if they want to, but that there's no expectation for
them to do so unless they're working on FFmpeg itself.  That suggests the body
of the patch is fine, but the subject needs improvement?

How about 'Clarify that "Implementing AVOptions" is addressed to people working
on FFmpeg itself'?
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

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

On Tue, Apr 23, 2024 at 12:54:53PM +0100, Andrew Sayers wrote:
> On Tue, Apr 23, 2024 at 01:18:28PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> > > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > > > 
> > > > > > > They _are_ intended for general use though.
> > > > > > 
> > > > > > In that case I'm confused...
> > > > > > 
> > > > > > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > > > > > AVOptions to display configuration options for different encoders.  And it's
> > > > > > possible to create AVOptions objects for my UI.  But how strongly is that use
> > > > > > case recommended?
> > > > > > 
> > > > > > To provide a particularly difficult example - let's say I want to let the user
> > > > > > choose between interface themes, and I want to show both some text and a
> > > > > > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > > > > > so how would I extend it to meet my needs?
> > > > > 
> > > > > If they fit your use case, then use them, otherwise don't - that's true
> > > > > for pretty much all APIs we provide.
> > > > 
> > > > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> > > 
> > > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > > pictures through its option API in a way not curently supported.
> > > I would say thats not going to qualify as "general use" outside specialized
> > > software thats already dealing with a lot of pictures
> > > 
> > > still you certainly can handle binary data (like a bitmap picture) through
> > > AVOption
> > 
> > And if you disagree, which you probably do :)
> > send a patch to improve AVOption to cover more general use
> 
> Not sure if that's aimed at the real me, or the hypothetical me that wants to
> make a desktop app.  The hypothetical me wants not to throw away a week's work
> because he did everything through AVOptions then came across some edge case
> that doesn't fit into the AVOptions model.  The real me doesn't want to throw
> away a week's work because I avoided AVOptions then found some bit of interface
> that needs me to express my program in an AVOptions-compatible way.  Neither of
> us mind what the answer is, so long as it's written down somewhere we would
> spot during the design stage.
> 
> It sounds like the consensus is that people are *allowed* to implement their
> own AVOption interfaces if they want to, but that there's no expectation for
> them to do so unless they're working on FFmpeg itself.  That suggests the body
> of the patch is fine, but the subject needs improvement?
> 
> How about 'Clarify that "Implementing AVOptions" is addressed to people working
> on FFmpeg itself'?

I think the way i would put it is:
AVOption is intended for general use.
If you have a use case that it cannot be used for, a clean patch to improve it is welcome.

What i do not like is, taking a limitation (noone seems to have hit before)
and documenting it as if it was intended.

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin

[-- 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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Vittorio Giovara]

On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers <ffmpeg-devel@pileofstuff.org>
wrote:

> The hypothetical me wants not to throw away a week's work
> because he did everything through AVOptions then came across some edge case
> that doesn't fit into the AVOptions model.


Out of curiosity, what are those edge cases?
-- 
Vittorio
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 10:28:38AM -0700, Vittorio Giovara wrote:
> On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers <ffmpeg-devel@pileofstuff.org>
> wrote:
> 
> > The hypothetical me wants not to throw away a week's work
> > because he did everything through AVOptions then came across some edge case
> > that doesn't fit into the AVOptions model.
> 
> 
> Out of curiosity, what are those edge cases?

It's really more a question of how to recover from the thing you didn't think
of, which makes it hard to think of good examples ;)

But since you ask, it might be worth looking at SANE option descriptors[0].
They perform a very similar function to AVOptions (providing a flexible
configuration API for a C codebase), and have a 90% overlap in features.  But
for example, SANE doesn't have an equivalent of AVRational, while AVOptions
doesn't have an equivalent of option groups.  More importantly, some things are
technically compatible but perform unobviously different jobs, like how SANE's
"description" text seems to do the same as FFmpeg's "help" text, but if memory
serves descriptions are usually several paragraphs while help is usually a
sentence or two.  It would waste a lot of time if I coded up a whole program
only to discover the SANE config screen had nicely-grouped options with
novel-length tooltips, while the FFmpeg config screen had a flat list of
well-described options that would have looked good if I'd picked an interface
with a search bar.

In a situation like that, it would be very helpful to know that FFmpeg's
position is "have a go and send us a patch if it works" rather than e.g. "we
never got round to making that private" or "we're in the middle of spinning
that off as a standalone library".  I'll have a think overnight and submit an
updated patch tomorrow based on everyone's feedback (thanks!).

[0] http://www.sane-project.org/html/doc011.html#s4.2.9
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Andrew Sayers]

On Tue, Apr 23, 2024 at 07:52:49PM +0100, Andrew Sayers wrote:
> On Tue, Apr 23, 2024 at 10:28:38AM -0700, Vittorio Giovara wrote:
> > On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers <ffmpeg-devel@pileofstuff.org>
> > wrote:
> > 
> > > The hypothetical me wants not to throw away a week's work
> > > because he did everything through AVOptions then came across some edge case
> > > that doesn't fit into the AVOptions model.
> > 
> > 
> > Out of curiosity, what are those edge cases?
> 
> It's really more a question of how to recover from the thing you didn't think
> of, which makes it hard to think of good examples ;)
> 
> But since you ask, it might be worth looking at SANE option descriptors[0].
> They perform a very similar function to AVOptions (providing a flexible
> configuration API for a C codebase), and have a 90% overlap in features.  But
> for example, SANE doesn't have an equivalent of AVRational, while AVOptions
> doesn't have an equivalent of option groups.  More importantly, some things are
> technically compatible but perform unobviously different jobs, like how SANE's
> "description" text seems to do the same as FFmpeg's "help" text, but if memory
> serves descriptions are usually several paragraphs while help is usually a
> sentence or two.  It would waste a lot of time if I coded up a whole program
> only to discover the SANE config screen had nicely-grouped options with
> novel-length tooltips, while the FFmpeg config screen had a flat list of
> well-described options that would have looked good if I'd picked an interface
> with a search bar.
> 
> In a situation like that, it would be very helpful to know that FFmpeg's
> position is "have a go and send us a patch if it works" rather than e.g. "we
> never got round to making that private" or "we're in the middle of spinning
> that off as a standalone library".  I'll have a think overnight and submit an
> updated patch tomorrow based on everyone's feedback (thanks!).
> 
> [0] http://www.sane-project.org/html/doc011.html#s4.2.9

At the risk of further complicating a conversation that's already drifting
off-topic, a better example might be Video4Linux2 configuration.  Not only does
it have data types unsupported by AVOptions (like "menu"), but also does things
like making some options constant depending on the value of others (e.g. you
can't change the frame rate if you've selected "automatic frame rate").  A
quick look at v4l2_m2m_enc.c suggests that FFmpeg has decided to just put up
with limited configurability, rather than do something crazy like dynamically
allocate new AVClasses at runtime.  That's a limitation I'd need to know about
if I made a chat app, but also a guarantee that helps me understand how
AVOptions works.

Looping back to a point from before, I can work with either answer, the value
is simply in *having* an answer.
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[James Almer]

On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
>> On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
>>> Quoting Andrew Sayers (2024-04-23 11:51:00)
>>>> On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
>>>>>> lavu/opt: Clarify that AVOptions is not indended for general use
>>>>>
>>>>> They _are_ intended for general use though.
>>>>
>>>> In that case I'm confused...
>>>>
>>>> Let's say I make a desktop app to transcode videos.  Obviously I would use
>>>> AVOptions to display configuration options for different encoders.  And it's
>>>> possible to create AVOptions objects for my UI.  But how strongly is that use
>>>> case recommended?
>>>>
>>>> To provide a particularly difficult example - let's say I want to let the user
>>>> choose between interface themes, and I want to show both some text and a
>>>> picture of the theme.  AVOption doesn't include a "text + picture" option,
>>>> so how would I extend it to meet my needs?
>>>
>>> If they fit your use case, then use them, otherwise don't - that's true
>>> for pretty much all APIs we provide.
>>
>> Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> 
> If FFmpeg which is a multimedia tool in no place needs or wants to store
> pictures through its option API in a way not curently supported.
> I would say thats not going to qualify as "general use" outside specialized
> software thats already dealing with a lot of pictures
> 
> still you certainly can handle binary data (like a bitmap picture) through
> AVOption
> 
> thx

Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which 
is currently the only field not covered by an AVOption (And thus not 
currently configurable from the CLI). How could it be supported? Binary 
type doesn't work because it expects a pointer + size field and 
allocates the former.
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Stefano Sabatini]

Il mar 23 apr 2024, 13:18 Michael Niedermayer <michael@niedermayer.cc> ha
scritto:

> On Tue, Apr 23, 2024 at 01:15:52PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > lavu/opt: Clarify that AVOptions is not indended for general
> use
> > > > > >
> > > > > > They _are_ intended for general use though.
> > > > >
> > > > > In that case I'm confused...
> > > > >
> [...]
> > still you certainly can handle binary data (like a bitmap picture)
> through
> > AVOption
>
> And if you disagree, which you probably do :)
> send a patch to improve AVOption to cover more general use
>

I think the real point is not that AVOptions/AVClass cannot be used in a
generic application, but that using them is not the point of employing
libav* libraries. In fact, if only part of your application is about
multimedia, probably you will be using the encoding or muxing or filtering
API but it's unlikely you will use AVOptions for generic non-multimedia
code, and you will be already using some other generic toolkit for handling
struct properties. This entails that practically AVOptions/AVClass is
mostly used to develop FFmpeg internals.

So even if the AVOptions API is generic, its use is not really the selling
point of the FFmpeg libraries, and therefore the user is not really
*expected* to use directly them to extend his generic structs, even if that
might be possible.

>
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

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

On Tue, Apr 23, 2024 at 05:24:03PM -0300, James Almer wrote:
> On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > > 
> > > > > > They _are_ intended for general use though.
> > > > > 
> > > > > In that case I'm confused...
> > > > > 
> > > > > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > > > > AVOptions to display configuration options for different encoders.  And it's
> > > > > possible to create AVOptions objects for my UI.  But how strongly is that use
> > > > > case recommended?
> > > > > 
> > > > > To provide a particularly difficult example - let's say I want to let the user
> > > > > choose between interface themes, and I want to show both some text and a
> > > > > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > > > > so how would I extend it to meet my needs?
> > > > 
> > > > If they fit your use case, then use them, otherwise don't - that's true
> > > > for pretty much all APIs we provide.
> > > 
> > > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> > 
> > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > pictures through its option API in a way not curently supported.
> > I would say thats not going to qualify as "general use" outside specialized
> > software thats already dealing with a lot of pictures
> > 
> > still you certainly can handle binary data (like a bitmap picture) through
> > AVOption
> > 
> > thx
> 
> Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which is
> currently the only field not covered by an AVOption (And thus not currently
> configurable from the CLI). How could it be supported? Binary type doesn't
> work because it expects a pointer + size field and allocates the former.

i would guess some form of AV_OPT_TYPE_FLAG_ARRAY

we have similar arrays like intra_matrix in mpeg codecs

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable

[-- 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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[James Almer]

On 4/23/2024 5:53 PM, Michael Niedermayer wrote:
> On Tue, Apr 23, 2024 at 05:24:03PM -0300, James Almer wrote:
>> On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
>>> On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
>>>> On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
>>>>> Quoting Andrew Sayers (2024-04-23 11:51:00)
>>>>>> On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
>>>>>>>> lavu/opt: Clarify that AVOptions is not indended for general use
>>>>>>>
>>>>>>> They _are_ intended for general use though.
>>>>>>
>>>>>> In that case I'm confused...
>>>>>>
>>>>>> Let's say I make a desktop app to transcode videos.  Obviously I would use
>>>>>> AVOptions to display configuration options for different encoders.  And it's
>>>>>> possible to create AVOptions objects for my UI.  But how strongly is that use
>>>>>> case recommended?
>>>>>>
>>>>>> To provide a particularly difficult example - let's say I want to let the user
>>>>>> choose between interface themes, and I want to show both some text and a
>>>>>> picture of the theme.  AVOption doesn't include a "text + picture" option,
>>>>>> so how would I extend it to meet my needs?
>>>>>
>>>>> If they fit your use case, then use them, otherwise don't - that's true
>>>>> for pretty much all APIs we provide.
>>>>
>>>> Ah ok, so how about if I changed "intended" to "optimized" in the subject?
>>>
>>> If FFmpeg which is a multimedia tool in no place needs or wants to store
>>> pictures through its option API in a way not curently supported.
>>> I would say thats not going to qualify as "general use" outside specialized
>>> software thats already dealing with a lot of pictures
>>>
>>> still you certainly can handle binary data (like a bitmap picture) through
>>> AVOption
>>>
>>> thx
>>
>> Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which is
>> currently the only field not covered by an AVOption (And thus not currently
>> configurable from the CLI). How could it be supported? Binary type doesn't
>> work because it expects a pointer + size field and allocates the former.
> 
> i would guess some form of AV_OPT_TYPE_FLAG_ARRAY
> 
> we have similar arrays like intra_matrix in mpeg codecs

Same situation it seems, it expects a pointer + size field.
_______________________________________________
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] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use

[Michael Niedermayer]

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

On Tue, Apr 23, 2024 at 06:23:04PM -0300, James Almer wrote:
> On 4/23/2024 5:53 PM, Michael Niedermayer wrote:
> > On Tue, Apr 23, 2024 at 05:24:03PM -0300, James Almer wrote:
> > > On 4/23/2024 8:15 AM, Michael Niedermayer wrote:
> > > > On Tue, Apr 23, 2024 at 11:10:43AM +0100, Andrew Sayers wrote:
> > > > > On Tue, Apr 23, 2024 at 12:04:34PM +0200, Anton Khirnov wrote:
> > > > > > Quoting Andrew Sayers (2024-04-23 11:51:00)
> > > > > > > On Tue, Apr 23, 2024 at 11:21:27AM +0200, Anton Khirnov wrote:
> > > > > > > > > lavu/opt: Clarify that AVOptions is not indended for general use
> > > > > > > > 
> > > > > > > > They _are_ intended for general use though.
> > > > > > > 
> > > > > > > In that case I'm confused...
> > > > > > > 
> > > > > > > Let's say I make a desktop app to transcode videos.  Obviously I would use
> > > > > > > AVOptions to display configuration options for different encoders.  And it's
> > > > > > > possible to create AVOptions objects for my UI.  But how strongly is that use
> > > > > > > case recommended?
> > > > > > > 
> > > > > > > To provide a particularly difficult example - let's say I want to let the user
> > > > > > > choose between interface themes, and I want to show both some text and a
> > > > > > > picture of the theme.  AVOption doesn't include a "text + picture" option,
> > > > > > > so how would I extend it to meet my needs?
> > > > > > 
> > > > > > If they fit your use case, then use them, otherwise don't - that's true
> > > > > > for pretty much all APIs we provide.
> > > > > 
> > > > > Ah ok, so how about if I changed "intended" to "optimized" in the subject?
> > > > 
> > > > If FFmpeg which is a multimedia tool in no place needs or wants to store
> > > > pictures through its option API in a way not curently supported.
> > > > I would say thats not going to qualify as "general use" outside specialized
> > > > software thats already dealing with a lot of pictures
> > > > 
> > > > still you certainly can handle binary data (like a bitmap picture) through
> > > > AVOption
> > > > 
> > > > thx
> > > 
> > > Take for example AVIAMFReconGain.recon_gain in libavutil/iamf.h, which is
> > > currently the only field not covered by an AVOption (And thus not currently
> > > configurable from the CLI). How could it be supported? Binary type doesn't
> > > work because it expects a pointer + size field and allocates the former.
> > 
> > i would guess some form of AV_OPT_TYPE_FLAG_ARRAY
> > 
> > we have similar arrays like intra_matrix in mpeg codecs
> 
> Same situation it seems, it expects a pointer + size field.

So someone needs to add support for a fixed size or
dim size0,size1,sizeDIM

thx

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

It is what and why we do it that matters, not just one of them.

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

[FFmpeg-devel] [PATCH v3] lavu/opt: Clarify the scope of AVOptions

[Andrew Sayers]

See discussion on the mailing list:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/326054.html
---
 libavutil/opt.h | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index e6013662f6..6cf2b39a63 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -53,6 +53,16 @@
  * question is allowed to access the field. This allows us to extend the
  * semantics of those fields without breaking API compatibility.
  *
+ * @section avoptions_scope Scope of AVOptions
+ *
+ * AVOptions is designed to support any set of multimedia configuration options
+ * that can be defined at compile-time.  Although it is mainly used to expose
+ * FFmpeg options, you are welcome to adapt it to your own use case.
+ *
+ * No single approach can ever fully solve the problem of configuration,
+ * but please submit a patch if you believe you have found a problem
+ * that is best solved by extending AVOptions.
+ *
  * @section avoptions_implement Implementing AVOptions
  * This section describes how to add AVOptions capabilities to a struct.
  *
-- 
2.43.0

_______________________________________________
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] [PATCH v3] lavu/opt: Clarify the scope of AVOptions

[Michael Niedermayer]

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

On Wed, Apr 24, 2024 at 08:30:28AM +0100, Andrew Sayers wrote:
> See discussion on the mailing list:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/326054.html
> ---
>  libavutil/opt.h | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index e6013662f6..6cf2b39a63 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -53,6 +53,16 @@
>   * question is allowed to access the field. This allows us to extend the
>   * semantics of those fields without breaking API compatibility.
>   *
> + * @section avoptions_scope Scope of AVOptions
> + *
> + * AVOptions is designed to support any set of multimedia configuration options
> + * that can be defined at compile-time.  Although it is mainly used to expose
> + * FFmpeg options, you are welcome to adapt it to your own use case.
> + *
> + * No single approach can ever fully solve the problem of configuration,
> + * but please submit a patch if you believe you have found a problem
> + * that is best solved by extending AVOptions.
> + *
>   * @section avoptions_implement Implementing AVOptions
>   * This section describes how to add AVOptions capabilities to a struct.
>   *

will apply

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire

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