The left and right samples are the same for the whole line, so store
their values and don't recompute them for every iteration of "y".
This simple optimization results in a speed improvement between 15%
and 20% in my tests (depending on the logo geometry.)
Result is obviously the same.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The top left hand corner pixel coordinates are already stored in
logo_x1 and logo_y1 so don't recompute each of them 6 times for every
iteration.
This is a simple code optimization, result is obviously the same. The
performance gain is small (about 2% in my tests) but still good to
have, and the new code is clearer.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by; Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e6d8acf6a8fba4743eb56eabe72a741d1bbee3cb':
indeo: use a typedef for the mc function pointer
cabac: x86 version of get_cabac_bypass
aic: use chroma scan tables while decoding luma component in progressive mode
Conflicts:
libavcodec/aic.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Data is appended in fill_buffer() when there is sufficient space left
and the data pointer only reset when needed.
Previously the data pointer was more often reset, loosing more seekback
space than otherwise needed.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The aix header math.h defines "extern int class()" for C.
This fixes compilation on aix with external libraries enabled.
Signed-off-by: Carl Eugen Hoyos <cehoyos@ag.or.at>
For some unclear reason Apple decided to use the same scan tables for luma and
chroma in the progressive mode while using different ones for luma in the
interlaced mode.
When operating on subsampled chroma planes, some rounding is taking
place. The left and top borders are rounded down while the width and
height are rounded up, so all rounding is done outward to guarantee the
logo area is fully covered.
The problem is that the width and height are counted from the
unrounded left and top borders, respectively. So if the left or top
border position has indeed been rounded down, and the width or height
needs no rounding (up), the position of the the right or bottom border
will be effectively rounded down, i.e. inward.
The issue can easily be seen with a yuv240p input and
-vf delogo=45:45:60:40:show=1 -vframes 1 delogo-bug.png
(or virtually any logo area with odd x and y and even width and
height.) The right and bottom chroma borders (in green) are clearly
off.
In order to fix this, the width and height must be adjusted to include
the bits lost in the rounding of the left and top border positions,
respectively, prior to being themselves rounded up.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When interpolating, weights are based on relative distances, which
assume square pixels. If a non-1:1 sample aspect ratio is used, it
should be taken into account when comparing distances, because the
human eye and brain care about the picture as it is displayed, not
stored.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
jpeg2000: Use the matching coding style struct for transform selection
jpeg2000: Merge rescaling with interleaving in 9/7 IDWT
No change, all commits & hunks where already in.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '22e18ea39e371030cc78973d1b46aae45a7ea215':
jpeg2000: Optimize output sample conversion
jpeg2000: Reset s->numX/Ytiles on tile deallocation
jpeg2000: Optimize dequantization
jpeg2000: Do not assume a single tile
jpeg2000: Speed up jpeg2000_decode_tile()
jpeg2000: Use EBCOT's CAUSAL and BYPASS mode in decode_cblk()
Conflicts:
libavcodec/jpeg2000dec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>