Better filter help

[Bernardo]

Is it possible to add default values of filters in the help option? Also, some data is missing, like ranges in options that accept expressions.

This is the help for e.g. Hue filter:

hue AVOptions:
  h       <string>     ..FV.. set the hue angle degrees expression
  s       <string>     ..FV.. set the saturation expression
  H       <string>     ..FV.. set the hue angle radians expression

While this is the man page (despite not being updated and show "float" instead of "expression", it has the range information and default value):

hue
   Modify the hue and/or the saturation of the input.
   This filter accepts the following options:
   h   Specify the hue angle as a number of degrees. It accepts an expression, and defaults to "0".
   s   Specify the saturation in the [-10,10] range. It accepts a float number and defaults to "1".
   H   Specify the hue angle as a number of radians. It accepts a float number or an expression, and defaults to "0".

The filter options that take int or double do have the range, but not the default value. E.g:

c1_strength   <int>    ..FV.. set component #1 strength (from 0 to 100)

So, it would be nice to have these values in the help option because they will not suffer from code changes (because the values come from the code) and are easier to use. Example:

hue AVOptions:
  h    <string>   ..FV.. set the hue angle degrees expression (default: 0)
  s    <string>   ..FV.. set the saturation expression (from -10 to 10, default: 1)
  H    <string>   ..FV.. set the hue angle radians expression (default: 0)

[Stefano Sabatini]

Replying to jbvsmo:

Is it possible to add default values of filters in the help option? Also, some data is missing, like ranges in options that accept expressions.

An expression is just a string, so in general you can't specify a range in the option definition.

This is the help for e.g. Hue filter:

hue AVOptions:
  h       <string>     ..FV.. set the hue angle degrees expression
  s       <string>     ..FV.. set the saturation expression
  H       <string>     ..FV.. set the hue angle radians expression

While this is the man page (despite not being updated and show "float" instead of "expression", it has the range information and default value):

hue
   Modify the hue and/or the saturation of the input.
   This filter accepts the following options:
   h   Specify the hue angle as a number of degrees. It accepts an expression, and defaults to "0".
   s   Specify the saturation in the [-10,10] range. It accepts a float number and defaults to "1".
   H   Specify the hue angle as a number of radians. It accepts a float number or an expression, and defaults to "0".

Fixed.

The filter options that take int or double do have the range, but not the default value. E.g:

c1_strength   <int>    ..FV.. set component #1 strength (from 0 to 100)

So, it would be nice to have these values in the help option because they will not suffer from code changes (because the values come from the code) and are easier to use. Example:

hue AVOptions:
  h    <string>   ..FV.. set the hue angle degrees expression (default: 0)
  s    <string>   ..FV.. set the saturation expression (from -10 to 10, default: 1)
  H    <string>   ..FV.. set the hue angle radians expression (default: 0)

Yes, this could be changed for all options (not only filter options).

[Bernardo]

Replying to saste:

An expression is just a string, so in general you can't specify a range in the option definition.

The "AVOption" struct has the fields "min" and "max" so they could probably be set with what the expression expects.

[PS: I don't want to open another bug report, but there are other small inconsistencies in the docs (that are right in the -help option) like the "noise" filter had the "q" flag removed but the filters.texi still has it. ]

[Elon Musk]

Fixed in a64248d1ec154779473be90ce1608702cc4a6496.

[Bernardo]

That's great!
But, there's no way in the "expression" type to set and show the range they expect? (when it makes sense)

[Elon Musk]

There is no way currently, making it possible would need much more significant changes for very little gain, and they would probably confuse users more than helping.