Il mar 23 apr 2024, 13:18 Michael Niedermayer <mich...@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-requ...@ffmpeg.org with subject "unsubscribe".
