Clypra: a Rust and Tauri video editor with a GPU decode path

The gap Clypra is aiming at

Video editors split into two camps. Commercial NLEs give you a polished timeline and charge a subscription; free tools often wrap FFmpeg in a thin GUI and inherit whatever latency the wrapper adds. Clypra targets the second camp's weak spot: the README promises "sub-10ms frame decoding" and "GPU-native rendering" while keeping the whole thing under the MIT License with, in its words, "no watermarks, no paywalls, no feature limits, and no subscriptions required."

The intended user is someone editing on a laptop who wants scrubbing and playback that keep up with the timeline, and who is willing to run a young project. The repository's topics (tauri-v2, wgpu, wgpu-native, video-editor) and the dependency list make the audience explicit: this is also a project for developers who want to read the decoder pool or extend the React timeline, not only a binary for end users.

The claim worth scrutinising is the latency number. The README states it as a property of the engine, and the docs folder is said to hold a "Native Performance Contract" and a runtime performance architecture document. Those are the places to look for the conditions under which the number holds, because decode latency on a 4K H.264 stream and on a 1080p proxy are not the same measurement.

How the Rust core and the React 19 frontend divide the work

The architecture diagram in the README shows two halves joined by a Tauri IPC layer. On top sits the React and TypeScript frontend: the timeline UI, the preview canvas, and a filmstrip cache. Below it sits the Rust backend, which owns the decoder pool, the frame decoder and the export pipeline.

The decoder pool is the mechanism that matters. It is described as an LRU cache sitting in front of hardware decoders selected per platform: VideoToolbox on macOS, D3D11VA on Windows, VAAPI on Linux. That design choice explains the latency target. Keeping recently decoded frames in a bounded cache means a scrub backwards over already-played footage does not re-enter the decoder, and the hardware path avoids a CPU-side decode of every frame. The trade-off is memory: an LRU cache of decoded frames is expensive, and the README does not state the cache size or the eviction policy, so the memory ceiling at 4K is undocumented.

Export is a separate pipeline rather than a reuse of the preview path, which is the conventional split and the right one. Preview wants the cheapest frame that looks acceptable; export wants the exact frame. The repository layout backs this up: `src/` holds the React 19 frontend with Zustand state, and `src-tauri/` holds the native backend with FFmpeg and the Tauri IPC commands. There are also `crates/` and `android/` and `ios/` directories at the top level, and package.json pulls in Capacitor packages, which matches the README's claim of iOS and Android support through Capacitor.

Installing Clypra on macOS, Windows and Linux

The README's installation section is short and points at pre-built binaries on the releases page. For macOS it gives a Homebrew tap, for Windows an MSI, and for Linux an AppImage. The Linux instructions include the chmod step, which the README shows as `chmod +x` before running.

brew install AIEraDev/tap/clypra

That installs the macOS build from the tap named in the README. On Windows the documented path is downloading `Clypra-x64.msi` and running it; on Linux it is downloading `Clypra-x86_64.AppImage`, making it executable, and running it. The README does not describe a package repository for Linux distributions, so AppImage is the only Linux route it names.

Building from source is the better-documented path, and the prerequisites are explicit: Node.js 18 or newer with npm, Rust 1.70 or newer via rustup, and FFmpeg 6.0 or newer with development headers. The quick start clones the repository, installs dependencies, copies the example environment file, and starts Tauri in development mode.

git clone https://github.com/AIEraDev/clypra.git
cd clypra
npm install
cp .env.example .env
npm run tauri dev

The `.env.example` copy is not optional decoration: the README lists it as a setup step, and the telemetry section implies runtime configuration exists, so an empty or missing `.env` is a plausible first failure. There are also two setup scripts in package.json, `setup:ffmpeg` and `setup:sidecars`, plus a `verify:sidecars` check, which suggests the FFmpeg sidecar binaries must be fetched before the app will run. The README does not spell out the order, so a first build that fails on a missing sidecar should be diagnosed with `npm run verify:sidecars`.

Tests, type checks and the scripts that gate a change

package.json is the most concrete documentation in the repository, and it is worth reading before touching the code. The test story is split across two languages. Frontend tests run through Vitest, backend tests run through Cargo, and type checking is a separate tsc pass.

npm test
cd src-tauri && cargo test
npx tsc --noEmit
npm run format

The `test` script is not just Vitest: it runs `npm run typecheck` first and then `vitest run`, so a type error stops the suite before any test executes. There is a `check` script that chains a documentation link check, the type check and the tests, and a `test:all` script that adds an RC1 benchmark and a production build on top. Someone preparing a pull request should run `npm run check` at minimum; `npm run test:all` is the full gate and will take longer because it generates golden assets and runs the benchmark harness.

