One engine, many hosts
The SDK, the OBS plugin and the editing plugins all sit on the same C++ engine. What that buys us, and what it costs.
Published 21 de out. de 2026
The same beauty effect ships four ways: inside your app through the SDK, as an OBS filter, and as a plugin for the editing timeline. They are not four implementations that happen to look alike — they are one engine with four front doors.
What sharing an engine buys
The obvious win is that a fix lands everywhere. When face detection misbehaves on a profile view, the patch happens once, and the OBS plugin, the SDK and the desktop plugins all inherit it at their next release.
The less obvious win is consistency. A preset is a set of numbers, and those numbers mean the same thing on every host:
- iOS, Android, Web, Windows, macOS and Linux run the same effect chain.
- A LUT looks like the same LUT in a preview and in an export.
- Behaviour a customer verified in the demo app holds in their shipped build.
What it costs
One engine means one set of constraints, and the hosts disagree about almost all of them.
The GPU layer
Each host brings its own device, its own texture format, and its own idea of who owns the render loop. OBS drives the frame; the editing host may hand us a texture on a device we did not create; a mobile app runs on a background thread with a swapchain we do not control. The engine therefore never talks to an API directly — it goes through a thin RHI that each host implements.
The build matrix
A shared engine is only shared if it compiles and runs identically. That is the real cost: every change has to survive six platforms before it is “done”, and the slowest platform sets the pace.
| Host | Who drives frames | Extra constraint |
|---|---|---|
| SDK in an app | The integrator | Threading model is out of our hands |
| OBS filter | OBS | Qt6, plugin lifecycle, one render loop |
| Editing plugin | The host app | Offline and real-time paths must match |
A bug that only reproduces on one host is still an engine bug until proven otherwise. That default is expensive, and it is the reason the four products do not drift apart.
The part we got wrong first
Early on, host-specific behaviour leaked into the engine: a special case for one platform’s texture format, a fallback that only the OBS path hit. Each one was reasonable alone. Together they meant that “test it in OBS” and “test it in the SDK” verified different code. Cleaning that up was not a refactor for elegance — it was the only way to keep a single fix meaning a single fix.
If you are evaluating which entry point fits your product, the pricing page lists what each one includes, and the docs cover integration per platform.