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>

Change code style to match the rest of libav.

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