The result was two rules kept out of ten, and thirty findings. The fixes are gathered in one branch, #814, which is what v2 will be.

The audit​

Ten rules, each written as something a user should be able to rely on. Defaults that look good. Every value bounded, with a way back to its default. A format change or a cut that breaks nothing. What you see in the preview is what you export.

Measured on the build of that day, the defaults failed first:

• The default cursor was 82 px tall in a 1080p export, about four times the system arrow, and it could be pushed to 272 px.
• The default shadow drew at 9% opacity, which on most wallpapers means no shadow at all.
• A 16:9 recording exported as 9:16 filled 20% of the frame.

None of those is a bug in the usual sense. Each one is a setting that works as written and makes the video worse.

Twenty-one pull requests, one branch​

The findings split into six workstreams, and each became a pull request against a shared integration branch instead of main. They touch the same panels and the same compositor, and landing them one by one would have meant a week of broken intermediate states on main. Merged into one branch in dependency order, they can be tested together and land together.

Defaults. The cursor is half its old size, 41 px in 1080p. The shadow is at 27% opacity. New projects start from the look of your last one.

Bounds in the model. One table clamps every appearance value, whoever writes it: the panel, the AI agent, a preset or a hand-edited project file. Every slider has a reset.

The render tells the truth. Two findings were the kind you only see by measuring. Every text font exported as Segoe UI, pixel for pixel, because the picker offered fonts the app never shipped; five open-licensed families are embedded now. Gradients used only their first and last colour stops, so a red, green and blue gradient drew purple at its midpoint where green belonged.

Export. The bitrate the app computed never reached the encoder, so every export ran at 8 Mb/s whatever the frame rate. It is 18.7 Mb/s at 1080p60 now. GIFs are dithered, and the dialog offers four destinations (Web / YouTube, Social, Studio, README GIF) with the codec details folded under Advanced.

Audio. Voice is normalised to −16 LUFS with a soft limiter instead of a hard clip, and music ducks under it.

Framing. A 16:9 take in a 9:16 export now fills 64% of the frame, in a window that follows the cursor. Zooms are capped at twice the source's own resolution, so a deep zoom no longer magnifies blur. Silence cuts keep 70 ms of breath on each side, so a cut doesn't clip the start of a word.

One thing went the other way. The 17 third-party cursor packs are gone: their terms don't allow redistribution. Five original themes replace them.

Then the interface​

With the rules holding, the panels were the next thing to make ugly by accident. The branch this post was written on carries about a hundred and twenty more commits, and most of them delete something.

One click per choice. The selects and dropdowns in the right panel became rows of buttons, so every option is visible and picking one is a single click: format, frame style, the zoom's 3D camera, focus mode, cursor style, caption language and font. Only the fifteen translation targets stay a list.

Names instead of numbers. A shadow is None, Light, Medium or Strong. Click bounce is None, Light or Strong. A slider stays where the amount is the point (padding, background blur, cursor size), and a slider with no unit shows no number.

No explanations under settings. If the label needs a sentence to be understood, the label is wrong. An option that does nothing in the current context is hidden instead of greyed out with its reason.

Fewer controls. The Fit button rewrote four settings without naming any, and padding at 0 already does its job, so it's gone. The seek bar under the transport repeated the ruler right below it, so that went too.

A timeline you read by colour. The recording is the main object on the timeline, so it wears the brand's green. Zoom pills are blue, so the most common effect never reads as the clip under it. Every block is a solid card with dark text, because mint can't carry white: 2.3:1 contrast with white text, 8.2:1 with dark ink.

The walkthrough on the home page and this site's docs were redrawn to match.

The 3D camera​

The 3D work followed the same rule. A camera that rolls during a zoom looks broken rather than cinematic, so a moving camera never rolls now. The fixed angles went through three versions in a day before landing back on the v1.13.0 angle, checked against a real v1.13.0 export rather than from memory. The follow camera became 3D Orbit, which obeys the zoom's focus mode like the flat zoom does. The 3D cursor dives onto each click in depth, and the click impact that used to live on the zoom is a cursor setting for every camera.

