Videorc optimizes its debug build, because an unoptimized capture path runs 50x slower

Two tracks, and the Windows one is not released yet

The release section splits the project in two, and the difference between the tracks is more informative than the feature list.

The macOS track is labelled Beta: macOS 13 and later, Apple Silicon, with signed and notarized beta builds as the current public desktop release. The Windows track is labelled Alpha, and the guide says Windows 11 x64 only. The condition on that word Alpha is spelled out rather than left to inference: a Windows installer is published only after the signed candidate, clean machine, malware scan, update, uninstall and real device acceptance gates pass, and a CI artifact or an unsigned local package is explicitly not a public alpha.

That is a release policy rather than a status label. Five named gates stand between a build and a download, and the sentence about CI artifacts closes the door on the usual workaround of shipping the pipeline output to a friend.

Both tracks are called pre-release software, with an expectation of fast moving releases, rough edges and occasional recording or streaming bugs while the app is being hardened. The last push to main is dated 1 October 2026 and there are no GitHub releases at all, so the beta is distributed from the project's own download pages rather than from a tag, which is consistent with a build that is signed and notarized on a schedule rather than cut per commit.

The Windows preview is called a proof surface, in writing

One feature bullet is about the preview window, and it reads like a legal disclaimer rather than a feature description.

On macOS the preview is a detached native CAMetalLayer surface. On Windows Alpha it is described as the documented uncompressed, latest wins Electron proof surface, and the README says in as many words that it must not be described as CAMetalLayer or as final native parity.

Three things are packed into that sentence. The Windows path is uncompressed, so it costs bandwidth and CPU that the macOS path does not. It is latest wins, so a frame that arrives late is discarded rather than queued, which is the right choice for a preview and would be the wrong one for a recording. And it is a proof surface, which is the project's word for something that demonstrates the pipeline works rather than something that ships as the final implementation.

The reason to take that sentence seriously is that it appears in a marketing document. A project comparing itself to other capture tools has every incentive to describe both platforms with the same adjective, and this one names the gap instead.

The same restraint shows up in the auto-update bullet, where signed notarized macOS builds update in place while Windows updating is a release candidate gate enabled only for an accepted, signed Alpha feed. The consequence for a user is concrete: on Windows there is no in-app update path yet, and the Alpha you are told to test is the update mechanism.

Electron and React on top, Rust and FFmpeg underneath

The how it works section is four lines and the split is the design.

The studio interface is an Electron and React shell in TypeScript with shadcn/ui components. The Rust backend owns capture, composition, recording and streaming, and the shell talks to it over an authenticated localhost WebSocket protocol. FFmpeg, an LGPL-compliant build that is bundled rather than assumed, drives encoding and output. And a local SQLite library holds the sessions, with the stated consequence that your recordings and AI artifacts stay on your machine.

Splitting a desktop app this way is a common choice with a specific cost, which is that everything crossing the boundary is serialised. A per pixel video pipeline plus a WebSocket protocol in the middle is a design that has to be justified, and the justification is in the repository layout rather than the README: a `neon.ts` at the root for a native Node addon, and a second workspace member called `videorc-native-preview-addon` alongside `videorc-backend`.

So the macOS preview is not an Electron canvas trick. It is a Rust addon compiled to a native module and loaded through Neon, which is what makes the CAMetalLayer claim and the Windows proof surface claim a difference in implementation rather than in marketing.

The authenticated localhost socket is the other line worth pausing on. A recording tool with a local control channel has to decide who may speak to it, and saying the protocol is authenticated rather than leaving it implied is the right way to start that conversation.

The dev profile is optimized on purpose

The Cargo workspace file is two members and a set of comments that read as a debugging diary, and the reason it exists is the most concrete engineering statement in the repository.

Incremental compilation is disabled for the whole dev profile. The comment says that on macOS arm64, stale incremental serde codegen artifacts have produced invalid links for the backend binary. That is a specific toolchain, a specific crate and a specific symptom, which means somebody lost an afternoon to it and wrote down the fix.

Then three opt-level overrides, all set to 2: the backend crate, the native preview addon, and a wildcard for every dependency. The reason is the sentence that follows: the backend runs real time per pixel work, with camera YUV to BGRA conversion at 4K given as the example, and an unoptimized debug build makes that about 50 times slower, hundreds of milliseconds per frame, which starves capture.

So `pnpm dev` is not a debug build in the usual sense. It is a release build with the debugging affordances, and the file says the runtime cost of that choice is small because the hot paths are GPU and hardware work anyway. The dependencies get the same treatment, with the reasoning that per frame work also happens inside serde event serialisation, the objc2 and Metal bindings, image encoding and tokio, and that optimising them costs one cached rebuild.

This is the single most useful thing in the repository for anyone trying to reproduce a bug, because it tells you the two builds you are comparing are not the same build.

One encode, local MKV, and a remux afterwards

The capture pipeline is described as record and stream in one pipeline, and the three outputs come from a single encode rather than from a separate recorder and a separate streamer.

The local recording is MKV, with an automatic MP4 remux afterwards, which is the arrangement a tool picks when it wants the recording to survive a crash mid write. Streaming is RTMP. Doing both at once is the interesting case, and it includes simulcast fan-out to multiple destinations with a per target health status, so one dead destination is visible in the interface rather than taking the stream down with it.

