Age | Commit message (Collapse) | Author |
|
need color space conversion ...
|
|
thread count needs to be set before avcodec_open otherwise it will be stuck
with a single thread at least for h264 (might also want to use avcodec_open2
instead?)
|
|
yuv2rgb_mmx.c scales YUV and rounds them down to 8 bits
individually before the addition. That causes red and
blue to be off by up to 2, green even off by 3.
This little patch does the stuff using 10 bits per
component, plus correct rounding.
There seems to be no noticable impact on performance,
but color gradients come out much smoother now.
|
|
Cuts roughly 10% of the instructions (with sse), results should be
identical.
Not sure why it was that complicated in the first place, the
simplification is possible because the code gave a score of 1 to top and
bottom comparisons, and 2 for the middle one, and weaved when all scores
added together were more than 2. This is equivalent to weave when
(cmp(m) AND (cmp(b) OR cmp(t))) which is a much better match for the
available hw instructions. This also reduces the number of constant
loads a lot, and the patch moves up some memory loads a bit which can
never hurt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(as a simple argument swap is all that's needed).
|
|
|
|
|
|
|
|
|
|
|
|
register (mmx_a2r)
|
|
|
|
|
|
systems
|
|
--HG--
rename : src/xine-utils/xineutils.h => include/xine/xineutils.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.
|
|
--HG--
rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
|
|
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.
|
|
|
|
|
|
--HG--
rename : debian/dh_xine => debian/dh_xine.in
|
|
|
|
|
|
|
|
--HG--
branch : 1.2.1-branch
|
|
|
|
--HG--
branch : 1.2.1-branch
|
|
--HG--
branch : 1.2.1-branch
|
|
|
|
|
|
driver.
|
|
|
|
In 2005, xine-lib 1.1.1 added the following change:
xine-lib (1.1.1) 2005-11-15
* Improve sound quality when using alsa 1.0.9 or above.
When playing a 44.1khz stream on a 48khz only capable sound card.
It bypasses alsa-lib resampler and uses xine's
That made sense when Alsa's resampling was the worst thing ever. But now,
if one installs alsa-plugins-1.0.25 and puts this in ~/.asoundrc:
defaults.pcm.rate_converter "samplerate_best"
Alsa then does markedly better resampling (using libsamplerate) than
xine-lib (using its own algorithm). The bypass added in 2005 is therefore
preventing the use of a higher-quality algorithm and blocking the ability to
tune that algorithm in ~/.asoundrc, and no longer seems to have any
redeeming value.
--HG--
extra : transplant_source : %AE%96zte%B0%ED%B6C%BC%89%02%1F%05%21%BD%ED%D6%8C6
|
|
|
|
|
|
|
|
|
|
|
|
conversion.
Proper (HW-accelerated) implementation would use OpenGL texture to blend the OSD directly to RGB video texture.
|
|
--HG--
rename : include/xine.h.in => include/xine.h
rename : src/xine-engine/xine_internal.h => include/xine/xine_internal.h
rename : src/combined/ffmpeg/ffmpeg_encoder.c => src/dxr3/ffmpeg_encoder.c
|
|
|