[Ffmpeg-devel] [PATCH] Snow mc_block mmx optimization

[Oded Shimon]

On Sun, Mar 26, 2006 at 11:13:37PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Mar 26, 2006 at 10:24:05PM +0200, Oded Shimon wrote:
> > On Sun, Mar 26, 2006 at 09:48:41PM +0200, Michael Niedermayer wrote:
> > > On Sun, Mar 26, 2006 at 03:10:17PM +0200, Oded Shimon wrote:
> > > > Ping.
> > > 
> > > pong
> > 
> > pin... missed! lost the ball.. damnit, I lose...
> > 
> > > after more carefull review of this iam not so sure anymore if its a good idea
> > > 
> > > * doesnt this change 1/2 pel (no qpel) encoding?
> > 
> > I don't see how, mc_block has the exact same behavior. From what I could 
> > figure from RTFS, dx and dy are always 0<=d<=15, and always even. I just 
> > tested out another odd resolution video (364x241), md5sum still match.
> 
> s->dsp.put_pixels_tab isnt initalized anymore so there should be a difference
> with the "correct" parameters (EPZS ME no qpel subcmp!=0)

I asked Loren about this, he said all those were obsolete. I also planned 
to send a snow cleanup patch which removes the other function initialized 
about that (among other nonsense).

> > BTW, widths that divide by 4 now do work for me, but anything less still 
> > gives
> > mencoder: snow.c:2438: pred_block: Assertion `b_w>1 && b_h>1' failed.
> > I'm not sure why only widths that divide by 8 worked for me earlier, maybe 
> > I was using out of date cvs. This is up to date to yesterday night though.
> > 
> > BTW2, can 'assert(!(b_w&3))' ever fail in mc_block ? If not, I can remove 
> > the C code duplication in the mmx functions... I know b_h was still 
> > divisable by 8 in this odd res video. Can't know about b_w cause encoding 
> > doesn't work...
> > 
> > > * currently we have 2 different MC variants, 1. the h.264 case for 1/4 pel
> > >   and our own for 1/8 pel, i really disslike this, we should attempt to
> > >   find a more unified method
> > 
> > I'm generally clueless about this, either way, my MMX still stands and I 
> > would like it committed as it's the last piece missing for me to play a 
> > 944x544 snow file smoothly... Even the C code is significantly faster...
> 
> first comes the spec/algo then comes the optimiation
> 
> whats the speed & PSNR/bitrate of the common test videos like forman if we
> would always use the mc_block() code and never the h.264 code?

No idea. How do I test this, remove all if's there and use mc_block ?

- ods15