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