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

[Arpi]

Hi,

Hmm.
I like both idea (preprocessing and mplayer keeps searching next codec).
The second one is a bit hard now. Codecs wrappers are a bit messy, most of
them cannot be uninitialized, nor re-initialized. After we moved them to
libmpcodecs, and made some cleanup, review, it will be possible (and it's
planned)

I also had an idea to replace -afm/-vfm: codecs priority list.
so, users can set up their preferred order of codecs, to override order in
codecs.conf. this can be made in mplayer config file...
(but needs to be implemented :))

if you're interested in the above tasks, it's great!
(especially codecs priority option)

> 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
> 
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 
> 


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu