Signed-off-by: Diego Biurrun <diego@biurrun.de>

Libav, for some reason, merged this as a public API function. This will
aid in future merges.

A define is left for backwards compat, just in case some person
used it, since it is in a public header.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

It is well known that fabs and fabsf are at least as fast and sometimes
faster than the FFABS macro, at least on the gcc+glibc combination.
For instance, see the reference:
http://patchwork.sourceware.org/patch/6735/.
This was a patch to glibc in order to remove their usages of a macro.

The reason essentially boils down to fabs using the __builtin_fabs of
the compiler, while FFABS needs to infer to not use a branch and to
simply change the sign bit. Usually the inference works, but sometimes
it does not. This may be easily checked by looking at the asm.

This also has the added benefit of reducing macro usage, which has
problems with side-effects.

Note that avcodec is not handled here, as it is huge and
most things there are integer arithmetic anyway.

Tested with FATE.

Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

The new fields can be accessed directly and are more intelligible.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

With bps > 8 more than 255..255 are used
The initialized table content is left unchanged,
But it could also be adjusted for the slight difference of
the maximum

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

This code looks clumsy, and an assert would probably be more welcome.

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

Arch specific calls should have an emms_c following to keep the cpu
state consistent.

Reported-By: wm4
CC: libav-stable@libav.org

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Do not leak all the temp buffers.

This is shorter and consistent across filters.

This should fix several issues with odd dimensions inputs.

lut, vflip, pad and crop video filters also need to be checked for such
issues. It's possible sws is also affected.

The filter stores some temporal data, which needs to be done with the
passthrough callback system when timeline is enabled. Until then,
timeline support is disabled.

Flag added in a few simple filters. A bunch of other filters can likely
use the feature as well.

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

Conflicts:

	libavfilter/avfilter.c
	libavfilter/vf_drawtext.c
	libavfilter/vf_lut.c
	libavfilter/vf_select.c
	libavfilter/vf_setpts.c
	libavfilter/vsrc_color.c
	libavfilter/vsrc_movie.c

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

CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>

CC:libav-stable@libav.org

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

%f denotes a double argument and 'l' does nothing in this case
according to the C spec.

video->[wh] will be set with the same values as the input after
avfilter_copy_buffer_ref_props. These filters don't change the size of
the input so there is no need for this code.

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

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>

Fixes ticket1752

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

This should fix compilation with gcc 3

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

Compilation seems to fail on GCC 3.4 due to this duplicate
declaration.

Signed-off-by: Martin Storsjö <martin@martin.st>

This C99 feature is generally not used in the libav codebase,
since it breaks building with some fringe compilers (GCC 2.95,
MSVC).

Signed-off-by: Martin Storsjö <martin@martin.st>

This should fix compilation with gcc 2.95 and possibly others

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

13% faster on penryn, 16% on sandybridge, 15% on bulldozer
Not simd; a compiler should have generated this, but gcc didn't.

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

11% faster on penryn, 7% on sandybridge, 5% on bulldozer
Negligible change to output.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

14% faster on penryn, 2% on sandybridge, 9% on bulldozer

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>