FFmpeg in FileMaker

A conversation you might recognise

A video engineer walks up to a FileMaker developer. They've spent three days perfecting an FFmpeg command that produces exactly the right output — the right codec, the right proxy size, the right poster frame. It works perfectly. In a terminal window. On their
laptop.

Now they need it to run for fifty operators, triggered from a button in a FileMaker layout, without any of those operators ever seeing a terminal.

That conversation used to end with "we can't do that from FileMaker."

The gap

FileMaker developers are good at interfaces. Video engineers are good at encoding pipelines. The problem is that those two worlds have never had a shared language. A FileMaker developer can't easily take an FFmpeg command and turn it into a script step. A video engineer can't easily put their workflow inside a FileMaker layout.

The result is usually a brittle workaround — a watched folder, a scheduled script on a server, a manual step that depends on the right person being in the right place. It works until it doesn't.

Inlay_TRANSCODE

Inlay_TRANSCODE is a FileMaker plugin function that accepts an FFmpeg job as a JSON argument and runs it — with a native progress window, a cancel button, and a result the script can act on.

The key word is accepts. You don't need to understand the FFmpeg parameters. You just need to receive them from someone who does, drop them into a FileMaker variable, and call the function.

Set Variable [ $job ; Inlay_TRANSCODE ( $ffmpeg_payload ) ]

That's the integration. The video engineer owns the payload. The FileMaker developer owns the interface. Each does what they're good at.

What that looks like in practice

A production facility has a video engineer who has already defined their encode spec: hi-res H.264 for delivery, a 960×540 proxy for review, and a representative poster frame — all from one pass. They hand that spec to the FileMaker developer as a JSON object.

The FileMaker developer stores it in a global variable, wires it to a button on the asset record layout, and adds a polling loop that writes the output paths back to the record when encoding completes. The operators never know FFmpeg is involved. They click a
button, watch a progress bar, and get three files.

The video engineer can update the encode spec any time — change the bitrate, swap the codec, adjust the proxy resolution — and the FileMaker solution picks it up without any code changes.

For the FileMaker developer

You don't need to learn FFmpeg to use this. You need to know how to call a function, read a JSON result, and poll a file path. If you've used Inlay_S3_COPY or any other Inlay function, the pattern is identical.

If a client's video team already has a working FFmpeg workflow, this is the fastest path to giving their operators a proper interface for it — without rebuilding the pipeline and without dragging anyone into a terminal window.

Have questions or want to see how this fits your solution? Get in touch →