Michael Niedermayer (12020-07-14): > Let me phrase my suggestion in a more high level sense > > Currently the functions use int for lots of cases where they should not > ultimately we want the functions to use more correct types for linesize > sizes and so on. > > We need to add these function(s) because we fix a bug. > Can we take a step toward more correct types while doing this in a > way that makes sense ? > > if so that should be done. > > If not (as in its more mess than if its done later in some other way) > then we should not try to do this now > > The idea is just to take a step towards how these functions/API should look > ideally. Its not to make some inconvenient mess
I strongly agree. If we use ints now, then the next time the same question comes this function will be one more argument for using ints again. And the next time, and the next time, all this making that much work for when we cannot wait any longer to make the change, instead of that much less. Consistency is not a end in itself, it is a means to an end. And it is one of the weakest arguments. If there are no other reason for doing things one way or another, then sure, by all means let us choose the way that looks the same at the rest of the code. But if there is a reason, if one way is more efficient, or more convenient, or more future proof, or more compatible, etc., then we choose this way, and too bad for consistency. 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".
