The -20050412 and -20050216 versions of media-libs/win32codecs don't include the sipr3260.dll file. Some RealMedia files cannot be played with mplayer due to this. For example, try downloading http://www.sr.se/laddahem/ekot/nyheter/p3eko22.rm which is a 3 minutes news broadcast (in Swedish) and using mplayer to play the .rm file. My workaround is to download http://www.mplayerhq.hu/MPlayer/releases/codecs/windows-all-20050412.zip, unzip the archive and manually move the sipr3260.dll to /usr/lib/win32. My mplayer version is -1.0_pre7-r1. My emerge --info is Gentoo Base System version 1.6.13 Portage 2.0.53_rc7 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Pentium III (Coppermine) dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.10 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-pipe -O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-pipe -O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.pudas.net/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acpi alsa arts audiofile avi berkdb bitmap-fonts bzip2 crypt cups curl eds emboss encode esd ethereal exif expat fam flac foomaticdb fortran gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 idn imlib ipv6 java jpeg junit kde lcms libg++ libwww mad mikmod mmx mng motif mozilla moznoxft mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pcre pdflib perl png python qt quicktime readline real sdl spell ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts udev vorbis win32codecs xine xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
Sorry, this needs to be requested/fixed upstream; we just unpack and copy the files.
I agree that there seems to be confusion over at the MPlayer website. For the 20050412 release I have found that there are two different archives, namely (A) http://www1.mplayerhq.hu/MPlayer/releases/codecs/all-20050412.tar.bz2 (B) http://www.mplayerhq.hu/MPlayer/releases/codecs/windows-all-20050412.zip By unpacking and comparing one finds that most of the codecs are identical. However, some codecs are only in A and some are only in B. Those that are only in B are Only in windows-all-20050412/: atrc3260.dll Only in windows-all-20050412/: cook3260.dll Only in windows-all-20050412/: drv23260.dll Only in windows-all-20050412/: drv33260.dll Only in windows-all-20050412/: drv43260.dll Only in windows-all-20050412/: pncrt.dll Only in windows-all-20050412/: sipr3260.dll Only in windows-all-20050412/: tokr3260.dll notably including sipr3260.dll which was missing on my system. I guess there are three ways that the "missing sipr3260.dll" problem could be fixed: 1. Point out the state of things to the maintainers of MPlayer and hope that they put together a more complete http://www1.mplayerhq.hu/MPlayer/releases/codecs/all-yyyymmdd.tar.bz2 that an updated ebuild can make use of. 2. Gentoo maintainers could put together an improved .tar.bz2 file, containing all of A plus the additional codecs in B, and include it among the distfiles and let an updated ebuild make use of it. 3. The win32codecs ebuild could be refined so that it downloads not only A but also B and merges the contents at install time. Which is the way to go? I'll be glad to give a hand if I can.
Please push this upstream, or ask if they have reason to split them this way. It's probably the best way to go.
