| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
--HG--
branch : point-release
|
|
|
|
|
|
|
|
capability, and force an error if someone tries to include xine_private.h in an unsuitable source file.
|
|
|
|
_x_set_file_close_on_exec() and _x_set_socket_close_on_exec() prototypes were missing.
We need the prototypes because of visibility attributes.
|
|
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 have been assigned "internal" visibility so
that they can be used throughout libxine.so itself while still
not being exported to the global symbol table. In other words,
they're both as close to being "static" as I can make them.
|
|
xine_socket_cloexec() function.
|
|
|
|
This patch creates two utility functions:
int open_cloexec(pathname, flags)
int create_cloexec(pathname, flags, mode)
These return a file descriptor with the CLOEXEC flag set, to ensure
that the descriptor is not inherited across a fork/exec operation.
The sockets returned by:
_x_io_tcp_connect_ipv4()
_x_io_tcp_connect()
now also have their CLOEXEC flag set.
|
|
|
|
|
|
- use type of enough size for pointer types (uintptr_t)
- fixes "Unhandled exception" in memcpy code
|
|
- symbols in objects built by mingw64 not mangled
- fixes build of deinterlace post plugin
|
|
|
|
|
|
|
|
|
|
MSVC complained about a memset to a const object and all "long long"
variables that are GNU only. I fixed it by grouping the fields into a
structure and now even GCC is more happy.
|
|
|
|
|
|
|
|
This requires that many other files include config.h themselves.
Also convert <config.h> to "config.h".
|
|
This does not incompatibly change the API and has no effect on the ABI.
--HG--
rename : src/xine-utils/xineutils.h => src/xine-utils/xine_mmx.h
|
|
Add warning flags to the DEBUG_CFLAGS too.
|
|
Bug was found and fixed by Carlo Bramini.
select() does not work on mingw+msys causing xine_usec_sleep to sleep much
longer than requested which completely broke audio playback
|
|
xine_get_pluginroot now makes use of the XINE_REL_PLUGINROOT define
|
|
<xine-internals.h> includes <xine-utils/refcounter.h> which includes
<pthread.h>. As all xine sources include <xine-internal.h>, the
PTHREAD_CFLAGS are always needed. This patch removed it from two Makefile.am
and adds them to CPPFLAGS
|
|
--HG--
extra : transplant_source : %00%23%8FM%AA%B88C%FEA%7E%2C%D3%F5%29%8F%28%AC%D7_
|
|
|
|
|
|
Adjust translations for the spacing changes etc. which this introduces.
|
|
All the initialisation functions returning a new object instance that
was allocated through malloc() or calloc() can get the malloc
attribute so that the compiler can optimise their call.
|
|
Its result will be always the same during execution, as it depends on
the hardware present.
--HG--
extra : transplant_source : %F2%D1%1A%84%0F%D4%08%C0%12%09%1A%BBb%7Ef%CC%F2%FB%A3t
|
|
Add CC_ATTRIBUTE_CONST macro to the attributes.h.
Run CC_ATTRIBUTE_CONST in configure.
Define SUPPORT_ATTRIBUTE_CONST for GCC 3.
Define XINE_CONST to __attribute__((__const__)) if supported.
--HG--
extra : transplant_source : /26%26%DF%C0%3C%AC%27%5C%B7%B1y%FEQ%8Ay%EE%F1%BD
|
|
When using a variable to store the result of strlen(), make sure its
type is size_t just like the function returns, rather than using a
smaller type like int.
--HG--
extra : transplant_source : %B0%D5%3B%D7%1Dy%0A%7E%7D%7C%023%08%B2%CE%D3t%0B3%D7
|
|
Use the proper function for common memory operations (memset() for
zeroing, memcpy() for copying, memmove() for moving), instead of
looping through arrays.
By extension, remove loops to reset arrays when they were allocated
with calloc() and thus already zeroed.
|
|
Also don't reset memory after it's allocated if we do that with
calloc.
|
|
- Add a configure test for the attribute, during xine build process.
- Define the attribute as supported when using GCC 2.95 or later
outside xine build process.
- Use the new XINE_PACKED define instead of the attribute directly.
- Check for SUPPORT_ATTRIBUTE_PACKED rather than doing strange
subdefines.
|
|
|
|
|
|
The xine_xmalloc() function is going to be deprecated, as its
behaviour is rarely needed as such, and it's thus misused.
With this, almost all uses of xine_xmalloc() with static size (for
instance the value returned by sizeof()) or with a size that is
guaranteed not to be zero (like strlen()+1) are replaced with calls to
either calloc(1, ...) or malloc().
malloc() is used whenever the allocated memory is going to be
immediately overwritten, while calloc() is used in every other case,
as it sets the whole memory area to zero.
--HG--
extra : transplant_source : %8F%98%EC%02%1E%83%F0s%06X%83C%205Y%80%B12%CC%E1
|
|
|
|
When we're including xine/attributes.h but we're not building xine,
define the support for particular attributes based on the compiler and
its version. This way semantic information is maintained outside
xine's build (such as deprecated functions).
|
|
The xine_check.h header is not currently installed and the symbols are
not exported, their are only ever used in the same unit they are
defined.
|
|
rather than just checking for GCC 3.
|
|
|
|
|
