[x264-devel] Re: [PATCH] Altivec optimizations for quant4x4, quant4x4dc, quant8x8, sub8x8_dct8, sub16x16_dct8, pixel_sa8d_8x8, pixel_sa8d_16x16, *idct8*

[Guillaume POIRIER]

Hi,

On 10/2/06, Loren Merritt <lorenm at u.washington.edu> wrote:

[..]

> checkasm is just testing that the two strides are different, and that pix2
> is unaligned. I didn't think about mod16 when I coded that. This case
> should be gone now.

Right. I saw that in your latest commit.


> >> sad, satd, and sa8d can all be optimized for:
> >> pix1 is aligned to whatever the block size is.
> >> pix2 is unaligned.
> >
> > unaligned, as in: _any_ alignment, or as in "sometimes 8 or 16 bytes aligned?
> > Also, aren't alignment patterns different for sad, satd, and sa8d?
> >
> >> Additionally, in the current usage of sa8d, pix2 is also aligned to the
> >> blocksize. But don't count on that remaining so.
> >
> > Ah crap! What kind of alignment should I assume in the future? No alignment,
> > or 4, 8, ... bytes aligned?
>
> sad, satd, sa8d should all assume pix2 is only a multiple of 1.
> Yes, the fraction of calls that happen to have aligned pix2 is different
> between the functions, so it may be useful to have separate aligned
> versions of some of them.

That seems reasonable.


> The application I have in mind that needs unaligned sa8d is: predict
> whether the current macroblock will use 8x8 vs 4x4 dct, and if the guess
> is 8x8 then use sa8d instead of satd in motion estimation.

Ok. In other words, current implementation of sa8d _happens_ to be fed
with simple alignment and strides, but you plan to add/modify the
motion estimation pass in which sa8d won't be blessed with these
simple alignments/strides, right?
(yes, I'm trying to repeat what you said with my own words to make
sure I understood correctly).


By any chance, do you know the options that I should pass to x264 that
would allow me to test all strides and alignments in a real world
encode? (activating all options being both overkill and slow).

I've got another question: if ever the computation returned by either
one of SAD, SATD, SA8D is incorrect, that doesn't mean that the
resulting picture will be corrupted, right? This would just lead to
incorrect motion estimation and therefore sub-optimal compression,
right?

All these questions may seem trivial, but I really don't know anything
about video encoding internals....

Guillaume
-- 
I don't know what you could say about a day in which you have seen
four beautiful sunsets.
 -- John Glenn

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html