Before v2 ships​

#814 is open, and green except for one compositor test on Linux and macOS that checks the 3D cursor's footprint. After that, it needs a manual pass on real Windows and macOS machines, then the usual release candidates.

It is still not production-grade, and rough edges are expected. If a default still makes your demo worse, that is exactly the bug this release is about: Discord or an issue, either works.

So the comparison is public now: screen-recorder-benchmark. Same clip, same edit, same machine, across the desktop apps built to turn a recording into a finished demo. OpenScreen is one of the tools in it, alongside Cap, FocuSee, Recordly and Screen Studio, and the standings are whatever the submissions say.

The current standings (lower is better)​

Read the ratio, not seconds. Each figure is an export divided by what a plain ffmpeg transcode of the same clip needed on the same machine, measured minutes earlier. A tool at 1.5× did 50% more work than a bare re-encode, on whatever hardware you have. Seconds only ever compare a machine to itself.

The scenario is a finished demo rather than a transcode: a sampled wallpaper, padding, rounded corners, a drop shadow, three animated zooms, motion blur, a cursor redrawn from telemetry, a webcam inset with mask and shadow, and the recording's audio, all pinned to 1920x1080 at 60 fps in H.264. How the current OpenScreen release renders that is in the export docs.

Four decisions that make it hard to fake​

ffmpeg is the 1x, and it is not a competitor. The reference is re-measured on your machine, under your load, immediately before each tool runs. Nothing is normalised against a number I recorded once on a laptop I own.

No tool is required in a submission. Tools are nodes, every pair measured together on one machine is an edge, and the ranking is recovered by least squares across the whole graph. Two people who never measured the same app still contribute to the same ordering, as long as the submissions overlap somewhere.

The verifier decides what happened, not the app. Every export is re-probed before it counts: resolution, frame rate, codec and duration against the target, then wallpaper, padding, corner radius, zooms, cursor and camera checked in the pixels, then audio by loudness, because a silent track passes any check that only asks whether audio exists. A tool reports what it configured. The verifier reports what came out, and the verifier wins.

The disagreement is published above the ranking. Where one pair of tools was measured on more than one machine, the two ratios can differ by more than the gap the ranking puts between them, and that spread is printed at the top of the page rather than in a footnote. A single global order is not yet what this data supports, and the page says so before it shows you one.

Roster membership follows what a tool is for, not whether I managed to automate it. An app I cannot drive is an empty cell, and an empty cell is a result.

Add a machine​

The hardware coverage is thin, and it shows in the spread above. A run needs any two tools and takes one command:

node bench.mjs run --bundle commons-upload --apps <two or more tools>
node bench.mjs submit --run <runId> --as "your name" > submissions/<platform>/<chip>-<date>.json

Open a pull request. CI validates it against the schema and regenerates the site, so the table on this page moves as soon as it merges. The footage comes from permanent Wikimedia URLs with a hash, so two machines can prove they measured the same thing. It is MIT, and the results page is the repo's own output: EtienneLescot/screen-recorder-benchmark.

Building it this way meant accepting the answer before knowing it, on every machine anyone adds. A benchmark whose author always wins is a marketing page.

That is v1.10.0, August 24. Before it, v1.9.0 through v1.9.6 in under two weeks.

Losing a recording used to be possible​

A screen recorder that can lose the take is not a screen recorder. The old capture path wrote a single MP4 whose index is finalised at the end, so a helper crash, a forced quit or a dead battery left a file no player could open. The recording had happened. It was just unreadable.

Capture on Windows and macOS writes fragmented MP4 now. The file is valid at every fragment boundary, so whatever was captured before the process died is still there and still plays. Linux still writes a plain MP4, so a crash there can still cost the file.

