[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