On 9/3/26, 8:21 PM, "softworkz ." <[email protected] <mailto:[email protected]>>>> wrote:
>> -----Original Message----- >> From: Nicolas George via ffmpeg-devel <[email protected] >> <mailto:[email protected]>>>> >> Sent: Donnerstag, 18. Juni 2026 16:52 >> To: FFmpeg development discussions and patches <[email protected] >> <mailto:[email protected]>>>> >> Cc: Tom Vaughan <[email protected] <mailto:[email protected]>>>>; Nicolas >> George <[email protected] <mailto:[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 Hi Softworkz, It seems clear that there is no interest in supporting this feature in FFmpeg. I've implemented it in MediaMolder, my redesigned media processing framework. It works great. It's a massive improvement, and the interface is rock solid. There are many more modern features in MediaMolder, including proper metrics. Again, my goal wasn't to compete with FFmpeg. My goal was to go back to first principals and ask "what should a modern media-processing framework do, and how should it be architected?" At the top of the list was improving performance against non-functional requirements like usability and observability. I'd be happy to collaborate with any open-source developers to advance the state of the art. I'm building a killer media application on top of MediaMolder, and it's proven to be much easier to reliably develop applications on top of. Writing code to create long, complex command-line strings, then capturing and parsing raw logs to retrieve metrics is messy and unreliable, in my opinion. Tom https://github.com/MediaMolder/mediamolder _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
