[XviD-devel] EDGE_SIZE == 64

[Christoph Lampert]

On Mon, 10 Mar 2003, suxen_drol wrote:

> 
> On Sun, 9 Mar 2003 17:44:57 +0100 (CET) Christoph Lampert <chl at math.uni-bonn.de> wrote:
> 
> > I'm sure this was asked before, but: Why is EDGE_SIZE defined 
> > as 64 in image/image.h? That's far beyond what is needed for
> > unrestricted motion vectors. 16 should be sufficient for this, or not? 
> 
> 
> EDGE_SIZE was originally set to 32 because we need an additional 16
> pixels on each side of the image for unresticted mvs.
> EDGE_SIZE reflects 16+16. EDGE_SIZE2 reflects 16.

I thought so, too, but it's not used that way:   encoder.c 

pEnc->mbParam.edged_width = 16 * pEnc->mbParam.mb_width + 2*EDGE_SIZE;
pEnc->mbParam.edged_height = 16 * pEnc->mbParam.mb_height + 2*EDGE_SIZE;

so it's EDGE_SIZE pixels on each side, not EDGE_SIZE in total and  
EDGE_SIZE2 per side. 

At the moment, a 320x240 image is stored at 448x368 which is 
almost twice the original mem needed. 

> EDGE_SIZE was increased to 64 to accomdate quarterpel. qpel filters may
> need to access upto 3 pixels (i think...) outside the unrestricted range.
> 
> notes:
> * we could use 48 instead of 64, and still maintain 16-byte stride alignment
> * we dont need to setedges the entire EDGE_SIZE, only the 16+3 pixels
> per side. 

I don't care much about the exact value of EDGE_SIZE, I even though about
making edged_width always a power of 2 or something, or better, a
constant value of 2048. But then image_setedges() and image_interpolate() 
should not use this constant, but only what the specs say has to be
available for MVs, and that's only 16 per side (in halfpel), or 16+3 in
qpel. 

P.S. Radical approach: How common _are_ unrestrictred MVs on all four
sides? We check motion vectors for fcode bounds anyway. We could check for
image bounds instead and e.g. implement a lazy setedges() routine. 
_If_ a position outside is needed, we'll setedge the margin, otherwise we
don't. 

gruel