[MPlayer-dev-eng] possible bugs in vf_decimate filter

Trent Piepho xyzzy at speakeasy.org
Mon Oct 16 21:28:58 CEST 2006


On Sun, 15 Oct 2006, Loren Merritt wrote:
> On Sun, 15 Oct 2006, Rich Felker wrote:
> > On Sat, Oct 14, 2006 at 07:09:32AM -0700, Trent Piepho wrote:
> >> The decimate filter calculates 8x8 SADs over the image.  The loop that
> >> calls the SAD function increments x and y by 4 each time, rather than 8.
> >> This means all the pixels, except for the outer four, are included in four
> >> SAD calculations instead of one.
> >
> > This is intentional. Ideally it would increment by 1 each time, but
> > that would be much slower and not much more accurate. The idea is to
> > look for maximal change over _any_ 8x8 block, not just
> > aligned-to-8-pixels 8x8 blocks.
>
> OK, but it would be faster to calculate non-overlapping 4x4 blocks, and
> then add 4 adjacent block sums.

Possibly.  I wrote a faster version that used MMX2, which can compute the
SAD of 8 pixels in a single instruction.  If you wanted to do four pixel
blocks, you would have to use slower code.  Finding the SAD of four pixels
is actually slower than finding the SAD of eight.

Of course, one could do blocks of 4 rows of 8 pixels.  The image could be
processed in vertical strips, which would allow an efficient algorithm, but
poor cache use.



More information about the MPlayer-dev-eng mailing list