Quoting James Almer (2021-01-04 20:35:30) > On 1/4/2021 4:29 PM, Nicolas George wrote: > > Andreas Rheinhardt (12021-01-04): > >> What enumerating code? It is actually commonplace that options are > >> shared (you can find examples in libavfilter by using 'git grep -e > >> define --and -e options'); pointing into other options and thereby > >> reusing only a part of other options is not common, but I don't really > >> see why it shouldn't work. > > > > Using #define to de-duplicate the source is fine, of course. > > > > But IIRC pointing to the same array, i.e. de-duplicating in the binary, > > will lead to the code that enumerate options to loop in some way. I do > > not remember the details, and I cannot find a commit that talks about > > it, sorry. Maybe somebody here remembers better? > > > > Regards, > > I recall issues with modules sharing a common AVClass, but different > AVClasses sharing a common array of AVOptions seems to be ok. > See rawdec.h in libavformat, and how ff_raw_options is used in several > different demuxer AVClasses.
child_class_next() implementation for AVFormatContext and others assumes a one-to-one mapping between objects and their AVClasses. But that is now deprecated and there should be no issues when it's removed. -- 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".
