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

[Benoit Fouet]

Michel Bardiaux wrote:
> Benoit Fouet wrote:
>> Michel Bardiaux wrote:
>>> Benoit Fouet wrote:
>>>> Michel Bardiaux wrote:
>>>>> Michael Niedermayer wrote:
>> [snip]
>>>>>> without anyone even bothering to look at the code :(
>>>>>> not to mention the thread where i asked if anyone would mind the -b
>>>>>> change ...
>>>>>>
>>>>>> so again
>>>>>> -foobar sets  foobar for all contextx
>>>>>> -afoobar sets foobar for the audio context
>>>>>> -vfoobar sets foobar for the video context
>>>>>>
>>>>>> that is nicely consistent but changes a few cases like -ab X -b Y in
>>>>>> unexpected ways
>>>>> And -r 25 would set the video fps *and* the audio sampling rate to
>>>>> 25?
>>>>> That cant be good. What foo is a reasonable bar for both A and V?
>>>>>
>>>> no, rate works in a different way...
>>> Sorry, I dont see what you mean here. If you mean rate is a exception
>>> to the generic behavior described above by Michael, then its main
>>> (IMHO only) merit, that of consistency, is already lost.
>>>
>> that is what i meant
>>
[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 ?

> 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 :)

>>>>>> we could of course add -b with a function which av_log()exits()
>>>>> Or keep -b as synonymous to -vb, -r as synonymous to -vr, etc...
>>>>>
>>>> i don't think it's worth it...
>>> :-( How many scripts using ffmpeg do you have in production?
>>>
>> none, that's a fact...
>
> 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 ? won't you *always* choose the latter ?

> (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 ?

Ben