Re: [xine-devel] [PATCH] Real codecs FAQ update

[Diego B. <di...@bi...>]

Franti=B9ek Dvo=F8=E1k writes:
>=20
> V P=E1, 17. 09. 2004 v 16:44, Diego Biurrun p=ED=A1e:
> >=20
> > Since you are about to make a releae I thought I'd drop by and send=

> > you this patch.  I noticed some time ago that you advise installing=

> > RealPlayer to get Real files working.  It's not necessary to instal=
l a
> > proprietary bloatware application to do this, grabbing our codec
> > packages does the trick as well.  Since you already instruct people=
 to
> > download them from the MPlayer homepage to get QuickTime and Window=
s
> > Media files working, you might as well do so for Real.
>=20
> Wouldn't be better to have two separate packagaes for the codecs=3F

There are several different codec packages, just look at our codecs
page:

http://mplayerhq.hu/homepage/design7/codecs.html

> One placed into /usr/lib/win32 and second to /usr/lib/realplay, for
> example=3F  It's isn't too clear mixture x86 32-bit Windows libraries=

> with Linux binary shared libraries for various platforms into one
> /usr/lib/win32 directory, IMHO.

In MPlayer we have deprecated /usr/[local/]lib/win32 and switched to
/usr/[local/]/lib/codecs instead.

I wanted to suggest in another mail that xine follow this standard as
well some day, but since it has come up, we might as well discuss this
now.

I don't think /usr/lib/realplay makes much sense, you could as well
create /usr/lib/xanim and /usr/lib/quicktime (under PPC at least) then
and another directory for each vendor that starts releasing codecs for
Linux.  Besides Real support is available via the Linux .so as well as
the Windows DLLs (at least in MPlayer, haven't tested with xine).
There are some platforms where the Real DLLs have to be used (Cygwin,
MinGW), there are some that support both (e.g. Linux x86).

Loading everything from one directory simplifies things enormously,
but since this directory may contain native as well as non-native
codecs the name win32 is misleading.

For the reasons outlined above I suggest you switch the default codec
location to /usr/lib/codecs.  This should simplify sharing some common
infrastructure.  You can always put some backwards compatibility in
place.  I will talk to the vlc people next.

> > The attached patch accomplishes that and corrects the codec package=

> > names in addition to a few spelling and link updates.
>=20
> Yes, nice.
>=20
> I think we can just mention the "essential" codec package without
> dropping information about the bloat-wares.

OK, so will somebody apply the patch=3F

Mike=3F  This is what we talked about at SUCON ;-)

Diego