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

Benoit Fouet benoit.fouet
Tue Mar 6 16:58:41 CET 2007


Michel Bardiaux wrote:
> 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*.
or to be suppressed ?

> -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.
>
ok, that's what i understood, thanks for clarifying anyway...

>>> 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.
>
makes sense

>>
> [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.
>
thank you, i really needed to be explained the meanings...

>> won't you *always* choose the latter ?
>
> No, but it would be too long to explain why.
>
if you consider i cannot even understand "devil's choice", i do guess
you won't explain to me...
[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.
>
>
when i think all of this came because of amr bitrates :)

Well ok... what we really need (i guess) is to get back on what was
delivered on r8244, think about all this, and find the
"ffmpeg-devel-universal" way of handling this, don't we ?
so, if everyone's ok with that, this should be good if someone with svn
commit rights could do it, so that users don't "suffer" from our
misunderstanding...

Ben





More information about the ffmpeg-devel mailing list