Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This is a fairly dumb copy of the assembly for 8-bit samples but it
works and produces identical output to the C version.  The options have
been tested on an Athlon64 and a Core2Quad.

Athlon64:
1810385 decicycles in C,    32726 runs, 42 skips
1080744 decicycles in mmx,  32744 runs, 24 skips, 1.7x faster
 818315 decicycles in sse2, 32735 runs, 33 skips, 2.2x faster

Core2Quad:
 924025 decicycles in C,     32750 runs, 18 skips
 623995 decicycles in mmx,   32767 runs,  1 skips, 1.5x faster
 406223 decicycles in sse2,  32764 runs,  4 skips, 2.3x faster
 387842 decicycles in ssse3, 32767 runs,  1 skips, 2.4x faster
 307726 decicycles in sse4,  32763 runs,  5 skips, 3.0x faster

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The C code treats the data as arrays of uint16_t so strides must not
be in bytes but in pixels.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Always use the special filter for the first and last 3 columns (only).

Changes made in 64ed397 slowed the filter to just under 3/4 of what it
was.  This commit restores the speed while maintaining identical output.

For reference, on my Athlon64:
1733222 decicycles in old
2358563 decicycles in new
1727558 decicycles in this

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Deprecate AVFilterBuffer/AVFilterBufferRef and everything related to it
and use AVFrame instead.

Found by: durandal_1707
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Finish what 99162f8 started

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Some changes in the border pixels, visually indistinguishable.

Do it all in config_props().

clang says:
libavfilter/vf_yadif.c:192:28: warning: incompatible pointer types assigning to
'void (*)(uint8_t *, uint8_t *, uint8_t *, uint8_t *, int, int, int, int, int)'
from 'void (uint16_t *, uint16_t *, uint16_t *, uint16_t *, int, int, int, int, int)'

Fix trac ticket #2128.

Signed-off-by: Stefano Sabatini <stefasab@gmail.com>

Also rename the "enable_auto" field to "deint", to match the name of the
option.

This is better than repeatedly failing during the filtering stage.

signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Any alleged performance benefits gained from the split are purely
mythological and do not justify added code complexity.

A number of compilers, for example those from TI and IBM, choke on
these initialisers.  The current style is also quite ugly.

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Require AV_PERM_PRESERVE and leave harmless permissions
alone for the next filter.

yadif needs at least 3x3 or it will likely crash with out of array reads

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The previous code dependent on the input buffer matching the
buffer that has been provided by yadifs get_buffer.
The API does in now way gurantee this though its often true.
This fixes some out of array reads.
The regression test checksums change due to "out of picture" values
being initialized differently.
There should be no visual difference in the filters output

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The buffer is stored internally, so this prevents it from being unreffed
automatically.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Mans Rullgard <mans@mansr.com>

It is not used in any filters currently and is inherently evil. If
passing binary data to filters is required in the future, it should be
done with some AVOptions-based system.

They are only useful inside filters and we don't allow user filters for
now.

They are only useful inside filters and we don't allow user filters for
now.

It is only useful inside filters and we don't allow user filters for
now.

Those functions are only useful inside filters. It is better to not
support user filters until the API is more stable.

The correct invariant is (cur != NULL -> next != NULL). Not the other way around.

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>