mplayer (from CVS) && win32/wmvadvd.dll

m.apitz at oclcpica.org m.apitz at oclcpica.org
Wed May 17 04:52:10 PDT 2006


Hello,

I'm trying to play a stream with mplayer from

$ mplayer mms://80.84.129.169/telesur45

The stream needs the newer video codecs Windows Media Video 9 Advanced
which comes from the (Windows) DLL wmvadvd.dll. Of course, it did
not work out of the box with the version in the 6.0-REL port of
mplayer and the mplayer folks directed me to fetch the current from
their CVS. I did so, compiled it and now I'm already able to play
the audio from the stream but the codecs for video from wmvadvd.dll
does not work. The mplayer folks claime that it works for them
with exactly the CVS version on *Linux*, ie. they tested the above
stream and both, video and audio, are fine.

So I digged into the sources to get why it says 'Unsupported WMVA version'
and it turned out that they map somehow the above DLL in memory
and awaiting there at special offsets some code or whatever, which
does not match and so they can't use the DLL. The c-file which
does the mapping of the DLL to memory (loader/pe_image.c) has a comment
saying:

/* Notes:
 * Before you start changing something in this file be aware of the following:
 *
 * - There are several functions called recursively. In a very subtle and
 *   obscure way. DLLs can reference each other recursively etc.
 * - If you want to enhance, speed up or clean up something in here, think
 *   twice WHY it is implemented in that strange way. There is usually a reason.
 *   Though sometimes it might just be lazyness ;)
 * - In PE_MapImage, right before fixup_imports() all external and internal
 *   state MUST be correct since this function can be called with the SAME image
 *   AGAIN. (Thats recursion for you.) That means MODREF.module and
 *   NE_MODULE.module32.
 * - Sometimes, we can't use Linux mmap() to mmap() the images directly.
 *
 *   The problem is, that there is not direct 1:1 mapping from a diskimage and
 *   a memoryimage. The headers at the start are mapped linear, but the sections
 *   are not. Older x86 pe binaries are 512 byte aligned in file and 4096 byte
 *   aligned in memory. Linux likes them 4096 byte aligned in memory (due to
 *   x86 pagesize, this cannot be fixed without a rather large kernel rewrite)
 *   and 'blocksize' file-aligned (offsets). Since we have 512/1024/2048 (CDROM)
 *   and other byte blocksizes, we can't always do this.  We *can* do this for
 *   newer pe binaries produced by MSVC 5 and later, since they are also aligned
 *   to 4096 byte boundaries on disk.
 */

This let me some how thinking that there could be a missmatch between
Linux and FreeBSD. Without deeper knowledge about how these DLLs are
working I am lost here :-((

Has someone a comment on it? Can someone with a CVS version of mplayer
try the above stream to ensure that it is not a local problem in my
compilation? Any other idea?

Thx in advance

	matthias
-- 
Matthias Apitz
Manager Technical Support - OCLC PICA GmbH
Gruenwalder Weg 28g - 82041 Oberhaching - Germany
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <m.apitz at oclcpica.org> - w http://www.oclcpica.org/ http://guru.UnixLand.de/


More information about the freebsd-questions mailing list