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

[Benoit Fouet]

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

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

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

Ben