Based on a patch by Mina Nagy Zaki <mnzaki@gmail.com>

It's the same as av_vsrc_buffer_add_frame(), except it doesn't take pts
or pixel_aspect parameters. Those are read from AVFrame.

Deprecate av_vsrc_buffer_add_frame().

Most of the code will be shared for both audio and video version.

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

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

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>

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.

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>

A nontrivial public function such as this should most certainly NOT be
inline.

This fixes a double-free crash if lists are the same due to the two
merge_ref() calls at the end of the (useless) merging that happens.

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

The function is not implemented (and possibly useless).

The scale filter is used for internal colorspace conversions, so it must
always be present.

This is not an erroneous condition, do not print a warning.

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

Prevents it from referring to the rest of the list.

The user submitted variable in this function is frame, not buf.

This is required for letting applications to create and destroy
AVFilterInOut structs in a convenient way.

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

Right now, e.g. scale,[in]overlay would connect scale to the first
overlay input and [in] to the second, which goes against the
documentation and is unintuitive.

The bug happens because of the ordering mess in curr_inputs variable:
1) the unlabeled links from the previous filter are added to it in
correct order
2) input labels are parsed and inserted to the beginning one by one
(i.e. in reverse order)
3) curr_inputs is matched against filter inputs in reverse order

Fix the problem by always using proper ordering without trying to be
clever.

Unlike avfilter_graph_parse(), it returns unlinked inputs and outputs
to the caller, which allows parsing of graphs where inputs/outputs are
not known in advance.

Signal that it can output a frame when there are frames on the main
input and EOF on the overlay input, but a frame is buffered -- e.g.
single picture overlay.

This fixes the following warning:
libavfilter/vf_unsharp.c:106: warning: initialization discards qualifiers from pointer target type

I.e. just pass the buffer along when src parameters == dst parameters.