[XviD-devel] [Future PATCH] I need testers for unified Makefile

Edouard Gomez xvid-devel@xvid.org
Mon, 3 Feb 2003 01:08:53 +0100


--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Christoph Lampert (chl@math.uni-bonn.de) wrote:
> On Sun, 2 Feb 2003, Edouard Gomez wrote:
>=20
> > Christoph Lampert (chl@math.uni-bonn.de) wrote:
> > > [...]
> > > checking size of int *... 4
> > > checking whether byte ordering is bigendian... yes
> > >=20
> > > Well done, GomGom, seems to work fine, except for the speeeeed (4 fps=
=2E..)
> >=20
> > well, 32bit targets are all working, but i fear 64bit target
> > (mips[lb]64, alpha or ia64) may experience problems with bitstream
> > functions.
>=20
> That was MIPS R5000 which has 64bit registers, but I guess since int-size
> is 32, it behaves just like ordinary 32bit.=20

The architecture size is for the address bus, so we make sure ptr_t is
the right size for the platform. I get the same 32/64 bit ambiguity on
sparc64 which is a 64bit processor (both data registers and address bus)
but for some obvious reason, gcc generates only 32bit mode code. So gcc
reports sizeof(int *) =3D=3D 4 the same way it did for your MIPS R5000.

> I tried again with -DARCH_IS_64BIT  and it did compile and also didn't
> crash, but there were compiler warnings of the type=20
>=20
> ../../src/encoder.c:887: warning: cast from pointer to integer of
> different size
>=20

That is the ptr_t being wrong. You have just misunderstood what
ARCH_IS_32/64BIT was meaning.

> for "DECLARE_ALIGNED_MATRIX" and what is strangest: cactus test was=20
> much smaller filesize at much higher PSNR!=20
>=20
> So maybe there's something wrong with image conversion already?=20
>=20
>=20
>=20
>=20
> bash-2.05a$ bzcat cactus.pgm.bz2 | ./xvid_stat -m 1
> xvid_stat - XviD core library test program written by Christoph Lampert
> 2002
>=20
> Trying to retreive width and height from PGM header
> Frame     0: intra 1, enctime=3D 126.9 ms, size=3D  3119 bytes dectime =
=3D  76.3
> ms PSNR 40.74
> Frame     1: intra 0, enctime=3D 295.7 ms, size=3D   344 bytes dectime =
=3D  26.2
> ms PSNR 41.21
> Frame     2: intra 0, enctime=3D 268.5 ms, size=3D   811 bytes dectime =
=3D  38.8
> ms PSNR 42.47
> Avg. Q6 br 0900 ( 0.43 bpp) size   1424 (  284 kbps / 0.13
> bpp) enc:    4.3 fps, dec:   21.2 fps
> PSNR P(2): 41.84 ( 41.21 , 42.47 ; 0.3650 ) I(1): 40.74 ( 40.74 , 40.74
> ; 0.0000 )

I got exactly the same results with the alpha target... so something is
wrong when activating 64bit. Perhaps ptr_t is used where it should not
be used. I'll have a look tomorrow. I'll also try to see if i find some
new sparc machine in my shool (i know we have old sparcs, but i'm sure
they bought some new SUN workstations last year)

--=20
Edouard Gomez

--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+PbMUR5dTYz5sWMcRArznAKC1L+tvNwiNxZHY0ZCK77wdljd3bwCcCt0T
DH/tAmvzzuwlOU9Ibz1hA9Q=
=UuMW
-----END PGP SIGNATURE-----

--wRRV7LY7NUeQGEoC--