| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
Non-RGB output always uses full chroma interpolation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes integer multiplication overflows in RGB48 output
(vertical) scaling as detected by IOC. What happens is that for
certain types of filters (lanczos, spline, bicubic), the
intermediate sum of coefficients in the middle of a filter can
be larger than the fixed-point equivalent of 1.0, even if the
final sum is 1.0. This is fine and we support that.
However, at frame edges, initFilter() will merge the coefficients
for the off-screen pixels into the top or bottom pixel, such as
to emulate edge extension. This means that suddenly, a single
coefficient can be larger than the fixed-point equivalent of
1.0, which the vertical scaling routines do not support.
Therefore, remove the merging of coefficients for edges for
the vertical scaling filter, and instead add edge detection
to the scaler itself so that it copies the pointers (not data)
for the edges (i.e. it uses line[0] for line[-1] as well), so
that a single coefficient is never larger than the fixed-point
equivalent of 1.0.
|
|
|
|
|
|
|
|
| |
this file uses the M_PI macro since
4e74187db2f5db52f88729efc662df9d6bc763e1, so include the correct header
directly.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was removed erroneously in
046f081b46c8479820409cf8f530b988221bd15b. This define still is
necessary for getting MAP_ANONYMOUS defined on linux/glibc,
despite the define reshuffling done in that commit.
Without MAP_ANONYMOUS defined, the mprotect calls for setting the
generated mmx2 scaler code pages executable are left out, causing
crashes if that codepath is chosen.
This patch fixes scaling from 192x144 to 320x240 with
-sws_flags fast_bilinear, which crashes on linux at the
moment.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Altivec does unaligned reads from this buffer in
hscale_altivec_real(), and can thus read up to 16 bytes beyond
the end of the buffer. Therefore, add an extra 16 bytes of
padding at the end of the conversion buffer.
This fixes fate-lavfi-pixfmts_scale on AltiVec-enabled builds
under valgrind.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
| |
The vertical scaler handles 2 rows at a time and thus requires
alignment by 2, or else it'll read invalid memory and result in
corrupt output.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
|
| |
|
|
|
|
|
|
| |
SSE-optimized hScale() scales up to 4 pixels at once, so we need to
allocate up to 3 padding pixels to prevent overreads. This fixes
valgrind errors in various swscale-tests on fate.
|
| |
|
|
|
|
|
|
|
|
|
| |
The logged information is possibly false, and it tends to be outdated
after each change since the logging code needs to be manually updated.
Simplify and prevent confusing wrong debug messages.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Also remove the unnecessary isSupportedIn/Out macros.
Make the code more compact/readable, and simplify the access to
lsws-specific pixel format information.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
|
| |
This reverts commit ac0fb5934893be554a44d2a1eb7a3bc7bf39da4a. It
causes valgrind errors which I'll want to investigate before
resubmitting this.
|
| |
|
|
|
|
| |
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
|
|
|
| |
Fixes a crash when forcing libc to strictly adhere to malloc sizes.
|
| |
|
| |
|
|
|
|
|
| |
We would use the second half of the U plane buffer, rather than the
V plane buffer, to output the V plane pixels.
|
|
|
|
|
| |
This functionality is only implemented for RGB24/32 and causes crashes
otherwise.
|
|
|
|
|
|
| |
For 9/10bit, it means we don't have to upscale to 16bit before
actual scaling or pixel format conversion, and thus a performance
gain.
|
|
|
|
|
|
| |
This means that precision is retained when scaling between sample
formats with >8 bits per component (48bit RGB, 16bit grayscale,
9/10/16bit YUV).
|
|
|
|
| |
This works through some non-obvious hacks in utils.c.
|
|
|
|
| |
Signed-off-by: Diego Biurrun <diego@biurrun.de>
|
|
|
|
|
|
|
| |
Also add missing glue code for recently added YUV422P10 formats
to swscale.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
|
|
|
|
| |
Inline functions are easier to read, maintain, modify and test,
which justifies the slightly increased source size. This patch
also adds support for non-native endianness RGB15/16 and fixes
isSupportedOutput() to no longer claim that we support writing
non-native RGB565/555/444.
|
|
|
|
|
| |
Altivec sws code intentionally overreads buffers for better performance,
so we need to allocate larger buffers to handle that.
|
| |
|
|
|
|
|
| |
That means it won't be allocated when not needed. Alongside
this, it fixes valgrind/fate-detected memory leaks.
|
| |
|
|
|
|
| |
Preparatory step to implement support for sizes > VOFW.
|
|
|
|
|
| |
This allows to convert between formats of arbitrary width,
regardless of the value of VOF/VOFW.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding _POSIX_C_SOURCE to CPPFLAGS globally produces all sorts of problems
since it causes certain system functions to be hidden on some (BSD) systems.
The solution is to only add the flag on systems that really require it, i.e.
glibc-based ones.
This change makes BSD systems compile out-of-the-box without the need for
adding specific flags manually. It also allows dropping a number of flags
set manually on a file-per-file basis, but were only present to work around
breakage introduced by the presence of _POSIX_C_SOURCE.
Also add _XOPEN_SOURCE to CPPFLAGS for glibc systems. We use XSI extensions
in several places already, so it is preferable to define it globally instead
of littering source files with individual #defines only needed for glibc.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
Also add support for these formats in libswscale.
Needed for high bit depth h264 decoding.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
|
|
|
|
| |
Signed-off-by: Anton Khirnov <anton@khirnov.net>
|
| |
|
|
|
|
| |
Signed-off-by: Mans Rullgard <mans@mansr.com>
|
| |
|
|
|
|
| |
also update the multiple inclusion guards in config.h|mak
|
|
|
|
|
|
|
|
|
|
|
| |
handle_jpeg may update the src/dstFormat variables, this makes sure the
updated version is stored in the context.
This fixes roundup issue 2302.
Patch by Troot, all_crap_goes_here at hotmail
Originally committed as revision 32562 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
|
|
|
|
|
|
|
| |
but worse it did not set up destination dimensions, thus every user
of it would necessarily fail.
Originally committed as revision 32424 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
|
|
|
|
| |
Originally committed as revision 32415 to svn://svn.mplayerhq.hu/mplayer/trunk/libswscale
|