[FFmpeg-devel] Re: [PATCH 1/5] fftools: add JSON command file support for ffmpeg

Thu, 03 Sep 2026 20:21:53 -0700 


> -----Original Message-----
> From: Nicolas George via ffmpeg-devel <[email protected]>
> Sent: Donnerstag, 18. Juni 2026 16:52
> To: FFmpeg development discussions and patches <[email protected]>
> Cc: Tom Vaughan <[email protected]>; Nicolas George <[email protected]>
> Subject: [FFmpeg-devel] Re: [PATCH 1/5] fftools: add JSON command file
> support for ffmpeg
> 
> I am sorry, I am lacking the time and energy to reply to this discussion
> constructively.
> 
> Therefore I will just write the few general remarks and just let
> somebody else take over the specific discussion.
> 
> One: features and user interface are two separate things. If you have
> added a new feature to the fftools, then we might want it, triggered by
> normal options, whether or not we want the JSON-based interface too or
> not.
> 
> Second: your JSON code only encodes the top-level arguments and options:
> codec parameters, filter graphs, but these are still strings and still
> require escaping. In fact, you are even making it slightly worse, since
> individual arguments do not require escaping (except if using a shell)
> whereas your version will always require top-level JSON escaping.
> 
> If you want to make your feature really useful, use the structure of
> JSON objects. I.e., instead of:
> 
>       "lavfi" : "drawtext=x=100:y=100:t='Eh: you?',scale=800:600"
> 
> make it possible to write something like that:
> 
>       "lavfi" : [
>         {
>           "filter" : "drawtext",
>           "x" : 100,
>           "y" : 100,
>           "t" : "Eh: you?"
>         },
>         {
>           "filter" : "scale",
>           "w" : 800,
>           "h" : 600,
>         }
>       ]
> 
> But it is not easy, because a lot of sub-options that need parsing and
> escaping are just declared as strings in the code.


Hi Nicolas & Tom,

having done something similar already, I'd agree that escaping is crucial
and should be ideally performed by a (platform-specific) procedure when
generating a command line rather than being baked into the JSON.

A presentation as suggested (json objects) can be difficult to handle, 
because values like x/y/w/h are integer for some filters and string for
other filters (for example), which makes it hard to have the JSON
backed by a typed object model 

I ended up with a somewhat extreme approach which means every FFmpeg
feature (each muxer, encoder, protocol, etc.) is projected to a 
separate type with its own strongly-typed properties - all autogenerated. 

The auto-generation is the interesting part: it's based on FFmpeg cli
help output like 

ffmpeg -decoders
ffmpeg -h decoder=h264
...

Most remarkably, the help output is sufficient for deriving a strongly
typed model of FFmpeg command line options with coverage close to 100%.
It's easier to parse than source code files and way more reliable. 
Of course, it's limited to what a compiled ffmpeg build includes, which 
one may consider a drawback or an advantage.
Regardless, I think that's the best way to get this kind o information 
out of FFmpeg, almost like a reflection API.

sw








_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]






















					Reply via email to