Video in volume, on our own engine

GZS, Slovenia's Chamber of Commerce, runs the national innovation awards. In 2026 each of the 235 entries needed a branded 35-second video for the ceremonies. Cutting those by hand across thirteen regions was never going to happen.

So every video is built from the entry itself. The pipeline takes the title, the company, the description and the photos or clips the entrant uploaded. It writes a Slovenian voiceover from the description and checks technical words against Slovenia's official lexical database, so they are stressed correctly. Then it fits the narration to the video. The slides stretch first, and only then does the speed change, within a range too small to hear.

We rendered 1,410 videos in total, because every entry was made in six voice variants while we compared speech providers. That is 235 entries times six. GZS received the 235 finished ones, and they played at the ceremonies.

• An uploaded clip is used when it is sharp and long enough, and the photos become a slow pan-and-zoom slideshow when it is missing
• Long titles and company names are wrapped and shortened to fit the opening card
• A transparent logo gets a background colour picked for it, with a manual override per entry
• Every batch run ends with a summary per region of what rendered and what was skipped

Almost every video product runs on FFmpeg underneath. It is the free tool that cuts, mixes and encodes video, and its commands are dense. A slideshow with crossfades and music takes 44 lines of them, and one wrong character can fail deep into a render.

Our engine lets a developer describe the video in ordinary code. Mistakes are caught while the code is written. Wiring sound into a picture filter, for example, is flagged before any render starts. The finished job then goes to two machines we run ourselves. One handles the encoding. The other has a graphics card for AI work, such as finding faces in footage and blurring them.

The same machines now carry work beyond video. They also run five language models that we host ourselves.

• Errors show up on the developer's screen, before any machine time is spent
• One machine for encoding, and one with a 20 GB graphics card for AI models
• A job that no machine is equipped for is refused on arrival, with the missing part named

JT Cut is our video tool in the browser, live at jtcut.com. A user uploads photos, picks a look, types a voiceover script and presses render. Every one of those videos is rendered on our machines, and the page checks back for progress until the file is ready.

A newer product cuts video ads. A team brings one approved ad with its script versions, footage and voiceovers, and it produces every cut across opening hooks, languages and formats. Each file goes to our machines as its own job. On its first live run, one day after work on it began, 25 jobs went out and all 25 came back. It is still before launch.

The GZS award videos were assembled with the building blocks of the same engine, in one batch for all thirteen regions.

The system that hands out jobs gives up on a machine after 30 minutes and passes the job to another one. Long renders used to run twice because of it. Now each job has one recorded owner, kept in a small ledger on the machine. The first long production job after the change ran for 41.5 minutes and finished exactly once.

A late copy of a job cannot overwrite a finished file either. The code that does the work has no way to reach storage. Only the layer around it can upload, and it checks that the job is still its own right before it does.

JT Cut also watches for renders that go quiet. A render with no final word after 30 minutes is marked failed, so the user can retry at once. Real footage finds real bugs too. Slovenian letters such as č in a music file's tags once crashed a slideshow render, and the fix carries a test built from that exact case.