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>

Right now it incorrectly assumes that the frames are sent in the proper
order, which worked with old ffmpeg and avconv versions by accident.

Output frames correspond 1:1 to input frames on the main input.
So use the main input timebase for output.

They were only roughly adapted when error return was
added to the push functions.

This allows the iteration callbacks to discover the internal class and
options, and show them when required.

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

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

Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

A reference is kept in the queue and freed after use.

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

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

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.

The macro can be used to define consistently the internal class of a
filter, save some typing and factorize.

While here:
    - add missing .version and .category,
    - make .class_name consistent across filters,
    - align declarations.

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

They are only useful inside filters and we don't allow user filters for
now.

They are only useful inside filters and we don't allow user filters for
now.

It is only useful inside filters and we don't allow user filters for
now.

avfilter_default_filter_name() is supposed to access an AVFilterContext
struct, if used with a private struct it will cause a crash since it will
access fields which are non defined in the private struct.

The function is modelled after av_default_item_name(), and will print the
name of the instance filter if defined, otherwise the name of the filter.

This allows to show the instance name in the log, which is useful when
debugging complex filter graphs.

The old implementation, upon receiving a frame on the main
input, would request an overlay frame if necessary. This could
generate an infinite recursion, off-by-one frame mismatch and
other harmful effects, especially it the split filter is present
upgraph.

The new implementation uses the linear approach: it uses two
buffer queues for frames received out of turn and forwards
request_frame calls to the input where a frame is necessary.

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.

Also add debug logging messages for helping tracking down similar
issues.

Fix trac ticket #467.

GCC 4.6.2 at least still seems to fail to put them in .rodata though,
see also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37303

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Ease readability, improve exactness.

Based on the work of Mark Himsley <mark@mdsh.com>.

See thread:
Subject: [FFmpeg-devel] libavfilter: extending overlay filter
Date: Sun, 13 Mar 2011 14:18:42 +0000

Add option rgb which forces the RGB path.

Extend syntax, allow to easily add more options later.

Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

Done to keep ABI compatible. Otherwise this is just silly

It is pretty hopeless that other considerable projects will adopt
libavutil alone in other projects. Projects that need small footprint
are better off with more specialized libraries such as gnulib or rather
just copy the necessary parts that they need. With this in mind, nobody
is helped by having libavutil and libavcore split. In order to ease
maintenance inside and around FFmpeg and to reduce confusion where to
put common code, avcore's functionality is merged (back) to avutil.

Signed-off-by: Reinhard Tartler <siretart@tauware.de>