[XviD-devel] EDGE_SIZE == 64

[Jim Hauxwell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gruel,

Check out table B-12 in the spec.

its for the out of bounds motion vectors.  It makes the calculation easier.
The edge size is 64 as we can go -16 to +16 in half pel units therefore
needing 32bytes at each side of the image of replicated edge data.

The other section which I think is relevant here is 7.6.4 unrestricted
motion compensation as xvid is only 1 VOP per screen the conditions apply to
out of VOP motion vectors.

Jim

> -----Original Message-----
> From: xvid-devel-bounces at xvid.org [mailto:xvid-devel-bounces at xvid.org]On
> Behalf Of Christoph Lampert
> Sent: 09 March 2003 16:45
> To: xvid-devel at xvid.org
> Subject: [XviD-devel] EDGE_SIZE == 64
>
>
>
> Hi,
>
> 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?
>
> If it's just to align lumi and chroma at same stride, then at least the
> extra pixels should not be processed during image_setedges.
>
> Second question: Image interpolate has
>
> const uint32_t offset = EDGE_SIZE2 * (edged_width + 1);
> // we only interpolate half of the edge area
>
> Why do we interpolate edged area at all? In Halfpel mode, two of four
> edges will be constant anyway (vertical at top and bottom, horizontal at
> left and right) and the others will just contain copies of the boundary
> row/column again, so a memcpy call (like setedges) would be sufficient.
>
> gruel
>
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPmuyDypQmIptkMWREQKiBQCfQDeuQvQdSwY6lgD1gXIxu+u7WvsAnRl9
FJ6iluKgXaJbRiqKEDdUQdZR
=tnWv
-----END PGP SIGNATURE-----