| Message ID | 20190324130451.1eaf06dd835ab700ef89fea2@gmx.com |
|---|---|
| State | Superseded |
| Headers | show |
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 <cand@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 [...]
On Mon, 25 Mar 2019 11:17:38 +0100 Michael Niedermayer <michael@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 <cand@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... - Lauri
On Mon, Mar 25, 2019 at 11:35 AM Lauri Kasanen <cand@gmx.com> wrote: > > On Mon, 25 Mar 2019 11:17:38 +0100 > Michael Niedermayer <michael@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 <cand@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
On Mon, Mar 25, 2019 at 12:37:37PM +0200, Lauri Kasanen wrote: > On Mon, 25 Mar 2019 11:17:38 +0100 > Michael Niedermayer <michael@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 <cand@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... yes, but its parent did not had the other cliping code, it should have been a bugfix only as long as the other code wasnt there [...]
On Mon, Mar 25, 2019 at 12:36:24PM +0100, Hendrik Leppkes wrote: > On Mon, Mar 25, 2019 at 11:35 AM Lauri Kasanen <cand@gmx.com> wrote: > > > > On Mon, 25 Mar 2019 11:17:38 +0100 > > Michael Niedermayer <michael@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 <cand@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 ... [...]
diff --git a/libswscale/output.c b/libswscale/output.c index d7c53e6..8441ddd 100644 --- a/libswscale/output.c +++ b/libswscale/output.c @@ -846,13 +846,6 @@ yuv2422_1_c_template(SwsContext *c, const int16_t *buf0, int U = (ubuf0[i] +64) >> 7; int V = (vbuf0[i] +64) >> 7; - if ((Y1 | Y2 | U | V) & 0x100) { - Y1 = av_clip_uint8(Y1); - Y2 = av_clip_uint8(Y2); - U = av_clip_uint8(U); - V = av_clip_uint8(V); - } - Y1 = av_clip_uint8(Y1); Y2 = av_clip_uint8(Y2); U = av_clip_uint8(U); @@ -868,13 +861,6 @@ yuv2422_1_c_template(SwsContext *c, const int16_t *buf0, int U = (ubuf0[i] + ubuf1[i]+128) >> 8; int V = (vbuf0[i] + vbuf1[i]+128) >> 8; - if ((Y1 | Y2 | U | V) & 0x100) { - Y1 = av_clip_uint8(Y1); - Y2 = av_clip_uint8(Y2); - U = av_clip_uint8(U); - V = av_clip_uint8(V); - } - Y1 = av_clip_uint8(Y1); Y2 = av_clip_uint8(Y2); U = av_clip_uint8(U);
In this function, the exact same clamping happens both in the if and unconditionally. Signed-off-by: Lauri Kasanen <cand@gmx.com> --- libswscale/output.c | 14 -------------- 1 file changed, 14 deletions(-) -- 2.6.2