[FFmpeg-devel] [PATCH] api-example for libavfilter

Stefano Sabatini stefano.sabatini-lala
Sun Dec 12 17:56:14 CET 2010

On date Sunday 2010-12-12 17:21:36 +0100, Nicolas George encoded:
> Le decadi 20 frimaire, an CCXIX, Stefano Sabatini a ?crit?:
> > 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).
> I gathered as much, but your last parenthesised statement leaves the
> following question:
> What do we _want_: do we want this output-buffer sink, or do we want people
> who write applications to write their own sink each time?
> It we want the buffer sink, then I can try to make a proposal in a near
> future. If we want a dedicated sink in each application, I shall change the
> example in accordance.

If you want to dedicate some time on this that's definitively welcome,
I still don't consider it an high-priority (as I want to fix all the
various regressions). I suppose the cmdutils.c:ffsink and
get_filtered_video_frame() may be used as a base for creating such an

> > 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.
> Indeed, but not always. As a matter of fact, one of my purposes when writing
> this example is to learn enough about lavfi API to write the "-vf lavfi"
> option for mplayer.
> Unfortunately, I do not think that lavfi sinks will compare with mplayer
> libvo in any foreseeable future.

Can you elaborate on this?

Does it depend on architectural issues or is a problem of missing
components (which will eventually be implemented)?
> > 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).
> I do not think I quite understand what you mean here.

I mean that vsrc_buffer.c in the present form is not acceptable, we
should either make it a libavfilter-pure source (with no references to
lavc/lavf symbols), or turn it into something more similar to the
ffplay.c:input_filter, which allows direct rendering, or have both of
them (note that I already posted some patches for this).

> > 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.
> I agree with that; "doc/examples" would probably be a good place.
FFmpeg = Foolish and Funny Most Proud Ecletic Goblin

More information about the ffmpeg-devel mailing list