[Ffmpeg-devel] [PATCH] Update docs according to new "ab" parameter unit

[Michel Bardiaux]

Benoit Fouet wrote:
> Michel Bardiaux wrote:
> [snip]
>> 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.

> 
[snip]

>> 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 :)
> 
>>>> [snip]
>>>>
>>>>>> A radical proposal: keep all existing options as compatibility
>>>>>> synonyms, and go for getopt_long (--vbitrate 200k) for a new set of
>>>>>> options.
>>>>>>
>>>> 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.


-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/