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>

Change code style to match the rest of libav.

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

This reduces code duplication and prevents stale pointers from remaining
on the link.

This reduces code duplication and prevents stale pointers from remaining
on the link.

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.