[XviD-devel] rrv en/decoding

suxen_drol xvid-devel@xvid.org
Wed, 11 Dec 2002 21:41:06 +1100


On Wed, 11 Dec 2002 20:47:03 +1030 Radek Czyz <radoslaw@syskin.cjb.net> wrote:

> >> * motion estimation needs modification to support rrv. current the
> >> encoder uses the halfpel mv's, which are non-optimal. we need to perform a
> >> sad 32x32 and 16x16 search, and scaleup the vectors. is anyone willing
> >> to help out here, or give me some "pointers"?
> 
> > Sure, I can do that.
> > I'll just download the code and see what's it all about. If I won't
> > understand anything, I'll ask.
> 
> OK that was easy. Done.
> However, I noticed that something _really_ bad happened to
> inter4v-mode encoding recenly. With current CVS, I have artifacts in
> every possible mode (rr, normal, qpel..). It looks like motion
> compensation problem... Not ME, I checked it 20 times already.

yep i introduced a motion_comp bug, being fixed _right now_
> 
> Skal wrote
> >        arghh... seems serious rrv enc is not that easy.
> >        I'm sorry i can't give a help right now :(
> 
> It's not? Well I can't confirm if my bitstreams are compatible with
> anything but xvid... ffdshow doesn't even try to decode reduced
> resolution.

its fairly straight forward skal; i think writing the filters was the
hardest part.
> 
> OK, I just checked that there is no new code in CVS since my
> yesterday's check. I'm clear to commit.

sure.
> 
> Best regards,
> Radek
> 
> PS: supporting rr-p-vops together with b-vops is going to be a
> problem... How does it work? Do we make 4 new macroblocks out of every
> RR-macroblock? Creating a 'correct' macroblock structure will be
> important for direct mode (but we also have to look out for any
> mode_not_coded in P-vop).

and its gets even more complex/wierd when you consider a sequence where 
the reference frame is rr, but the bframe is not rr (..or vice versa).
sadly, rrv+bvops is not defined in the mpeg-4 standard.

-- pete; life is like a box of ammo