The current SSE version is slower than the MMX version on Athlon64 and Sandy
Bridge, but the SSE4 and AVX versions are faster on Sandy Bridge.

This is easier to follow than having them randomly scattered in
avfilter.c and defaults.c.

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

This breaks audio filtering API and ABI in theory, but since it's
unusable right now this shouldn't be a problem.

There is no real reason for it to be 64bit, it's just a plain int in the
rest of Libav.

There's no reason for it to be explicitly 32 bits. It's declared as a
plain int in all other places in Libav.

This breaks audio filtering API and ABI in theory, but since it's
unusable right now this shouldn't be a problem.

The additional parameters are just complicating the function interface.

Assume that a requested samples buffer will *always* have the format
specified in the requested link.

This breaks audio filtering API and ABI in theory, but since it's
unusable right now this shouldn't be a problem.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Remove AVFilterBufferRefAudioProps.size, and use nb_samples in its place
everywhere.
This is required as the size in the audio buffer may be aligned, so it
may not contain a well defined number of samples.

Also remove the useless planar parameter, which can be deduced from the
sample format.

This is technically an API and ABI break, but since the audio part of
lavfi is not usable now, this should not be a problem in practice.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This allows compiling the Xvid rate control code without the encoder.

libavcodec/jpeglsdec.c:54:9: warning: variable ‘len’ set but not used

Signed-off-by: Anton Khirnov <anton@khirnov.net>

This is similar to what has previously been done in AVFrame to allow
dealing with more than 8 channels.

This would happen at least when lavr is used as a fifo with no
conversion.

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

This makes only tests actually using avconv depend on it.
The remaining tests already depend on what they need.
Signed-off-by: Mans Rullgard <mans@mansr.com>

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

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

Only the probe tests should depend on avprobe and these should
be enabled only if avprobe is configured.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Just like gcc 4.6 and later on ARM, gcc 4.8 on MIPS generates
inefficient code when a known-unaligned location is used as a
memory input operand.  This applies the same fix as has been
previously done to the ARM version of the code.
Signed-off-by: Mans Rullgard <mans@mansr.com>

GCC actually handles unaligned accesses correctly in all cases
except, absurdly, 32-bit loads on mips64.  The remaining asm is
thus not needed, and removing it results in better code.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Also add the public interface libavfilter/buffersink.h.

Based on a commit by Stefano Sabatini.

Based on a commit by Stefano Sabatini <stefano.sabatini-lala@poste.it>

Signed-off-by: Jordi Ortiz <nenjordi@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

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

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

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

libavcodec/utils.c:274: warning: passing argument 3 of ‘av_samples_fill_arrays’ discards qualifiers from pointer target type
./libavutil/samplefmt.h:151: note: expected ‘uint8_t *’ but argument is of type ‘const uint8_t *’

Unlike other variants, for YUY2 we need to use different prediction:
* on line 0 for luma we should left predict starting from the second pixel
* on line 1 we should left predict first 4 pixels for luma and 2 for chroma
* median prediction employed here is taken directly from HuffYUV