The same release stopped two other ways to lose work. The native webcam stream writes to disk while it records, so killing a recording can't take the camera track with it, and the Windows capture helper stopped hanging on stop, which used to require killing the process and losing the file.

Where you can install it now​

Most of v1.10.0 was packaging. Distribution is where free desktop software quietly fails: the build works, and nobody can get it.

Windows. The appx goes to the Microsoft Store from the release build, with branded tiles. That is the route I'd recommend on Windows now, and the installation docs walk through it. winget stopped skipping silently. There is no Visual C++ Redistributable dependency any more, and the OpenMP runtime the transcription backends actually import is bundled, so transcription works on a clean machine.

Linux. Fedora RPM (@Mundo-Dev0ps), a source build that completes on ARM64 machines (@zebster-cmd), and DMA-BUF negotiation so capture works on niri and other wlroots compositors, which had no working screen recorder from this project at all. Packages now respect the glibc floor of the distros they claim to target, declared and proven on a clean machine, and AppStream metadata is in place for Flathub. The released packages, all x64, are on the download page.

macOS. The Homebrew cask job now reports that it published nothing, instead of passing silently.

Capture is also DPI-aware and stops guessing which monitor you meant, and there is a GPU DXGI encode path behind a flag, opt-in until it earns the default.

v1.9.0, three weeks earlier​

v1.9.0 shipped August 5, the day after v1.8.0 was promoted. That is a backed-up queue rather than speed: the 1.8.0 RC window ran through nine candidates while main kept moving. The frozen release branch is the only reason the two didn't tangle.

Two features in it:

• Teleprompter mode in the notes window. Your script scrolls next to the capture, mirrored so it reads right in a webcam (@My-Denia).
• A CLI with record, export and info, driving the same engine the app does, which makes OpenScreen usable from a script (@PeterTakahashi). Recording still needs a real desktop session, as the CLI docs explain.

It also removed a PID-file instance lock that could permanently brick startup, notarized macOS RCs like stable builds, and made the AppX package declare all 13 locales instead of one.

What changed in the patch releases​

v1.9.1, v1.9.2, v1.9.5 and v1.9.6 went out over ten days. 1.9.3 and 1.9.4 never left RC and their fixes rolled forward.

Roundness, shadow and motion blur are on by default now, which is the look most people were assembling by hand on every project. The Windows cursor sampler became DPI-aware. The chat agent learned addTrims and addZooms, so asking it for a cut stopped costing a round trip through a slower path.

Every release's regression pass is written up in the repo's testing docs, including the ones that caught a candidate breaking something. This site was rebuilt in the same window, and gained its light theme.

On main right now​

Webcam background effects have landed on all three compositor backends. Blur or replace what is behind you, including an AI cutout that doesn't need a green screen. The transcription helper reports its real timing and which compute backend it used, so "how long will this take" has an answer instead of a progress bar with no scale.

Still open: hardware encode on Linux, and measurements on discrete GPUs and QSV. It is still not production-grade, so rough edges are expected and bug reports are welcome.

Three months, ten releases. Discord is open if you want to argue with any of it.

v1.8.0 shipped that on August 4, alongside an optional AI editing layer. It transcribes on your own machine, and chat edits go to the LLM provider you connect.

The AI layer​

It is off by default. If you never turn it on, nothing downloads, no model is contacted, and you have exactly the 1.7.0 feature set. That was in the roadmap from week one and I don't intend to change it.

Turn it on and you get four things.

Transcription on your machine. Whisper via whisper.cpp, with Metal on Apple Silicon, Vulkan on Windows and Linux, CPU everywhere else. DTW word timestamps. Nothing is uploaded, and after a one-time model download it works offline.

Editing through the transcript. Select words, delete them, the span is cut from playback and export. Word boundaries get re-anchored against the audio so the cut lands where the word actually starts.

