[Ffmpeg-devel] [PATCH] Update docs according to new "ab" parameter unit
Tue Mar 6 16:27:10 CET 2007
Benoit Fouet wrote:
> Michel Bardiaux wrote:
>> OK, -r works differently from -ab/-vb/-b *now*, but there is no
>> logical reason why it should. A generic behavior is always good from a
>> point of view of documentation and support (only half that much doc to
>> know, etc). So we *should* work towards -ar/-vr (and it shouldnt
>> matter that they are different internally).
> well i need to know one thing: do you want to have, for instance, -b and
> -vb to act in the same way ?
Bottom line: -b has to act *as now*. -vb has to act reasonably, it needs
not be 100% the same as -b, but its always better to apply the
"principle of least astonishment", so yes, it would be better if -b and
-vb were equivalent.
>> What I object to is that the same *value* (default or not) could apply
>> to both.
> on that i already said i don't really care whether i have to be precise
> in the command line (i keep the bitrate example):
> -vb for video, -ab for audio, -b for both...
> i won't argue, as it depends on everybody's feelings :)
OK, I think I see where the misunderstanding came in. If -b had not
existed before, having -b for both would be a matter of taste. My point
was that since -b *does* exist, its semantics should not be changed.
>> Well we have probably a dozen or so, most of them mission-critical,
>> some of them on customer sites. So any major command-line
>> compatibility breakage is a potential catastrophe. To guard against
>> that, for the production environments I always use frozen versions
>> rather than latest svn, but that's a band-aid at best: as soon as I
>> need a fix, say in some codec, I have the devil's choice of either
>> backporting the correction, or fix our scripts.
> is it really a devil's choice ?
A devil's choice means both sides of the choice are unpleasant.
> won't you *always* choose the latter ?
No, but it would be too long to explain why.
>> (There is a commercial solution, called the 48-hours day, but we cant
>> afford it :-) )
> well, it's the same here, they're talking about going from north pole to
> south one depending on season, and adapt work day to sun day :)
>>>>>> A radical proposal: keep all existing options as compatibility
>>>>>> synonyms, and go for getopt_long (--vbitrate 200k) for a new set of
>>>> What, no reaction?
>>> well, no... i think it could be better to split options so that audio
>>> ones are on one side, video on another one, subtitle one too, and so
>>> on... this would some code duplication for AVOption, but well, maybe
>>> it's finally the best thing to do...
>> We're talking about 2 different things here. My proposal was about
>> keeping compatibility while implementing a totally new options scheme.
>> Simple dashes would be 'old style' options, double dashes the new ones.
> why would we/you (i dont really know if i can tell "we", i'm a bit too
> young here ;) ) want to manage both options ?
Because I want to keep the old ones, so to be creative one needs a new
namespace: I propose the space of double-dash options.
T +32  2 790 29 41
F +32  2 790 29 02
E mailto:mbardiaux at mediaxim.be
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
More information about the ffmpeg-devel