On 4/19/26, 8:36 AM, "Nicolas George" <[email protected] <mailto:[email protected]>> wrote:
>Tom Vaughan via ffmpeg-devel (HE12026-04-14): >> To experiment and make improvements faster, I realized that it would >> be best to re-architect the interface and orchestration layer. So, >> I've created a new open-source project... >> https://github.com/MediaMolder/mediamolder >> <https://github.com/MediaMolder/mediamolder>. Contributions are >> welcomed. >Hi. Having an alternate implementation of the driving logic is a very >good thing. Nice. >I would still suggest to have the feature of converting your JSON >structure into a real ffmpeg command-line: ffmpeg is a very common tool, >it can be available on places where your tool is not: hosted servers, >compute clusters, etc. The option to use your tool to prepare the >command-line and submit it elsewhere would be very useful. Hi Nicolas. Thanks for the positive feedback. That feature is part of the patches I've contributed here. The media processing graph capabilities of MediaMolder are a superset of FFmpeg, with commands/parameters that aren't supported by FFmpeg. For example... https://github.com/MediaMolder/mediamolder/blob/main/docs/go-processor-nodes.md and https://github.com/MediaMolder/mediamolder/blob/main/docs/yolov8-guide.md This difference is going to grow over time. So, I don't think it makes sense to build and maintain a feature that won't work for all possible MediaMolder jobs. As an engineer who has written a lot of code that creates FFmpeg command-line strings, I believe that all the many thousands of other developers who drive FFmpeg with their code would also prefer the ability to drive it through a structured JSON. It enables more compact, understandable, and reliable code. Typically, you would use a job template JSON, and your code would simply replace a few job-specific parameters (source, output path/filename) in the template, then submit the job. It's an industry standard for web APIs, and we can leverage that. Another way to think of this improvement to the interface: it falls into the category of meeting the non-functional requirements of the library, (usability, manageability, reliability), which are every bit as important to satisfy as functional requirements. Of course, I understand concerns about maintainability, but I think if you review the patches, you will see that this improvement won't be difficult to maintain (and of course, it is entirely optional for FFmpeg users / developers). I also understand that some may have concerns about security, but I don't think this creates a new attack surface. If you could craft a FFmpeg command-line string that causes a security issue, you could do the same with a JSON and vice-versa. Security must be in the next stages. My goal is to experiment and innovate... not to compete with FFmpeg. If anyone is interested in me upstreaming any of the features of MediaMolder to FFmpeg, I would be more than happy to contribute them as C patches. I will also be augmenting some core libraries (in C), starting with x264, and I plan to contribute all improvements upstream (after adequate testing). See https://github.com/MediaMolder/x264 Tom _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