Captions derived from the transcript, instead of generated once and then maintained by hand. Restyle or regroup them with no regeneration step. Translation into 15 languages if you want it, through the LLM provider you connect for chat. The captions docs cover styling and translation.

Editing by chat. Describe an edit in plain language and an agent applies real timeline operations: cuts, zooms, speed ramps, annotations, camera framing. Ctrl/Cmd + Z undoes an agent edit the same way it undoes yours, with per-message rewind.

The chat uses your own LLM key. Anthropic, OpenAI, Google, Mistral, OpenRouter, MiniMax, or anything OpenAI-compatible. Keys are stored encrypted through your OS's credential protection, and requests go from your machine straight to the provider. There is no OpenScreen server in the middle, because there is no OpenScreen server. Setup is in the AI editing docs.

1.8.0 also removed the ChatGPT and GitHub Copilot sign-in options the pre-fork codebase had. Using someone's existing subscription there meant shipping GitHub's and OpenAI's own client IDs against endpoints they reserve for their own clients, from inside a signed installer. I didn't want to be in that position. If those vendors open a sanctioned surface, the integrations come back.

The compositor​

Export at 1080p60 with full effects ran at roughly 8 fps. The same project now runs at roughly 126 fps on the same laptop, an AMD Ryzen 5 7520U with its passive integrated Radeon. That machine is deliberately weak. Your number will be different. The order of magnitude is the point.

It is one GPU-resident chain with no CPU readback between stages:

demux -> hardware decode -> GPU composite -> RGB to NV12 -> hardware encode -> MP4 mux

I didn't set out to rewrite it. I first rebuilt the Canvas2D compositor to cache by what invalidates a cache instead of by layer. That was worth about 2x, and I verified it byte-identical (SSIM 1.000000 across all 1418 frames of the reference export). What it really did was make the profile readable: compositing was 79% of the time, encoding was 4.5%. The bottleneck was the compositor, running on the CPU inside a browser.

Preview and export now both consume the same SceneDescription the app builds, so there is no second renderer to drift. The frame in the editor is the frame that gets written.

Three backends​

There is a CPU backend too, software render and decode, picked automatically when there is no usable GPU. The UI tells you when you are on it, so a slow export has a visible reason.

The macOS decode detour​

Profiling the first working Metal export showed 74% of wall time in decode. The compositor was at 0.2 ms/frame. The hardware decoder pays a fixed per-frame latency, and OpenScreen's own capture writes Constrained Baseline H.264, which software decodes in a few hundred microseconds.

So the decoder is picked by profile now. Baseline goes to software, which came out 2.4x faster end-to-end on the test export (182 fps against 76). High, HEVC and 4K go to VideoToolbox, where the arbitration flips the other way.

Still open​

Hardware encode on Linux. It is correct today and slower for being software. And every number above comes from one weak laptop, so discrete GPUs and Intel QSV still need real measurements. Update, September 2026: since v1.11.0, H.264 export on Linux uses VAAPI when the driver and GPU support it, and falls back to software otherwise. H.265 on Linux is still software. The export docs cover the render path, and the download page has the current release.

Next: v1.9.0 through v1.9.6 in twelve days, and v1.10.0.

v1.6.0, so that merging is safe​

The fork inherited a codebase with no release candidate process. Merging a stranger's PR into a project with no RC step means the first person to find the regression is a user, so this came first: RC tags, a promote workflow, release notes generated from the PR history.

The Windows Graphics Capture helper, the native code that does the actual recording on Windows, got per-step stop timing and a diagnostic tool. "Recording fails on stop" is not a fixable bug report when all you know is that it failed, and it was the most common one.

The Linux HUD got its drag handle back. The overlay's pointer-events handling made the bar unmovable there, which nobody had noticed because nobody on the original team ran Linux.

