Why we built our own live graphics engine

For the Tyrun Racing livestreams we needed graphics that move as fast as the sport itself. So we built them ourselves. Steije, DOP and post producer at Crowdproductions, explains how a small custom server and a Stream Deck replaced an expensive broadcast graphics setup.

The problem: everything changes except the graphics

When we started doing the livestreams for Tyrun Racing, the graphics were the part that bugged me most. Hybrid fitness racing moves fast. Heats, athletes, times and rankings change constantly. Typing names into a lower third by hand was never going to keep up.

Until then, our graphics had always been static: a logo or a fixed overlay, keyed on the upstream or downstream keyer of the ATEM, or added as an extra layer in OBS. It did the job, but nothing on screen was ever live.

The usual broadcast graphics systems are powerful. They’re also expensive, heavy and built for teams far bigger than ours. I wanted something small and fast, fully under my own control.

Fast to change

At its core, the engine is a custom server that renders the graphics and sends them out as a clean video feed into our switcher.

Because we control the whole thing, I can tweak animations, layouts and typography in minutes instead of hours. For Tyrun everything stays black, white and the tints in between, and we keep that brand style strict.

What goes on screen

During a Tyrun stream, the engine handles everything graphic:

• Lower thirds, on demand or fully automatic
• Scoreboards and leaderboards
• A bug in the corner of the screen
• A live clock

The automatic lower thirds are my favourite part. When an athlete crosses the finish line, their name appears on screen by itself. Nobody has to press a button. That’s the kind of detail that makes a stream feel like real broadcast television.

Live data, straight from the client

The real magic is the data. The engine is hooked up to Tyrun’s data and updates the graphics automatically.

No retyping names. No copy-pasting results. When the data changes on their side, the graphic on screen follows. That removes a whole category of mistakes from a live show, and it frees up a person who would otherwise be stuck at a keyboard.

From test rig to dedicated server

The first version ran on a tiny computer. For the first event where we used it, I brought two. On one of them, a video port got fried. I still don’t know how. Those ports are tiny and fragile, and that’s not something you want to depend on during a live show.

The good news: the engine itself worked flawlessly that day. The software was solid; the hardware was the weak link.

That made one thing clear: I wanted a light server whose sole purpose is graphics. Nothing else running on it, nothing to get in the way. After that, we switched to a sturdier mini PC. Small and quiet, with solid ports and more than enough power to push animated graphics all day.

The hardest part: key and fill

The toughest problem wasn’t the graphics themselves. It was getting the signals to the switcher perfectly in sync.

A graphic consists of a fill, the actual graphic, and a key that tells the switcher what to cut out. If those two drift even slightly apart, you see it immediately as ugly edges or flickering. Getting that right took more work than anything else in the project.

Control: Stream Deck and a web interface

On show day, the operator controls everything from a Stream Deck. One button brings in a lower third, another fires the leaderboard, another takes it out. Physical buttons are fast and you can work them without looking.

There’s also a web interface. Anyone on the network can open it in a browser and control the graphics from a laptop, tablet or phone. Handy for setup, for testing, or as a backup for the Stream Deck operator.

Built with Claude Code

I’m a DOP and post producer, not a software developer. I built the server with Claude Code, an AI assistant that writes code.

I had a working first version after half a day. Since then, I’ve spent almost a month tweaking, refining and adding features, and the engine keeps evolving after every event.

That’s the part I find most exciting. A few years ago, a tool like this would have meant hiring a developer or buying an expensive licence. Now someone who knows exactly what a production needs can build it themselves, improve it between shows, and shape it around the way we actually work.

Updates without touching the box

The engine gets updates remotely. When a client asks for a change, I can push a new version to the server without physically touching it. Fix a layout, add a graphic, ship it. It’s a very fast way of working with clients.

Secure, even from a distance

Right now the engine runs locally, on the same network as the livestream gear. But we’re thinking about opening it up and using it for other clients too.

The idea is that a graphics operator wouldn’t need to sit next to the livestream setup. They could be somewhere else entirely and run the graphics through a public URL.

The moment something is reachable from the internet, security stops being optional. That’s why the code gets scanned automatically for security issues, so we can patch them before they ever become a problem.

Why custom beats off the shelf

People sometimes ask why I didn’t just rent a commercial graphics system. Honestly, I never even priced one out.

The real advantage isn’t cost. It’s focus. Because the engine is custom, we build exactly what the client wants and nothing else. Every feature exists because a production needed it. That’s how you get the best result on screen.

The bigger picture

This engine is one piece of something bigger. We’re building a set of tools to make our livestreams and our regular video productions better, faster and more automated.

The goal is simple: spend less time on repetitive, error-prone tasks and more time on what actually makes a production good. The shots, the story, the energy on screen. Small crew, fast workflow, high-quality output. That’s the direction.

What’s next

We’ll keep sharing what we build along the way. If you work in live production and you’re curious how this works, or you’re thinking of building your own tools, get in touch. Planning an event that needs live graphics? See what we do in livestreaming.