[Ffmpeg-devel] Embedded preview vhook/voutfb.so /dev/fb

Bobby Bingham uhmmmm
Fri Mar 30 08:07:12 CEST 2007

On 3/28/07, Rich Felker <dalias at aerifal.cx> wrote:
> /*
> OK, the super-quick explanation of the design is that there would be 2
> classes of filters, each subdivided into subclasses (class is just an
> english word here, no C++ connotation..):

Of course.  I get the impression we have very much the same feelings about C++.

> 1. picture filters. these act on individual pictures and have no
> knowledge or care that the pictures are a sequence of frames in a
> movie; in fact; they could just as easily be used as still picture
> filters in a photo viewer or in gimp...

Or allow for a wrapper to use gimp filters (as slow as many of them
are) on video ;)

> 2. picture sequence filters. these are aware of processing frame
> sequences.. things like pts, order, neighboring frames, etc. no need
> for one-to-one correspondence between input and output frames even.
> The division allows the calling filter system to be very clever if it
> wants to. Picture filters don't need to process frames in order, so
> they could operate in decode order during out-of-order decoding,
> maximizing performance.


> Now, on to picture sequence filters....
> These would be similar to picture filters, but also have an amount of
> necessary 'context' along the time axis, i.e. a number of past and
> future frames that need to be available in order for the filter to
> operate. Again, what to do when the in/out correspondence isn't
> one-to-one is a little tricky. Perhaps mimic the way scaling ends up
> working along the spatial axes...

Is there any reason the picture filters can't just be a picture
sequence filter with temporal context = 0?


> */
> Rich
> P.S. Note that, upon Michael's special request, my notes have been
> delivered in C form. :)))))))))))


Bobby Bingham

More information about the ffmpeg-devel mailing list