[FFmpeg-devel] [PATCH] api-example for libavfilter
Sun Dec 12 17:21:36 CET 2010
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
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.
> 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.
> 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.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel