Remove unused variables "flags" and "dstFormat" in yuv2packed1,
merge source rows per plane for yuv2packed[12], and make every
source argument int16_t (some where invalidly set to uint16_t).
This prevents stack pollution and is part of the Great Evil Plan
to simplify swscale.
They are hacks added to reuse the same scaling function for
different formats and they may cause problems when SIMD
implementation of the same functions are used along with pure
C functions.
Reintroduce the internal symbol which was removed in:
commit e1197b9e17
Author: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Date: Sun May 29 17:57:40 2011 +0200
swscale: remove sws_format_name()
Use av_get_pix_fmt_name() instead.
The symbol is used by some external libs (hi libx264!), this gives
time to them to use the recently added av_get_pix_fmt_name() rather
than an internal symbol.
commit 93681fbd50
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Thu May 26 11:32:32 2011 -0400
swscale: fix compile on ppc.
commit e758573a88
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Thu May 26 10:36:47 2011 -0400
swscale: fix compile on x86-32.
commit 0f4eb8b043
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Thu May 26 09:17:52 2011 -0400
swscale: remove VOF/VOFW.
commit b4a224c5e4
Author: Ronald S. Bultje <rsbultje@gmail.com>
Date: Wed May 25 14:30:09 2011 -0400
swscale: split chroma buffers into separate U/V planes.
Preparatory step to implement support for sizes > VOFW.
Fix handling of input if not in native endianness, and add support for
9/10-bit output. This allows us to force endianness of YUV420P 9/10bit
in the H264/10bit fate tests, which should fix them on big-endian
systems.
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>
x86_64 / Mac OS X gcc 4.0.1
x86_64 / Linux icc (all)
x86_64 / Linux gcc 4.0.4
x86_64 / OpenBSD gcc 3.3.5
x86_64 / Linux suncc 5.10
and there are some reports of crashes.
Originally committed as revision 31170 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
long was being incorrectly used as an x86-sized register, both for 32 and 64
bits, but this is not the case in win64.
Originally committed as revision 31153 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale