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

[Michael Niedermayer]

Hi

On Wed, Mar 28, 2007 at 12:16:02PM -0400, Rich Felker wrote:
[...]
> > 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
> 
> with this design, swscaler could be factored into a separate
> horizontal scaler and vertical scaler with no performance loss, as
> long as the calling filter engine setup the right temporary buffer
> between them. it would also be able to operate on any regions of the
> image in any order, not just top-to-bottom or bottom-to-top full-width
> slices. i think that's a pretty compelling argument in favor of an api
> like this, even if swscaler wouldn't take advantage of it now (or
> ever), just the fact that you _can_ do stuff like this..

one thing which seems to not have been mentioned yet is that the scaling
operation for lets say line 5 is not the same as for line 6, scaling 
501 lines to 500 shows that nicely for example, so a scale filter needs
to know and deal with its position

also the number of lines of context for luma and chroma can differ, or
it can be the same but the space which they cover can differ, that is
if we seriously would want to split swscale into horizontal and vertical
filters such things must be supported, inside sws this is trivial iam not
sure how nice that would be outside
having a ring buffer with more lines than needed is bad due to caching
issues

lets consider a few other filters
wavelets while they are local differ from even and odd pixels, also
practial implementations perform several passes over the image and
each pass will generally be done as several lifting step that is
the data will be written to and read a few times
i cani imagine how to do both libmpcodec slice input and output
but random order fails also output together with extra context seems
tricky, i mean we should reuse the lines as soon as possible to
improve cacheing but here our filter needs to know how much context
the next filter needs

box blur and similar filters are trivial to implement with
libmpcodec slices, but they need slices to be in a sensible order

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- 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/9b20b9bc/attachment.pgp>