summaryrefslogtreecommitdiff
path: root/src/xine-utils
AgeCommit message (Collapse)Author
2013-04-15xine_mmx.h: make sure alignment macros are defined. Make some noise if ↵Petri Hintukainen
alignment requirements are not met.
2013-01-21rgb2yuy2: added 16/15/8 bit formatsTorsten Jager
2012-12-05color.c: direct rgb->yuy2 converterTorsten Jager
2012-10-07yuv444_to_yuy2_mmx: follow target UV pitchTorsten Jager
2012-07-16Added configure check for AVX assembler supportPetri Hintukainen
2012-07-12avx memcpyPetri Hintukainen
2012-07-12sanity check for memcpy method config valuePetri Hintukainen
2012-06-05Merge from 1.1Petri Hintukainen
2012-06-05Fix building with cygwinCarlo Bramini
CYGWIN is a full POSIX environment, it does not need to include windows.h (it even causes an error if you try).
2012-05-29Fixed 91d04bf1862cPetri Hintukainen
2012-05-29Moved defining ATTR_ALIGN after include configure.h.Petri Hintukainen
ATTRIBUTE_ALIGNED_MAX is defined in configure.h.
2012-05-29Removed extra semicolonCarlo Bramini
2012-05-28Added yv12_to_yuy2_sse2()Petri Hintukainen
2012-05-23Added missing #include "config.h" to make ATTR_ALIGN workPetri Hintukainen
2012-05-16xine_mmx.h: added 32-bit integers to sse_tPetri Hintukainen
2012-05-16xine_mmx.h: added SSE2 pslldq and psrldqPetri Hintukainen
2012-04-11Marked data const and fixed typePetri Hintukainen
2012-02-15Improved RGB→YUV conversion v2 (use MPEG range instead of full range)Darren Salt
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.)
2012-02-14Backed out RGB→YUV patch – API change.Darren Salt
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.
2012-02-14Improved RGB->YUV conversion (use mpeg range instead of full range)Torsten Jager
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.
2011-12-31Merge.Darren Salt
2011-12-22Use proper chroma upsampling for yv12 to yuy2 conversionRoland Scheidegger
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
2012-04-04xine_mmx.h: Added pmaddubsw (SSSE3)Petri Hintukainen
2012-04-11Added MMXEXT version of yv12_to_yuy2()Roland Scheidegger
2012-04-11Removed incorrect .align directives from asm codePetri Hintukainen
2012-04-11MMX version of yv12_to_yuy2()Roland Scheidegger
2012-04-10yv12_to_yuy2: use the same macros for both odd and even linesRoland Scheidegger
(as a simple argument swap is all that's needed).
2012-04-04Fixed pmovmskb() and added a version that can be actually used.Petri Hintukainen
2012-03-29Detect CPU/OS support for SSE3, SSSE3, SSE4, SSE42 and AVXPetri Hintukainen
2012-03-29Added some SSE2 instructionsPetri Hintukainen
2012-03-29Added integer types to sse_t unionPetri Hintukainen
2012-03-29Added macros for loading 32-bit value to mmx/sse register from memory or GP ↵Petri Hintukainen
register (mmx_a2r)
2012-02-15Merge from 1.1.Darren Salt
--HG-- rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
2012-02-14Merge from 1.1Petri Hintukainen
--HG-- rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
2012-01-10Fixed printf argumentPetri Hintukainen
2012-01-10Removed unused variable from enum definitionPetri Hintukainen
2012-01-10Include xine_private.h to get xine_probe_fast_memcpy() definitionPetri Hintukainen
2011-12-31Merge from 1.1.Darren Salt
2011-12-16MergePetri Hintukainen
2011-12-16Silenced warningPetri Hintukainen
--HG-- branch : point-release
2011-12-10Merge from 1.1.Darren Salt
--HG-- rename : src/liba52/xine_a52_decoder.c => src/audio_dec/xine_a52_decoder.c rename : src/libspudvb/xine_spudvb_decoder.c => src/spu_dec/spudvb_decoder.c rename : src/libxinevdec/image.c => src/video_dec/image.c
2011-11-25Fixed using uninitialized variable (segfault in memcpy.c)Petri Hintukainen
2011-11-18Use POSIX timers where available for determining which memcpy method to use.Darren Salt
2011-10-17Merge from 1.1Petri Hintukainen
2011-10-17Merge from 1.1Petri Hintukainen
--HG-- rename : src/xine-engine/xine_internal.h => include/xine/xine_internal.h rename : src/xine-utils/xineutils.h => include/xine/xineutils.h
2011-10-11Merge from 1.1.Darren Salt
--HG-- rename : src/xine-engine/post.h => include/xine/post.h rename : po/libxine1.pot => po/libxine2.pot
2011-10-10Fixed asprintf usagePetri Hintukainen
2011-10-10Added asprintf wrapperPetri Hintukainen
2011-10-10xine_check: check vasprintf() return valuePetri Hintukainen
2011-10-03Set CLOEXEC flag on three more sockets.Chris Rankin
There are two functions that actually set this flag: int _x_set_file_close_on_exec() int _x_set_socket_close_on_exec() (We need two functions because file descriptors and sockets are not the same under WIN32 - of course). These function belong to libxine's internal API, i.e. they are not available for use by plugins.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-22 13:54:40 +0000