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

[Michael Niedermayer]

Hi

On Wed, Mar 28, 2007 at 12:11:25AM -0400, Rich Felker wrote:
> On Wed, Mar 28, 2007 at 08:51:48AM +0900, Bobby Bingham wrote:
> > Rich Felker wrote:
> > >I won't block efforts to support libmpcodecs. But if there's a SoC
> > >project I wish it could lead in a new direction.. Maybe that's just
> > >wishful thinking. I will not be around to aid in SoC mentoring but I
> > >could write up and leave my notes for others to examine.
> > >
> > 
> > I've been hoping to work on a filter system for SoC, so I'd be very 
> > interested to see any such notes.  Especially any part the points out 
> > specific problems with the current libmpcodecs design and suggestions 
> > for improvements.
> 
> /*
> 
> 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..):
> 
> 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...
> 
> 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.
> 
> A picture filter would just define a function (or functions) to
> operate upon rectangular pixel arrays, in a set of supported image
> formats (packed/planar/yuv/rgb/etc.). Optionally it could provide
> separate functions for aligned and unaligned locations, and the filter
> layer would automatically call the unaligned functions for boundary
> pixels while using the optimized aligned functions (if available) for
> most of the picture. These functions could also be called on
> individual slices.
> 
> If the picture filter needs context of surrounding pixels (not just
> the source rectangle), it would provide the caller an amount of needed
> context, and the caller (the filtering engine) would ensure that this
> much context was always available. The caller would be responsible (is
> this a good idea?) for generating fake context at the boundaries of
> the image in this case.

i do not know if this is a good idea, or if this is just "we know how its
done currently sucks and we dont know if a radical different design
sucks less..." or in other words existing filters tend to support dealing
with picture boundaries somehow already and in general they do so with
no performance loss. providing extra context and for many fiters that
might be MANY pixels of context might have some negative performance
effect also what do you put in this extra context pixels? many filters
will not work correctly if thats random or black pixels and i dont see
how you want to do boundary mirroring efficiently especially in
combination with direct rendering this is likely to become fairly complex


> 
> So far I've been thinking of a one-to-one correspondence between input
> and output pixels, i.e. nothing like scaling. How to make this idea
> work well with scaling is a bit of a research question.

the swscaler works with normal horizontal slices ordered top to bottom
and it does so efficiently with zero memcpy with the current libmpcodecs
design, extra context would not help it, even if its rewriten i dont see
how extra context would do any good, the swscaler scales horizontally
first into a temporary buffer then vertically from that, so if it
had vertical context that would do no good
one or 2 of the special converters in the swcaler might benefit maybe
or maybe not but i think the advantages are tiny if at all

and last i think this local filter stuff is independant of the actual
filter system, it can easily be added on top of any filter system and
its the filter system we need first the localized wraper can be designed
and added after the actal filter system is in place and working

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

you cheat ;)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070328/95efd442/attachment.pgp>