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

[Michel Bardiaux]

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
> if you open ffmpeg.c and libavcodec/utils.c, you'll find out how this is
> handled i think...
> to sum up:
>  - options defined in const OptionDef options[] are handled in ffmpeg.c
>  - if the current option doesn't match any, it triggers the last one,
> which is "default" option
> 
> default options are the ones defined in libavcodec/utils.c
> this calls opt_default with this option, and in this function, we set
> the option for all avctx_opts.
> if this gives nothing, this is done with avformat_opts.
> finally, again if the previous fails, and depending on the first letter
> of the option ("a", "v" or "s" for the moment), it tries to see if the
> option without its leading letter can be applied to the corresponding
> context ("a":audio, ...)
> 
> the only options i see for the moment that works like that are "ab" and
> "vb" (and potentially "sb")

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

What I object to is that the same *value* (default or not) could apply 
to both.

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

(There is a commercial solution, called the 48-hours day, but we cant 
afford it :-) )

> 
>> [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.

-- 
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/