On Sun, Feb 09, 2020 at 09:28:48PM +0100, Michael Niedermayer wrote: > On Sat, Feb 01, 2020 at 11:48:06PM +0100, Michael Niedermayer wrote: > > On Sat, Feb 01, 2020 at 04:17:10PM +0100, Paul B Mahol wrote: > > > On 2/1/20, Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > On Tue, Jan 14, 2020 at 04:04:29PM +0100, Paul B Mahol wrote: > > > >> This better belong to generic code. > > > > > > > > This specific check (which checks for INT_MAX) is specific to our > > > > bink audio code which does a +1 > > > > so it would not fit in generic code > > > > > > > > We could arbitrarily decide on a maximum sample rate hardcode that > > > > and check for that in generic code. > > > > I can implement that if people prefer. It would not avoid all > > > > sample rate checks in codecs though ... > > > > > > sample rate can not be > INT_MAX > > > > no and the code also doesnt check > INT_MAX > > I think you maybe missed the = in >= > > theres a +1 and INT_MAX+1 is bad so INT_MAX is checked for > > we can do that in generic code but its only this decoder that has this > > issue other decoders may have other limits. That makes this specific > > check threshold bad for a check in generic code. Another threshold > > would work in generic code, it would be arbitrary though and limit > > most decoders more than needed > > Iam happy to implement what people prefer but the check as it is > > makes not much sense if its moved as is into generic code > > any preferrance on how to solve this ? > or you are ok with the patch ?
ping [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes
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".
