Andreas Rheinhardt (12021-08-17): > Well, this has the problem that it adds code in many places, whereas > static flags for the filter just need code in two places (with zero > marginal cost for making another filter use this feature, whereas a flag > to ff_append_... has a nonzero cost even to users not making use of this > feature). I also like that it uses a static flag for what is essentially > a static property.
I do not understand your reasoning. If you have one case that is the majority by a wide margin, then it makes sense to make it the default and require the other case to be explicit. But that is not what is happening here. A quick count indicate that among filters adding pads dynamically, there are two using allocated names for one using static names. Two-to-one is not a huge majority, it is one of the cases where it makes more sense to write it explicitly on both cases. Furthermore, it is two-to-one for dynamically allocated, which means the default should be to free(), and the flags should be FF_FILTER_FLAG_DO_NOT_FREE_(IN|OUT)PADS, which would make the logic quite ugly. And honestly, we are talking adding ", 1" or ", 0" to each ff_insert_(in|out)pad() call. Just the name of the flag requires eight times as much characters in the source code. Regards, -- Nicolas George
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".
