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? Perhaps another bit pattern with more high bits set would solve that. - Hendrik _______________________________________________ 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".
