[FFmpeg-devel] [PATCH] Default to using libraries when enabled

[Michael Niedermayer]

On Sun, Jun 14, 2009 at 02:47:05AM +0300, Ivan Kalvachev wrote:
> On 6/12/09, David Conrad <lessen42 at gmail.com> wrote:
[...]
> The point is, if bug can't be reproduced, it doesn't exist.

indeed :)



> 
> > encoder on purpose, nor anyone who would want to use it over
> > libvorbis. Plus, the only other native encoder for which there is also
> > a competing --enable-lib is mpeg4.
> 
> Ones again. I thought it is not FFmpeg policy to babysit and spoon-feed users.
> If they have no clue what are they doing, then shouldn't be doing it.
> 
> Or to quote a quote - it's like "the old UNIX philosophy of giving people rope,
> and letting them hang themselves with it if they want to".

true, but there are 2 things here
1. giving the user power to do anything she chooses to do
2. being plain inconvenient

UNIX or not, IMHO
* The user should ultimately be in charge of what is done
* There should be no artificial limits or omission of usefull and
  easy to implement things
* the user interface should allow fast working
* the user interface should be intuitive (vi, emacs, gdb, ... are great
  examples of what fails this point)
* there should be documentation that allows users to quickly find relevant
  information (gdb fails this too)

iam not sure where in this list a default setting would fit ...
of course disabling a encoder at compile time is a different matter from
just not selecting it by default and letting the user change that default ...

our vorbis encoder should be compiled and available by default, selecting
another encoder by default at runtime if a better one is available surely
is not a bad idea


> 
> > IMO, the vorbis encoder was a special case due to how bad it was (thus
> > its disabling), and is a good argument for not accepting other
> > encoders until they produce about as good (ideally better) output as
> > other widely used open source encoders (e.g. the old h264 patch, aac
> > encoder, etc.)
> 
> I think this is wrong mentality altogether.
> Every oss project advances by small evolutionary steps.
> First you need something working, then you make it work better and better.
> If you wait somebody to make the best encoder out of thin air,
> you'd never get anything.
> 

> I can't pinpoint single issue, but ffmpeg encoders are in sorry state.
> I can say that very few people are working on improving
> encoders and even fewer developers actually use them regularly.

yes, i know, i remember quite well how i was almost the only one who
improved mpeg1/2/4* encoding
I always wondered why so few others contributed

> Maybe the policy is too strict and few bits could be relaxed.

Maybe people mispredict my review comments to the worse ...
am i that unreasonable?


[...]
> Maybe removing libvorbis support from ffmpeg
> would be better way to encourage people to
> port its psy model into ffmpeg.

i prefer someone who understands ths psy model stuff and can write one
combining the best of several models as well as his own ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090615/453b871d/attachment.pgp>