[XviD-devel] Fcode

Christoph Lampert chl at math.uni-bonn.de
Wed Oct 29 12:01:02 CET 2003


On Wed, 29 Oct 2003, Radek Czyz wrote:
> Now, I have some questions. I hope you can answer them.
> 1. (@gruel probably) fcode seems to be used in GME, but I'm not sure
> how. Does it limit warp range? 

If I remember correctly, only GMC's average motion vectors are clipped to
the MV range determined by fcode. 

In estimation, fcode value is just needed to determine the number of 
motion vector bits, jsut as in block motion search.
But of course, it's not worth repeating search only if fcode changes a
little, and lowering fcode afterwards can only have positive effects
on bitrate. 

> Do I have to check warp info before I can say that we can encode a
> frame with lower fcode after all?

You might have to check average motion vector for all blocks with
mcsel==1 just as you check block motion vectors. 
Apart from that: no idea. I'd suggest to simply disable GMC all the
time ;-)

> 2. we are guessing the correct fcode by calculating RMS of *coded*
> vectors in a frame. Question is, why coded (real - pred)?? Fcode
> limits the *real* vector range. 

I guess because the reason for lowering fcode is to save bits. The larger 
fcode, more bits are needed to encode the differential MVs, and the longer
the differential MVs, the worse this effect becomes. 

Hm, thinking about it, this argument is weak. Maybe it's just a bug or
rather missing feature, because IIRC fcode code is really old.


> 3. Why fcode can't be 1 with qpel?? It works very well, and 1 is often
> used if given a chance.

MPEG-4 allows it, maybe it's also a relict in XVID, because Qpel fcode is
just Hpel+1.   

> I wrote some new fcode stuff, but it's another piece of code waiting
> for after-1.0 xvid :)

;-)  Oh, how long have I waited for anyone to say that. Thanks!
Let's release! and then start with many new features and even more new
bugs ;-) 


gruel




More information about the XviD-devel mailing list