[FFmpeg-devel] Ideas to replace the options system

[James Darnley]

On 2015-12-04 15:33, Nicolas George wrote:
> Why do we need a new options system?
> 
>   Most importantly: escaping hell

OMG yes!  I have seen several times the amount of backslashes Windows
users are forced to use to provide a path to some of the filters.

You raise a lot of good points that need to be considered from design,
user-dev, and user-user perspectives.  I haven't read through in great
detail but did glance at the heading and TL;DRs.

I have a couple of probably controversial opinions about this:

- Only allow "simple" string arguments on the command line.  If escapes
or complexity is needed then force people to use a script file.

- Deprecate and remove the expression evaluation that currently exists
and replace it with an existing scripting language.  Sorry to the people
that worked hard on it.  It works fine.  Perhaps the escaping hell
causes my bad perception of it.

- Use Lua.  This is my biased suggestion on what should be used as I
already know and use it.  I'm going to try and sell it to the rest of
you, sorry.  Some of the selling points are:

-- It is very good for embedding in other software.  You can see some of
the places it is used through: http://www.lua.org/uses.html

-- It is powerful and flexible yet simple.  It has just 8 basic types.
Projects where it is used will need to provide their own interface to
their own code.  Lua's meta-methods features lets projects create their
own object and type system to do that.

-- It is portable.  It can be used on all the major desktop operating
systems, mobile operating systems (and embedded platforms but I reckon
the rest of FFmpeg might be the limitation there).

-- It is small.  Their own figures state "24000 lines of C. Under 64-bit
Linux ... the Lua library takes 419K."  The static library of 5.3.1 I
was using is just 301K on Windows/Cygwin 64.

-- Finally it is MIT licensed http://www.lua.org/license.html

If an existing scripting library is chosen then another area to consider
using it might be subtitles.  I haven't been following their development
in great detail but I do remember the people (or was it students) having
problems there with string parsing.

(On the string subject, I saw the tangent about a string type.  I will
say here that Lua's strings are internal and immutable but I think you
should want to parse them in Lua.)

Back to the escaping madness now.  Taking Lua as an example (I'm sure
other interpreters can work just the same) you can easily provide a
script as an argument to its interpreter.  It can define functions,
tables, and just about anything from 1 line and 1 argument.

When used like that I haven't seen need to escape things (except for
quoting to make it 1 argument).  Lua supports 3 ways to represent
strings: single quotes, double quotes, and Lua's double square brackets
which are even extendible with equals signs.  This lets you easily type
strings within one argument from your shell.

I've been at this quite a while and all I've really covered is escaping.
 Perhaps more in another email.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151205/89b0a4dd/attachment.sig>