On Mon, Mar 25, 2019 at 12:36:24PM +0100, Hendrik Leppkes wrote: > On Mon, Mar 25, 2019 at 11:35 AM Lauri Kasanen <c...@gmx.com> wrote: > > > > On Mon, 25 Mar 2019 11:17:38 +0100 > > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > > > On Sun, Mar 24, 2019 at 01:04:51PM +0200, Lauri Kasanen wrote: > > > > In this function, the exact same clamping happens both in the if and > > > > unconditionally. > > > > > > > > Signed-off-by: Lauri Kasanen <c...@gmx.com> > > > > --- > > > > libswscale/output.c | 14 -------------- > > > > 1 file changed, 14 deletions(-) > > > > > > The removed code is the one that should stay, the other should be > > > removed. > > > one check for a rarely true condition should be faster than 4 checks > > > > Yes, I thought so too, but the commit that added the unconditional code > > says it fixes a bug... > > > > Could it overflow so high that other bits then the one being checked > for are set?
in realistic cases this should not happen. It may be possible to construct a case with crafted scale parameters where this happens > Perhaps another bit pattern with more high bits set would > solve that. yes, actually i thought we did use a different pattern ... [...] -- 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".
