[FFmpeg-devel] Writing filters

[Michael Niedermayer]

On Wed, Jun 11, 2014 at 03:02:46PM +0200, James Darnley wrote:
> While I appreciate the effort someone put into doc/writing_filters.txt
> it still doesn't go far enough for me to understand enough for what I
> want to do, namely an A->V filter.
> 
> It (doc/writing_filters.txt) is based on a one-in-one-out video filter
> (edgedetect) so it doesn't need to explain some of the more
> "interesting" functions.  It only has to explain filter_frame which, I
> think, is fairly simple in concept: it is called by the previous filter
> and itself calls the next filter's filter_frame, indirectly though
> ff_filter_frame (I think).
> 
> While looking at some of the vsrc and other avf filters, I see that some
> use filter_frame, some use request_frame, and some use both.
> 
> I believe request frame works in the other direction: it gets called
> from the next filter, does whatever it needs to and then "returns".  I'm
> sure you can see that I don't understand this quite as well.  Its use in
> mandelbrot is obvious, it draws the picture then calls ff_filter_frame
> to send the image along the chain.
> 
> What I don't understand is: why some filters use both; how they use both
> and how data gets from the input to the output; and when I (or another
> user) should use both.
> 
> I see that request_frame in showwaves and showspectrum run request_frame
> in a loop until "something" happens (they actually set a var in their
> context) but, their flow is obscured by an inline push_frame function
> which calls ff_filter_frame.  This looks like it should result in the
> same frame going to the next filter twice over.
> 
> What adds to my confusion is that avectorscope doesn't use both, it uses
> only filter_frame.
> 
> I guess my ultimate questions are:
> 
> Is my understanding how filter_frame and request_frame correct?
> 
> If necessary, can someone explain in more detail the difference between
> filter_frame and request_frame?

request_frame() does exactly what its name suggests, it requests a
frame
so a "downstream" flter calls it if that downstream filter wants to
get something to call its filter_frame with the next frame

If you consider a larger filter network, the user application can
run request_frame on an output to get a frame out.
(it might do that when it is low on frames in some fifo between
the filters and some display thread for example)

The filter network will then have the request_frame calls "travel"
backward and cause request(s) from whichever inputs need more data
and the user app can then pull that data from the respective file(s)
and inject them via filter_frame() in the other direction

Without a system like this an application wouldnt exactly know when it
has multiple inputs, on which data is needed and on which data is
not needed and would just end up having to be buffered with no
usefull output



> 
> Why do some filters, particularly showwaves and showspectrum, use both
> filter_frame and request_frame?  Why does avectorscope not?

theres a default request_frame, if that works for your filter you
dont need to "override" it by writing one

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140611/88f9ce50/attachment.asc>