The quality numbers are specific and asymmetric. Streaming quality is described as free on every plan, up to 1080p60, with true 4K30 available on YouTube while other platforms ingest up to 1080p. So the 4K promise is a property of what the destination accepts, not of what the app encodes, and the README is clear about which is which.

Live captions are streaming speech to text at roughly a second of latency, and the burn-in choice has four positions: on the stream, on the recording, both, or neither. A second of latency is the number to judge the feature by, and a second is enough for a live caption and not enough for anything that needs word level accuracy.

Scenes are described as scenes rather than knobs: screen and camera, screen only, camera only, or side by side splits, with draggable camera placement, corner snapping, shapes and framing controls, plus a bring your own wallpaper option at PNG, WebP or JPEG with one slider for visibility or none at all for a full bleed recording.

The AI half needs an account, and consent is per session

The open source and pricing paragraph is where this project is most careful, and it draws a line in a place most tools do not.

The desktop application, which is capture, scenes, recording, streaming and the captions interface, is free software under AGPL-3.0, and the stated benefit is auditability: you can build it, run it, and read every line that touches your camera, microphone and screen. That claim only makes sense for the local half, which is why the next sentence matters.

The cloud AI features, meaning transcription, titles, chapters and highlights, run through a signed in Videorc account. The desktop app never holds AI provider keys, and nothing is uploaded without explicit per session consent. Local audio extraction works with no account at all, and the README closes the pricing question by saying hosted AI is what funds the project.

So the architecture is a local capture and encode path that is auditable, and a hosted model path that is not, with the boundary marked rather than blurred. The post-recording AI bullet says the same thing from the feature side, describing explicit consent and post recording only, and listing what comes out: a transcript, title and description suggestions, summaries, chapters, highlights, and an exportable publish pack.

The licence has a second half that is easy to miss. The code is AGPL-3.0, but the brand is not part of the code licence: the Videorc name, logo and app icon sit outside it, and TRADEMARK.md is the file to read before distributing a modified build. The bundled FFmpeg is LGPL-compliant, with the third party licensing notes in the distribution document.

The verification loop includes a lint rule against em dashes

The development section is unusually specific about how a change gets checked, and the short loop is the whole contribution story:

pnpm typecheck
pnpm build
pnpm smoke:dev          # records a test-pattern MKV per layout preset — no permissions needed
cargo fmt --check
cargo test
cargo clippy -- -D warnings

The comment on the smoke test is the important part. It records a test pattern MKV per layout preset, and it needs no camera, microphone or screen permissions, which means the test suite runs on a build machine and in CI without anybody consenting to be recorded. The full non packaged acceptance gate that CI runs is a single command, `pnpm smoke:local-gates`.

Then there are the named smokes, and they are named after the failure they exist to catch. `pnpm smoke:multistream` proves simulcast fan out end to end against local RTMP listeners, including what the README calls the offline destination failure guarantee, so a stream pointed at nothing is a tested case rather than an anecdote. `pnpm smoke:packaged` exercises a packaged build, because a packaging bug does not show up in a dev run. The Windows installer lane adds `pnpm smoke:windows-native-screen` against DXGI with a gdigrab fallback, and keeps the packaged proof preview live during a real screen only recording.

The lint script is where a detail worth reporting lives: running lint is eslint over the desktop sources and then a second command called `check:em-dashes`. A source tree that fails on a typographic character is enforcing a writing style in code comments and commit messages, and the rule survives in the lint script rather than in a style document.

Node 24, pnpm 11, and a dependency store in the repository

The toolchain is pinned in four places at once, and the root directory says the project is mid scale rather than starting out.

The package manifest is private, at version 0.9.0, licensed AGPL-3.0-only, and it pins the package manager to pnpm 11.0.9. The engine floor is Node 24 and no lower, with the upper bound at 25, and pnpm itself is held between 11 and 12. Alongside that in the same tree there is a `.node-version` file and a `rust-toolchain.toml`, and the README says those checked in fields are what keep local tools aligned with CI, with Corepack installing the pinned pnpm. The development loop is four commands:

corepack enable
corepack install
pnpm install
pnpm dev

FFmpeg is handled differently per platform, which is the kind of asymmetry that only shows up when a project supports both. macOS source development uses whatever FFmpeg is on `PATH`, while Windows fetches the pinned LGPL bundle with a dedicated script, and a local unsigned macOS bundle has its own two commands, one that builds or reuses the bundled FFmpeg and one that packages the desktop app.

The directory listing is where the size of the project shows. There are `apps/`, `crates/`, `docs/`, `scripts/`, `assets/`, `config/`, `changelog/`, `plans/`, `vendor/`, `patches/` and `protocol-fixtures/`, alongside a `.pnpm-store/` directory and a `skills-lock.json`. A committed package store and a lockfile for skills are the marks of a project that has decided reproducibility is worth the disk, and `protocol-fixtures/` is a test suite for the WebSocket protocol that the shell and the backend agree on.

Editorial conclusion

Videorc fits a creator on an Apple Silicon Mac who wants one window to record a screen and camera, simulcast to several destinations, and finish with captions and a publish pack without handing their screen to a hosted service. It does not fit anyone who needs the Windows build today, since that track is an Alpha behind a signed candidate gate, and it does not fit someone who wants the AI features without an account. Before installing, decide which track you are on, read TRADEMARK.md if you intend to redistribute a build, and expect the AI step to be a network round trip rather than a local model.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. TheOrcDev/videorc on GitHub