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

[Bobby Bingham]

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.
>

[snip]

> 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?

[snip]

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

;)

-- 
Bobby Bingham
?????????????????????