[MPlayer-cvslog] r19789 - trunk/DOCS/tech/binary-packaging.txt

The Wanderer inverseparadox at comcast.net
Tue Sep 12 00:45:27 CEST 2006

Diego Biurrun wrote:

> On Mon, Sep 11, 2006 at 05:11:38PM -0400, The Wanderer wrote:
>> Diego Biurrun wrote:

>>> RV30/RV40 and Indeo.  You got this backwards.  Now that we have
>>> WMV3 and VP6 support the Windows DLLs just cover the fringe
>>> codecs...
>> And yet, oddly enough, there is a WMV[39] file which was played as
>> "no video" by my (r19766) copy of MPlayer until I went out and
>> grabbed the binary codecs package...
> WMV3 support is not yet fully complete but under heavy development.
> I expect Kostya to finish it by the end of the year.

Okay. That fits with what I thought I remembered - but in that case,
your statement above about "fringe codecs" is not yet accurate.

>> (Speaking of which, the binary codecs were not automatically picked
>> up when I placed them in /usr/local/lib/codecs/ as indicated.
>> Specifying that directory to configure located them just fine.
>> There appears to be an inconsistency between the recommended
>> locations and the detection code.)
> Hmm, please try to find out what is going wrong there.  What's the
> output when you grep config.h for _PATH?

wanderer at pegasus:~/text/src/svn/mplayer/mplayer-clean$ make distclean &> 
wanderer at pegasus:~/text/src/svn/mplayer/mplayer-clean$ ./custom_config 
&> /dev/null   # this one-line script does not contain --with-win32libdir
wanderer at pegasus:~/text/src/svn/mplayer/mplayer-clean$ grep _PATH config.h
#define WIN32_PATH "/usr/local/lib/codecs"
#define XACODEC_PATH "/usr/local/lib/codecs"
#define REALCODEC_PATH "/usr/local/lib/codecs"

Which is about what I'd expect to be there - but the first time I tried
recompiling (using my usual routine of "./custom_config ; make dep ;
make") after moving the contents of the codecs tarball into that
directory, the resulting MPlayer failed to play the file in exactly the
same way as my previous no-binary-codecs version had. After copying my
configure line out of 'custom_config', appending the appropriate
'--with-win32libdir' option, and repeating the 'make dep ; make', the
resulting MPlayer played the file just fine.

The possibility that it had just been a matter of some part of MPlayer
not getting recompiled had occurred to me (even though far more was
getting recompiled than seemed to be strictly necessary, given that no
part of the code had changed in the meantime), but if that were the case
then it seems to me that the same non-recompiling should have happened
the second time around.

Hmm... moving the /usr/local/lib/codecs directory out of the way and
reconfiguring finds a subset of the win32 codecs in /usr/lib/win32, even
though I didn't specify that directory. Perhaps this previous detection
(from before the current location was recommended) was persisting
through the initial recompile, even though the other directory had been
created by that point? It doesn't happen that way when I re-place the
directory and reconfigure now, but it's about the only explanation I can
think of.

In any case it doesn't appear to be a particular problem after all.

>> The file in question should be on one of my brothers' computers at
>> present, I'll try to get his attention and make a copy available in
>> incoming/ at some point before he deletes it.
> Yes, make Kostya aware of it.

Will do.

       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.

More information about the MPlayer-cvslog mailing list