[MPlayer-cvslog] r23020 - trunk/etc/codecs.conf

[Ivan Kalvachev]

2007/4/19, Compn <tempn at twmi.rr.com>:
> On Thu, 19 Apr 2007 01:55:35 +0200, Diego Biurrun scribed:
>
> >On Wed, Apr 18, 2007 at 09:25:11PM +0300, Ivan Kalvachev wrote:
> >> 2007/4/18, diego <subversion at mplayerhq.hu>:
> >> >
> >> >Log:
> >> >FFmpeg Atrac 3
> >> >
> >> >--- trunk/etc/codecs.conf       (original)
> >> >+++ trunk/etc/codecs.conf       Wed Apr 18 16:39:16 2007
> >> >@@ -2386,6 +2386,13 @@ audiocodec ffcook
> >> >
> >> >+audiocodec ffatrc
> >> >+  info "FFmpeg Atrac 3 audio decoder"
> >> >+  status working
> >> >+  format 0x63727461 ; "atrc"
> >> >+  driver ffmpeg
> >> >+  dll "atrac 3"
> >>
> >> Adding 2 new decoders is big enough change to boost the release
> >> number.
> >
> >Why?  We have never had such a policy, codecs.conf.txt does not mandate
> >it, Roberto does not do it...  I'm not against implementing such a
> >policy if it makes sense, but it's never been discussed nor the habit.
>
> you guys tried to discuss this last month...
> http://lists.mplayerhq.hu/pipermail/mplayer-cvslog/2007-March/029134.html

Actually it is much older. Look in -dev-eng.

Let's say that for some reason some advanced user have placed
codecs.conf in .mplayer. Then he upgrades mplayer svn and tries to use
the new codecs. And of course they don't work.

The release number indicates that there are changes in the codecs.conf
and newer version must be used.

The user usually is not aware that there are changes in codecs.conf or
that these changes are big enough to cause supported codecs not to
work (as expected). This is what the committers knows and there is no
other way to signal that.



Of course the current behavior is to ignore the obsolete codecs.conf
but it would be trivial to make mplayer exit with error message.

Increasing this number only at releases is useful only if we do
frequent releases and nobody but developers use svn, that is not the
situation at the moment. Also, it is pointless to increasing the
codecs.conf release number on mplayer release when there are no
changes.

FYI the policy Diego was quoting is written at the same time when
"release" option was implemented, months before we get fallback
build-in version. That's why I consider it a little bit out-dated.