[XviD-devel] bframes and qpel

[Michael Militzer]

Hi,

> I already started implementing qpel support to bframes. Is anyone
> working on it? If not, don't start :>

yes I'm (was) working on it...

> I have motion estimation for forward, backward and interpolate search
> ready. I'll make motion compensation soon. Also direct search
> shouldn't be a problem, all I'll have to do is discover a method to
> move a dimond in non-qpel positions, because it's going to be
> incredibly slow otherwise.

I also have forward, backward and interpolate ME ready, but direct mode was
a real pain in the a** - at least for me, because I tried not to change
anything for the halfpel search... I tried to round qpel MVs down to
halfpel, do a normal delta MV search and then refine again to qpel. Also I
have working motion compensation code for qpel + forward, backward,
interpolate and direct_no_mv. I have also added full qpel+bframes decoding
support...

I think we should combine our efforts.

> Btw, the entire thing is, of course, very slow. I'll experiment on
> using sad-bi to do the checks, instead of performing interpolation to
> temporary memory first.
> If someone is interested in writing some asm, I'll recommend:
>  - sad8bi2/sad16bi2 with different rounding then current (I don't know
> how important it is)
>  - 16x16 halfpel interpolation for halfpel positions in forward and
> backward search (and interpolate?). If you remember, interpolation
> should _not_ be done on 8x8 blocks in this case. You might combine it
> with 8to16sub for speed.
>  -  8x8 SAD which accepts FOUR sources - hv-interpolation combined with
> sad. Will also be used for faster chroma ME. Correct rounding would be
> nice.

I don't think that speed is that much important right now. Let's first
create a working implementation, then let's see what kind of implementation
would be good in combination with other features (I think I remember that
someone mentioned GMC would be fastest with image based interpolation in
qpel mode?) and finally we should refine our code (well, the dev-api-3 tree
is pretty messy right now...)

> OK, that would be it. Ah, one more thing: is there _again_ something
> wrong with chroma channels in qpel encoding? not shift this time, but
> colors get... strange in ffdshow. mostly visible at keyframes, when
> they suddenly go correct again. I use this new, 3 days old ffdshow.

?? don't know about this. I didn't change anything about qpel rounding and
last time a checked, everything seemed fine (at least with MS-FDAM)

bye,
Michael