[FFmpeg-devel] Ideas to replace the options system

[Nicolas George]

Replying to everybody at once:


To Ronald, regarding "rewrite EVERYTHING!!!" versus "added as extensions of
the current API":

My gut feeling is that starting from scratch would prove less efforts in
total. The current code is already quite convoluted, even adding a single
type requires adding code in various places, and it is already not easy to
know what places are mandatory and what places are optional or squarely
redundant. There are functions with similar names because one was added
after the other, etc.

The way I see it, just getting the current code into shape for serious
extensions would require a big refactoring. I believe this is a situation
where the desired new features are significantly larger that the current
code base, and in these case, not worrying with the existing, taking only
what is useful as it comes seems easier.

But of course, this is up to whoever does the work.


To Paul, about dynamic options changing:

This one, I think, is rather orthogonal to what I am suggesting. Right now,
you could call av_opt_set() on a filter or a codec that is already in use.
It would give awful results, but not because of the options system, because
filters and codec are not ready for options changing below their feet.

Of course, some support from the options system would help, like a flag
telling us if an option can be changed later or not (dynamic read/write
status), but the bulk of the effort seems to be getting filters into shape.


To James, regarding allowing only simple string arguments:

I do not quite understand what you are proposing. How would the user specify
a PAN matrix like "FL<FL+RL+0.5*FC:FR<FR+RR+0.5*FC" with just simple string
arguments? Or a drawtext string with expanded variable snippets?


To James again, regarding using a scripting language like Lua:

I believe supporting it would be a great improvement, but relying on it,
making it the main entry point, would not.

I partially agree with Tobias Rapp that it would make beginners' life
harder: the base syntax does not need to be complicated, but the extra
features would make error diagnosis much harder.

Furthermore, there are security considerations. Reimar already warned that
allowing untrusted users to set some options is dangerous, but it is mostly
minor and theoretical. Security levels could be added to options to make it
really safe. On the other hand, with a full scripting language, I could get
an online transcoding service to mine bitcoins for me while parsing the
options and get the results in the encoded video.

So completely yes to a scripting language, but not as the only entry point.


To Tobias, about using JSON syntax:

I must say, I do not see how it would help. It seems to make things rather
worse. JSON have lists and key-value pairs, and we need these, but only at
the toplevel, not nested. Escaping hell comes from nesting syntaxes. What we
nest are types unknown to JSON: video sizes, drawtext formated strings,
channel layouts, expressions. As your examples show, expressions need to be
quoted inside JSON, and the example seems rather longer than the current
syntax for the same thing.

There is another feature of the current option system that neither JSON nor
scripting languages provide: context-dependant constants. Right now, I can
write "application=voip" for libopusenc and arnr-type=backward for
libvpxenc, but "voip" makes no sense for libvpx, nor "backward" for libopus.
General-purpose syntaxes are not aware of the context and can not take that
into account.


To Ryan, regarding reading values from a file:

It helps, of course, but reading from a file, like using single quotes,
works only once. It saves one level of escaping, but the contents of the
file is still subject to escaping hell. Unless users are expected to use
another file indirection for each level of nested syntax, which seems rather
inconvenient.


I hope I addressed most of the remarks.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151210/a78d2e40/attachment.sig>