[MPlayer-dev-eng] [PATCH] Do not read codecs.conf files by default

Ivan Kalvachev ikalvachev at gmail.com
Wed Jan 17 14:34:06 CET 2007


2007/1/17, Diego Biurrun <diego at biurrun.de>:
> On Wed, Jan 17, 2007 at 12:11:36AM +0200, Ivan Kalvachev wrote:
> > 2007/1/16, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > >On Mon, Jan 15, 2007 at 08:03:33PM +0100, Diego Biurrun wrote:
> > >> IMO dynamic codecs.conf loading should be an optional,
> > >> disabled-by-default feature that devs can compile-in if they want.
> > >
> > >Going that far, as Michael pointed out, would be a bad idea, among the
> > >reasons security considerations.
> > >A possible consideration would be to change codecs.conf in the sources
> > >so that it would not load without manual modification by the user,
> > >a I-know-what-I-am-doing similar to the lavf bframes thing...
> >
> > There is already "release 20061022" parameter in the codecs.conf.
> > If the release number is older than the one in the build-in
> > codecs.conf then MPlayer should exit with error (saying "Update or
> > Delete").
> >
> > Of course the problem is that this release parameter is not updated on
> > every commit.
> > I hope we could use the svn system for that. ( if there are no $date
> > like macros, then probably via pre/post-commit scripts).
> >
> > I guess this would handle all cases of users stupidity and developers
> > memory leaks.
>
> It does not, look at the bug report that inspired this patch.

I still don't understand what the problem is.
Why the user had codecs.conf with removed driver entry?
It can't be because codecs.conf is old, as "rv3040" is (probably)
older than "rv40".
Then, where have this codecs.conf  came from?

Diego, I personally think you are trying to fix symptoms, without
finding the root of the problem.

If this codecs.conf is put there by debian (or any other) package,
they won't have any problems installing default .mplayer/config with
"codecs-file=/some/obscure/codecs.conf".

And of course this would mean not only that this patch would be
useless, but that now we much check BOTH .mplayer/codecs.conf and
.mplayer/config when looking at obscure codecs problems... (e.g. old
releases still lurking around:).



More information about the MPlayer-dev-eng mailing list