Three PRs from outside landed in this one: the macOS cursor offset in single-window capture (@giulio333), copy/paste for timeline region attributes (@446f6e6e79), and a CI refactor (@psychosomat).

The release branch rule​

If you maintain something with a promote step, this is the part to steal. One release branch per stable version, cut at the RC, frozen until promote. Only cherry-picked bugfixes land on it, and anything merged to main after the cut ships in the next cycle.

I wrote that rule after the promote workflow tagged the tip of main instead of the RC snapshot people had tested. The release went out containing commits nobody had signed off on, and I replayed it. The rule is in the repo docs now and every release since has followed it.

v1.7.0​

Eight first-time contributors:

• Large recordings stream instead of loading into memory. The editor and exporter used to run out of RAM on long captures, which made the app unusable for exactly the recordings people care most about (@rainyflash).
• A software H.264 fallback for Windows machines whose hardware encoder is missing or locked, which is a large share of corporate laptops (@My-Denia).
• The webcam recorder now starts after native macOS capture does, so the first seconds of camera footage stop vanishing (@josiahcoad).
• A fix for the cursor drifting out of place after a crop (@SakuraiSatoru).
• A notes window that capture ignores, so you can keep your script beside the recording without it showing up in the video (@Itzadetunji).
• Playback speed up to 100x, for finding the one moment you want in an hour of footage (@rainyflash).
• The Full Camera timeline effect. Press a key and the webcam PiP grows to fullscreen for a stretch, then eases back (@rodrvc).
• A custom gradient editor for backgrounds (@psychosomat).

The platform work in that release was mine. Preview recovery from WebGL context loss on Linux and Wayland. Vulkan off on Wayland so PipeWire capture can import DMA-BUF frames. webm duration patching rewritten so hour-long recordings stop killing the editor on load.

Full Camera and speed regions are covered in the timeline docs, and the download page has the current build.

Why this matters more than the feature list​

An archived repo with 39k stars has a lot of people sitting on fixes they wrote for themselves and never upstreamed, because there was nobody to merge them. Reopening the repo released about a month of accumulated work in two weeks, from people who had already done it.

That is the argument for continuing an archived project rather than starting a new one. The users are already there and some of them are already contributors.

Next: v1.8.0, where an AI layer and a whole new rendering engine shipped under one version number.

I picked it up on June 15, with the original author's approval. Same name, same MIT license, new URL. This post starts a journal of what happens next.

Where it lives now​

github.com/getopenscreen/openscreen. It started as a personal fork and moved under the getopenscreen org in the first week. It stays there. Installers are on the download page, and the docs cover installing, recording, editing and export.

The archived original is still online and still read-only. Every commit of it is in this repo's history.

I tagged v1.5.0 on day one with no code changes at all. Same code, same installer, same version number. It only exists to prove the release pipeline works on my infrastructure before anything real ships through it. v1.6.0 is the first release with new work in it.

What I'm committing to​

Forking a popular archived project is a good way to quietly turn it into something else. So, written down where you can hold me to it:

• Free forever, MIT. No paid tier, no premium features, no usage caps. Nothing is gated on who you are.
• Stability before features. The recorder has to work on macOS, Windows and Linux. Bugs from real users go first.
• It's not production-grade, and I'll keep saying so. Expect rough edges and breaking changes, including to the project format.

The roadmap is public: record, edit, export, plus an optional AI editing layer that's off by default and never required. There's a Discord with a roadmap channel if you want to argue about any of it.

It already had contributors​

Four days in, before I'd shipped anything, someone I'd never met opened a fix for exports stalling when trim regions leave long decoder gaps. Real bug, correct diagnosis, regression test included.

That's roughly what the job turned out to be. Very little of it is features. Mostly it's release candidates that mean something, CI that fails loudly, and diagnostics for the parts that break on other people's machines. Native capture on Windows and macOS is as finicky as its reputation.

I'll write up what ships and what breaks here. Next: v1.6.0 and v1.7.0.