| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* palette color count guard.
* add 4, 2, 1 bit palette support.
* use default gray on NULL palette.
* optional xine clut_t output.
|
|
|
|
|
|
Making them all "const char * const *" did work too
(even with Kaffeine build/run), but that would be
an API change.
|
|
|
|
BTW. Happy 2014 to you!
Didnt think xine will survive this far :-)
And yes, I finally got an ffmpeg patch through. That kind of rounds the circle :-)
|
|
|
|
|
|
|
|
Emitting vzeroupper is necessary to avoid avx<->sse transition penalties (when
using avx-256 instructions).
This didn't really matter much in the past, since other code wasn't using avx,
hence there was just a penalty once afterwards when sse code was executed.
However, there's code in ffmpeg which mixes avx-128 and sse a lot, and each
time this happens there's a huge penalty. This causes in particular
ff_deblock_v_luma_8_avx to slow down by a factor of 50 or so which makes the
whole decoding about twice as slow (might be dependent on the h264 stream or
maybe ffmpeg version too, since ffmpeg will also emit vzeroupper when using
avx-256 hence not doing it here might not always be an issue, but in the case
I was seeing nothing else used avx-256).
|
|
script execution time: 55"
|
|
alignment requirements are not met.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CYGWIN is a full POSIX environment, it does not need to include windows.h (it
even causes an error if you try).
|
|
|
|
ATTRIBUTE_ALIGNED_MAX is defined in configure.h.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Video-out plugins expect MPEG range Y'CbCr data (Y'=16..235, Cb,Cr=16..240).
RGB sources (still images and audio visualisation effects) need to be
converted first.
This patch fixes up the range calculations and corrects an off-by-one in the
range for Cb and Cr over commit 68fcd69fb3b6 (which was reverted due to API
change). It should also provide a little more accuracy: I've gone back to
the source (http://www.itu.int/rec/R-REC-BT.601/) for the conversion
information.
(We should use float or double here, but that would be an ABI change.)
|
|
Anything which uses the COMPUTE_* macros would need to be recompiled because
of the use of new tables. This change needs to be conditional somehow, at
least externally.
|
|
Video out plugins expect mpeg range yuv data (y=16..235, uv=16..239).
RGB sources (still images and audio visualisation effects) need
to be converted first.
|
|
|
|
The old code did some "averaging" which, while cheap, lead to serious
chroma shift because the weighting factors turned out to be pretty random
(arguably no averaging likely would have been given more correct results).
It also in fact lead to chroma ghosts.
To see why this was wrong read the following and then do the math.
http://www.hometheaterhifi.com/the-dvd-benchmark/179-the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html
http://avisynth.org/mediawiki/Sampling
As an example, let's look what happens at line 4 for interlaced content
(where the code would have averaged chroma from chroma line 2 and 4):
Chroma line 2 contains chroma values for line 2 (25%) and 4 (75%) while
chroma line 4 contains chroma values for line 6 (25%) and 8 (75%) of the
original (prior to subsampling) frame.
Average these together and you get something quite wrong. Most importantly
the center of these weights will be at 5.5 instead of 4 (hence chroma shift).
For odd lines it is different (better but still wrong).
So, fix this by using the correct weights for reconstruction of the chroma
values (which is averaging for the progressive case for all pixels since the
samples are defined to be between the lines, and use different weighting
factors for odd/even/"upper"/"lower" lines).
This runs more than twice the instructions (for the mmx case), but I measured
only a performance impact of roughly 5% (on a Athlon64 X2) - seriously bound
by memory access (by comparison the sort-of-pointless post-deinterlace chroma
filter is nearly twice as slow hence if you don't need it because the values
are correct this will be a lot faster).
Note: this is only correct for codecs which use the same chroma positions
as mpeg2 (dv is definitely different, mpeg1 is also different but only for
horizontal positioning, which doesn't matter here). "yv12" as such seems
underspecified wrt chroma positioning.
On another note, while this algorithm may be correct, it is inherently
suboptimal doing this pre-deinterlace (and a post-deinterlace chroma
filter is not going to help much neither except it can blur the mess).
This NEEDS to be part of deinterlace (which btw would also be quite a bit
faster when handling planar directly due to saving one pass of going
through all memory).
The reason is while line 4 will now use the correct weighting factors,
the fact remains it will use chroma values originating from lines 2, 4, 6
and 8 of the original image. However, if the deinterlacer decides to weave
because there is no motion, it CAN and most likely wants to use chroma values
from the other field (hence values originating from line 2, 3, 4, 5 in this
case when using a very simple filter, with appropriate weighting).
--HG--
branch : point-release
extra : rebase_source : 808bb5785ca398970324bea6b391a9e24c576d2f
|
|
|
|
|
|
|
|
|
|
(as a simple argument swap is all that's needed).
|
|
|
|
|
|
|
|
|
|
register (mmx_a2r)
|
|
--HG--
rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
|
|
--HG--
rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
|
|
|
|
|
|
|
|
|
