| Message ID | 20240422120925.380253-1-ffmpeg-devel@pileofstuff.org |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,v2] lavu/opt: Clarify that AVOptions is not indended for general use | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
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.
> lavu/opt: Clarify that AVOptions is not indended for general use
They _are_ intended for general use though.
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?
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.
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?
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 [...]
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 [...]
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'?
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 [...]
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?
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
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.
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.
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. >
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 [...]
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.
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 [...]
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.