In the loop:
for (i=0; i<dstH; i++) {
int chrI= i*c->chrDstH / dstH;
when i*c->chrDstH > INT_MAX this leads to an integer overflow, which
results in a negative value for chrI and in out-of-buffer reads. The
overflow is avoided by forcing int64_t arithmetic by casting i to
int64_t.
Fix crash, and trac issue #72.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
PPC and x86 code is split off from swscale_template.c. Lots of code is
still duplicated and should be removed later.
Again uniformize the init system to be more similar to the dsputil one.
Unset h*scale_fast in the x86 init in order to make the output
consistent with the previous status. Thanks to Josh for spotting it.
Keep only the plain C code in the main rgb2rgb.c and move the x86
specific optimizations to x86/rgb2rgb.c
Change the initialization pattern a little so some of it can be
factorized to behave more like dsputils.
When HAVE_7REGS was not defined these functions had an empty body
causing the following warnings during compilation.
In file included from libswscale/x86/yuv2rgb_mmx.c:58:
libswscale/x86/yuv2rgb_template.c: In function ‘yuva420_rgb32_MMX’:
libswscale/x86/yuv2rgb_template.c:412: warning: no return statement in function returning non-void
libswscale/x86/yuv2rgb_template.c: In function ‘yuva420_bgr32_MMX’:
libswscale/x86/yuv2rgb_template.c:457: warning: no return statement in function returning non-void
Signed-off-by: Diego Biurrun <diego@biurrun.de>
swscale doesnt ever actually do any runtime detection at all when
runtime cpu detection is enabled, it simply passes whatever is passed
to -sws_flags, which could be nothing at all making swscale default to
the C implementation.
Heres a benchmark
VOFW 5120 VOFW 21504 Note
10438.8 10344.2 timex ffmpeg -y -i tulip2.mp4 tulip2.yuv
25611.9 24256.9 timex ffmpeg -y -itulip2.mp4 -s 1272x724 tulip2.yuv
24485.7 26006.6
28573.1 24291.3
24069.1 26995.9
25684.95 25387.675 average
This is on a Nehalem i7. Despite being a 500 frame, 720p video, the numbers
fluctuate, so I took an average of 4 runs.
Another reason I'd like this change is youtube accepts videos with higher
resolutions than 5120.
16384 is vp8's maximum resolution, so that should keep us amused for a
little longer.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>