[FFmpeg-devel] [PATCH] lavfi: document filter design subtleties.

Michael Niedermayer michaelni at gmx.at
Thu May 10 16:34:05 CEST 2012


On Wed, May 09, 2012 at 08:27:57PM +0200, Nicolas George wrote:
> The details on reference ownership and permissions are missing.
> 
> Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
> ---
>  doc/filter_design.txt  |  121 ++++++++++++++++++++++++++++++++++++++++++++++++
>  libavfilter/avfilter.h |    2 +
>  2 files changed, 123 insertions(+)
>  create mode 100644 doc/filter_design.txt
> 
> diff --git a/doc/filter_design.txt b/doc/filter_design.txt
> new file mode 100644
> index 0000000..67dcb4b
> --- /dev/null
> +++ b/doc/filter_design.txt
> @@ -0,0 +1,121 @@
> +Filter design
> +=============
> +
> +This document explains guidelines that should be observed (or ignored with
> +good reason) when writing filters for libavfilter.
> +
> +In this document, the word “frame” indicates either a video frame or a group
> +of audio samples, as stored in an AVFilterBuffer structure.
> +
> +
> +Format negociation
> +==================
> +
> +  The query_formats method should set, for each input and each output links,
> +  the list supported formats.
> +
> +  For video links, that means pixel format. For audio links, that means
> +  channel layout, sample format and sample packing.
> +
> +  The lists are not just lists, they are references to shared objects. When
> +  the negociation mechanism computes the intersection of the formats
> +  supported at each ends of a link, all references to both lists are
> +  replaced with a reference to the intersection. And when a single format is
> +  eventually chosen for a link amongst the remaining list, again, all
> +  references to the list are updated.
> +
> +  That means that if a filter requires that its input and output have the
> +  same format amongst a supported list, all it have to do is use a reference
> +  to the same list of formats.
> +

> +  A more complex dependency can not currently be expressed. Any suggestion
> +  of an elegant solution would be appreciated. Currently, the amerge filter
> +  is the only one with such a dependency, and it uses the first format
> +  supported by the other end of its inputs, which has a lot of drawbacks but
> +  works in simple cases.

not sure this "work in progress" note belongs in here

rest LGTM

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120510/729b0309/attachment.asc>


More information about the ffmpeg-devel mailing list