We built Open Live: live production, in the open, on infrastructure you own
Eyevinn has open-sourced Open Live, a complete live production path built on the GStreamer-based Strom pipeline and open transport standards. Read it, run it, and stand it up on Open Source Cloud, then keep what you deploy.
I have spent most of my career around live production systems, and I keep running into the same wall. The tooling that runs a modern live channel is some of the most capable software in our industry, and almost none of it is something the broadcaster actually owns. You rent the pipeline. You integrate against an API you cannot see inside. And when something breaks at the worst possible moment, you are filing a support ticket instead of reading the code. So we built the thing we wanted instead. Today I am happy to share that Eyevinn has created Open Live, and we have open-sourced it.
Why we built it
The honest answer is that we got tired of the gap between how good live production tooling has become and how little of it you can see, change, or keep. Production stacks live for years. They accumulate the specific workflow of a specific operation, the routing, the templates, the way one particular gallery likes to work. That investment is real, and it should belong to the people who made it, not to whoever happens to own the platform this quarter. Open Live is our attempt to put a complete live production path into the open, where an engineer can read every stage, run it themselves, and adapt it to how they actually work. Not a demo, not a closed appliance with an open-source sticker on it. The repositories are public. You can clone them today.
What Open Live is
In plain terms, Open Live orchestrates a live production: it takes your sources, lets an operator drive the production through a Studio UI, and runs the signal from camera to viewer. Underneath the orchestration sits Strom, our GStreamer-based pipeline. Strom does the work an engineer recognises: ingest over SRT, transcode, vision mixing, and output. Open Live wraps that pipeline in production concepts that make sense in a gallery, sources, templates, and activation, and exposes an operator interface, Open Live Studio, so a human can actually run the show rather than edit config files mid-broadcast. At the edges we lean on open standards rather than proprietary transport. SRT for contribution coming in. WHIP and WHEP for low-latency delivery to a browser on the way out. That matters beyond ideology: it means your signal is never trapped inside a format only one vendor can read. We are also watching Media over QUIC closely as the next step for low-latency transport. MoQ is still an emerging IETF draft, not a finished standard, so we treat it as something to build toward rather than something to claim today. I want to be straight about maturity, because that is the only way this is worth anything to a fellow engineer. Open Live is a first open release. It is early. There are rough edges, and we know where some of them are. This is not a stack with a decade of large-scale production behind it, and I am not going to pretend otherwise with camera counts or latency numbers I cannot stand behind. What it is, is real, runnable, and open, and an invitation to build the mature version of it together.
How we build, and why open
This is not the first time we have built broadcast infrastructure in the open, and the pattern is deliberate. Open Intercom is the clearest example. It is production talkback built on WebRTC and open standards, developed alongside public-service broadcasters, and it runs in real production today. It exists because broadcasters brought the operational reality and we brought the engineering, in public, where both sides could see the code. Encore, our open-source transcoding platform, came out of the same world, with roots in a public broadcaster’s own infrastructure, and it has been maintained in the open ever since. Our whole industry has a long tradition of broadcasters open-sourcing hard-won production tooling so the rest of us can build on it, and that tradition is a large part of why broadcast software is as good as it is. Open Live is the next step in that habit. The reason we keep building this way is not philosophy for its own sake. It is that tools an engineer can read and change are tools an engineer can trust, and trust is the only currency that matters when you are live.
Where OSC comes in
Open-sourcing a stack is necessary but not sufficient. A pile of repositories is not a running channel. The other half of the problem is standing the whole thing up without it becoming a two-week infrastructure project. That is what Eyevinn Open Source Cloud, OSC, is for. You can bring up the full Open Live stack on OSC, and because OSC is MCP-native, you can provision it the way you would now expect to work, by asking an AI agent to compose the services rather than wiring them by hand. Camera to viewer, stood up on infrastructure you control. And here is the one promise I will make about lock-in, then I will stop, because this post is about the tool, not the sermon: what you run on OSC is yours. The code is open, the components are open, and the thing you deploy is something you can take with you. We built Open Live so that owning your live production is the default, not a migration project you dread.
Try it, and build it with us
If you run live production and any of this resonates, I would genuinely like your hands on it. Spin up Open Live on OSC and run a stream through it, camera to browser. Or just read the repositories, open-live, open-live-studio, and strom, and tell us where we are still rough. That feedback is worth more to us right now than applause. If you want to help build the mature version, join the open-source effort. The broadcasters who shaped Open Intercom did exactly that, and Open Live will be better for the same reason. We built Open Live because we wanted a live production stack we could read, run, and own. It is open now. Come build the rest of it with us.
Frequently Asked Questions
What is Open Live?
Open Live orchestrates a live production: it takes your sources, lets an operator drive the production through a Studio UI, and runs the signal from camera to viewer. Underneath sits Strom, a GStreamer-based pipeline that handles ingest over SRT, transcode, vision mixing, and output.
Is Open Live really open source?
Yes. The repositories are public and you can clone them today: open-live, open-live-studio, and strom. It is not a closed appliance with an open-source sticker on it. You can read every stage, run it yourself, and adapt it to how you work.
How do I run Open Live?
You can bring up the full Open Live stack on Eyevinn Open Source Cloud. Because OSC is MCP-native, you can provision it by asking an AI agent to compose the services rather than wiring them by hand. What you deploy is yours, the code is open and the components are open, so you can take it with you.
How mature is Open Live?
This is a first open release and it is early. There are rough edges and we know where some of them are. It is real, runnable, and open, and it is an invitation to build the mature version of it together.
Related Posts
6 AI Agents. 14 Services. 36 Hours.
How Streaming Tech TV+ went from concept to fully deployed streaming platform — with zero manual infrastructure. A case study in what happens when AI agents not only write the code, but operate the infrastructure too.
Agentic SDLC: the Human-Gated AI Coding Pipeline on Open Source Cloud
An AI agent that triages issues, writes code, and proposes changes. A mandatory review gate that controls what deploys. An authorization model where the deploy token lives on the server and the agent never touches it.
Build Apps That Act on Behalf of Your Users with OAuth on OSC
OSC now supports an OAuth 2.0 authorization flow that lets your app authenticate other OSC users and operate inside their own workspaces. No shared credentials, no platform-level API keys. Each user owns their own resources.