[MPlayer-dev-eng] fixing codecs.conf issues?

[D Richard Felker III]

hey, here are a few codecs.conf issues i'd like to report, and perhaps
work on fixing as well if everything sounds ok to the developers...

1) in the absence of win32 codecs (even when compiled with
--disable-win32), mplayer will still choose win32 codecs from
codecs.conf and then complain that they don't work, rather than
finding the later open source codec that would work perfectly fine if
the earlier one in the file didn't take precedence. using -vfm 5 fixes
the problem partially but makes mpeg 1 and 2 playback much slower,
since libavcodec isn't as heavily optimized as libmpeg2, so imho there
should be a better solution to the problem.

2) the "opendivx" codec entry in codecs.conf lists fourcc's that true
opendivx doesn't work with at all, resulting in bad or no video
output if mplayer isn't compiled with divx4 support.

one way both of these issues could be fixed without much trouble is
making the source version of codecs.conf a preprocessed file -- say,
perhaps running it through the c preprocessor using config.h to
determine what to include and omit. then, build the final version to
install at compiletime, tailored to the user's configuration.

perhaps a better fix for #1 -- but i'm not familar with the codebase
so i don't know if this is feasible -- is to make mplayer keep on
searching for another matching codec until it finds one that can be
initialized successfully, rather than quitting when the first one
found (the win32 one) is unavailable.

as for #2, it might be best to just remove the offending fourcc's from
codecs.conf, if you don't want to preprocess codecs.conf and all
that. or -- i think i've read thoughts like this on the list before --
perhaps its about time for opendivx to be removed from mplayer
altogether. there are very few files that true opendivx (as opposed to
divx4) can actually play, and libavcodec does just as well if not
better on them anyway. this would also bring you one step closer to
resolving all the licensing problems, wouldn't it?

any thoughts on these matters? as i said, i'm not sufficiently
familiar with the mplayer code to contribute any significant patches,
but i could probably work out a decent system for building a
custom-tailored codecs.conf at compiletime, if you guys would actually
want to include such a system in mplayer's build process.


richard