[FFmpeg-devel] [PATCH] api-example for libavfilter
Fri Dec 10 23:51:58 CET 2010
On date Wednesday 2010-12-08 20:37:44 +0100, Nicolas George encoded:
> L'octidi 18 frimaire, an CCXIX, Stefano Sabatini a ?crit?:
> > > +#include <stdio.h>
> > > +#include <stdlib.h>
> > > +#include <string.h>
> > > +#include <unistd.h>
> > These headers shouldn't be required.
> string.h was forgotten from a previous version.
> unistd.h is necessary for usleep, compilation breaks without it.
> stdio.h and stdlib.h are indirectly included by libav* headers, but AFAIK,
> that fact is not explicitly stated, and that could possibly change.
> > I'd prefer to avoid to rely on other FFmpeg libraries, currently lavfi
> > only depends on libavutil, libavcore and libswscale, and API example
> > should be minimal so should be as strict as possible in terms of
> > requirements.
> I think that illustrating how the filtering system interacts with the rest
> of the libraries is important: which time base should be used, how to insert
> an AVFrame in the system, etc.
> See libavformat/output-example.c: to give a complete working example, before
> outputing with libavformat, it scales with libswscale and encodes with
> > Also the code could be simpler if you implement it this
> > way... implement a video sink
> This is a point that I wanted clarified when I started writing this program:
> it seems that anyone who wants to use libavfilter is almost expected to
> write its own designated sink.
> Is it on purpose?
> Should there not be some kind of "buffer" sink just like there is a "buffer"
That may be possible, on the other hand such a sink is rather trivial
to write (check cmdutils.c:ffsink).
In general for integrating your application you need to write a source
(if you need to inject data) and a sink (if you need to pass it
filtered to the application), for the source you may use vsrc_buffer
and its interface in vsrc_buffer.h, for the sink we don't have nothing
of that kind yet (but may have in the future). Note that as the
library keeps adding functionality the need for injecting/extracting
data may decrease, for example you could implement a video player
simply connecting a movie source to a video display sink.
Also note that vsrc_buffer is quite generic so in the present form
doesn't allow the kind of strict integration which is possible in
ffplay.c (required for enabling direct rendering).
> > for printing to console a textual
> > representation of the image (which could be useful even in
> > libavfilter),
> Agreed, I will try to submit something like that sometime.
> But that will not do for an example, because an example needs to show how
> the main program is supposed to get the filtered data back from libavfilter.
> > and let the user specify the input for the input source
> > in the filtergraph description.
OK but I'm still thinking that having such example (using lavf API) in
libavfilter is a bit misleading, maybe would be better to have an
examples dir containing all the examples, rather than having them
scattered in the tree.
> As above: an API example needs to illustrate how the main program is
> supposed to inject the video/audio it has into libavfilter.
> (And at this time, video sources are rather scarce.)
> > you can use the log system (with the fancy coloring support).
> I think that a simple fprintf is more readable for this case.
I suggested this because I was thinking to implement that in ff*,
anyway this is bikeshed so do as you prefer.
> Anyway, I temporarily withdraw my patch: I forgot all cleanup code. I will
> submit again when it is done. But in the meantime, I am interested in
> clarifications on the previous points, especially the question of the sink.
FFmpeg = Fanciful and Funny Marvellous Pitiless Egregious Gymnast
More information about the ffmpeg-devel