The presence of `RC1_SCORECARD.md` at the top level and a `benchmark:rc1` script tells you the maintainers treat release candidates as measured events rather than tags. That is a good sign for a project at version 1.5.3, but note that the benchmark scripts are Node scripts under `scripts/benchmarks/`, so reproducing the published performance claims requires the same golden assets the maintainers use.

The telemetry collector is the decision point

Clypra ships a performance telemetry collector, and the README is unusually direct about it. What it collects is numerical timing data: decode microseconds, compose microseconds, P95 seek latency, dropped frame counts, OS family, and GPU vendor and model. What it says it never collects is video frames, media assets, project titles, file paths, or user identities.

Two design details are worth noting. Sampling is adaptive: smooth 60 FPS playback is sampled at 1 percent, while dropped frames above 5 percent and driver fallbacks are captured at 100 percent. That is a sensible way to get signal on regressions without paying a frame-pacing cost during normal editing. The second detail is the analysis side. The README says aggregated metrics are reviewed in a separate repository, `AIEraDev/clypra-studio`, at a `/studio/admin` route.

This is where a reader should slow down. The privacy claim is a claim about what the code sends, and the README does not document an opt-out flag, an environment variable to disable the collector, or a first-run consent prompt. The telemetry specification is said to live at `docs/performance-telemetry.md`; that file is the thing to read before deploying Clypra in an environment with network egress rules. For a hobbyist editor the data described is benign. For a studio with client footage under contract, an undocumented always-on upload path is a procurement problem regardless of how little it carries.

Where Clypra is the wrong tool

The first limitation is maturity, and it is visible in the version history rather than in any disclaimer. Releases v1.5.1, v1.5.2 and v1.5.3 all landed within five days of each other in September 2026. Rapid patch releases after a minor version usually mean regressions are still being found by users. That is normal for a young editor and it is not a criticism of the code, but it does mean the version you install this week is not the version you will be running next month.

The second limitation is the plugin and integration story. The README lists no plugin API, no scripting interface, and no headless mode. The related searches include "clypra api", but the material describes Tauri IPC commands between the app's own frontend and backend, which is an internal boundary, not a public API for third parties. If your workflow depends on scripting an editor, generating timelines programmatically, or driving renders from a build server, Clypra does not document a route for that.

The third is the FFmpeg dependency and its licence. The README states plainly that FFmpeg dependencies are licensed under LGPL v2.1+ while Clypra itself is MIT. Those are compatible in the general case, but LGPL obligations attach to how the FFmpeg components are linked and distributed, and the repository carries a `THIRD_PARTY_LICENSES.md` file for exactly this reason. Anyone redistributing a modified Clypra build should read that file and the LICENSE rather than assume the MIT label covers every binary in the bundle.

Finally, the README does not document rollback, project file format compatibility across versions, or what happens to an in-progress project when the app crashes. For a tool that holds hours of editing work, the absence of any statement about project file stability is the biggest undocumented risk.

How Clypra differs from a plain FFmpeg frontend

The obvious alternative for a free editor is a GUI that shells out to the FFmpeg command line for both preview and export. The difference in approach is structural. A command-line wrapper treats each operation as a fresh process: seek, decode, write, exit. Clypra instead keeps a persistent Rust process with a decoder pool and an LRU frame cache, so a scrub reuses decoded frames instead of restarting a decoder. That is the whole reason the latency claim is plausible, and it is also why Clypra is harder to embed: a wrapper can be scripted and containerised trivially, while Clypra is a Tauri desktop application with a native backend.

Within the same architectural family, the alternative is another native editor, and the meaningful axis is what the frontend is built on. Clypra uses React 19 with Zustand for state and a Tauri v2 shell, which means a web developer can read the timeline code without learning a desktop UI toolkit. An editor built on a traditional native UI framework will feel faster to some users and will be far harder for a web developer to contribute to. The trade is contributor accessibility against platform-native feel, and Clypra has clearly chosen the former.

A third comparison is against hosted editors. Those remove the install problem entirely and put the decode work on someone else's GPU. Clypra's answer is local processing, which is why the telemetry section exists at all: the project needs aggregate timing data precisely because it cannot observe your machine the way a hosted service can. If your footage cannot leave your machine, local is the requirement and hosted tools are disqualified. If your footage is already in a cloud bucket, the local-only design is a constraint rather than a benefit.

Editorial conclusion

Clypra fits editors and developers who want a permissively licensed desktop NLE with a native Rust core they can read and modify, and who are comfortable building from source. It does not fit anyone who needs a stable plugin ecosystem, a documented API, or a no-questions telemetry posture, and it does not fit teams that cannot take on an LGPL v2.1+ FFmpeg dependency. Verify two things before committing: whether the frame-timing upload is acceptable under your own policy, and whether a pre-built binary exists for your platform, since the README points to the releases page rather than describing a verified install path for every OS.

Frequently asked questions

Official sources

1. AIEraDev/Clypra on GitHub
2. License: MIT
3. Project website
4. README
5. Releases