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