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

[Michael Niedermayer]

On Sun, Jun 21, 2009 at 08:05:14PM -0400, David Conrad wrote:
> On Jun 15, 2009, at 5:00 PM, Michael Niedermayer wrote:
>
>> 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
>
> So, I should revert my disabling of the vorbis encoder. How about moving 
> only the libvorbis declaration above native encoders, as in the attached? 
> (or moving the native vorbis encoder below all others?) And would adding an 
> av_log info message to vorbis_enc.c saying that the native vorbis encoder 
> is poor quality (and recommending libvorbis) be okay?

adding a flag (like the CODEC_CAP_* stuff but CAPability is maybe a bad name
here) that specifies that the codec is not production quality yet could help
a user app like ffmpeg could then print a warning and the code could select
codecs while prefering ones wihout that flag ...

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/20090622/56ff65de/attachment.pgp>