Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
Il mar 23 apr 2024, 13:18 Michael Niedermayer 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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 > > 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
On Tue, Apr 23, 2024 at 10:28:38AM -0700, Vittorio Giovara wrote: > On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers > 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
On Tue, Apr 23, 2024 at 4:55 AM Andrew Sayers 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
> 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
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-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] lavu/opt: Clarify that AVOptions is not indended for general use
--- 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-requ...@ffmpeg.org with subject "unsubscribe".
