Michael Niedermayer
2f503851c6
fate: fix due to new yuv444 formats
...
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2011-10-03 23:43:22 +02:00
Michael Niedermayer
abe0b8e9f3
sws: use shift for chroma sample up convertion
...
sws: use shifts for non full range luma sample upconvertion
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2011-08-25 14:49:29 +02:00
Ronald S. Bultje
28c1115a91
swscale: use 15-bit intermediates for 9/10-bit scaling.
2011-08-12 11:54:25 -07:00
Ronald S. Bultje
62ee0e6a97
Revert "swscale: use 15-bit intermediates for 9/10-bit scaling."
...
This reverts commit ac0fb59348
. It
causes valgrind errors which I'll want to investigate before
resubmitting this.
2011-08-02 12:27:43 -07:00
Ronald S. Bultje
ac0fb59348
swscale: use 15-bit intermediates for 9/10-bit scaling.
2011-08-02 10:34:02 -07:00
Joseph Artsimovich
eedb1f2034
swscale: mark YUV422P10(LE,BE) as supported for output
...
Signed-off-by: Mans Rullgard <mans@mansr.com>
2011-07-21 02:10:31 +01:00
Ronald S. Bultje
7d7bacf0f1
swscale: fix overflow in 16-bit vertical scaling.
...
We operated on 31-bits, but with e.g. lanczos scaling, values can
add up to beyond 0x80000000, thus leading to output of zeroes. Drop
one bit of precision fixes this.
2011-07-08 15:15:30 -07:00
Ronald S. Bultje
f44d50a94c
swscale: fix 16-bit horizontal scaling underflow.
...
When using e.g. lanczos scaling, values can drop below 0, so they
should never be unsigned.
2011-07-08 15:15:30 -07:00
Ronald S. Bultje
42d622fab3
swscale: fix 16-bit scaling when output is 8-bits.
...
We would use the second half of the U plane buffer, rather than the
V plane buffer, to output the V plane pixels.
2011-07-08 15:15:30 -07:00
Ronald S. Bultje
ef1ee362b3
swscale: implement >8bit scaling support.
...
This means that precision is retained when scaling between sample
formats with >8 bits per component (48bit RGB, 16bit grayscale,
9/10/16bit YUV).
2011-06-29 09:45:52 -07:00
Mans Rullgard
b0da4903dd
fate: enable lavfi-pixmt tests on big endian systems
...
Signed-off-by: Mans Rullgard <mans@mansr.com>
2011-06-28 23:35:00 +01:00