[MPlayer-dev-eng] [PATCH] Do not read codecs.conf files by default
diego at biurrun.de
Wed Jan 17 16:01:52 CET 2007
On Wed, Jan 17, 2007 at 03:34:06PM +0200, Ivan Kalvachev wrote:
> 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
> 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:).
Nonsense. Please read the bug report before making wild assumptions and
jumping to conclusions.
More information about the MPlayer-dev-eng