Two things in this stretch matter more than the version numbers. Capture now writes fragmented MP4, so a recorder that dies halfway through leaves you a playable file instead of a corrupt one. And the app finally installs the way people on each platform expect it to.
\nThat is v1.10.0, August 24. Before it, v1.9.0 through v1.9.6 in under two weeks.
\nA 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.
\nCapture 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.
\nThe 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.
\nMost of v1.10.0 was packaging. Distribution is where free desktop software quietly fails: the build works, and nobody can get it.
\nWindows. The appx goes to the Microsoft Store from the release build, with branded tiles. That is the route I'd recommend on Windows now. 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.
\nLinux. Fedora RPM (@Mundo-Dev0ps), ARM64 builds (@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.
\nmacOS. The Homebrew cask job runs again instead of sitting dormant.
\nCapture 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.
\nv1.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:
\nrecord, export and info, driving the same engine the app does, which makes OpenScreen usable from a script or on a server (@PeterTakahashi).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.
\nv1.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.
\nRoundness, 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.
\nmain right nowWebcam 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.
\nStill open: hardware encode on Linux, and measurements on discrete GPUs and QSV. It is still pre-1.x, so rough edges are expected and bug reports are welcome.
\nThree months, ten releases. Discord is open if you want to argue with any of it.
", "url": "https://getopenscreen.com/blog/2026/08/24/store-and-crash-safe-recordings/", "title": "Recordings that survive a crash, and an app you can actually install", "summary": "v1.10.0 put OpenScreen in the Microsoft Store, on Fedora and on ARM64, and made capture write fragmented MP4 so a helper that dies mid-recording leaves a playable file.", "date_modified": "2026-08-24T00:00:00.000Z", "author": { "name": "Etienne Lescot", "url": "https://github.com/EtienneLescot" }, "tags": [ "release", "distribution" ] }, { "id": "https://getopenscreen.com/blog/2026/08/04/local-whisper-and-a-rust-compositor/", "content_html": "Exporting a 1080p60 project with full effects used to run at about 8 fps. The same project now exports at about 126 fps on the same laptop. The bottleneck was never the encoder, which is the part of this worth writing down.
\nv1.8.0 shipped that on August 4, alongside an optional AI editing layer that transcribes and edits entirely on your own machine.
\nIt 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.
\nTurn it on and you get four things.
\nTranscription 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 it works offline.
\nEditing 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.
\nCaptions 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.
\nEditing 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 go in your OS credential store and requests go from your machine straight to the provider. There is no OpenScreen server in the middle, because there is no OpenScreen server.
\n1.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.
\nExport 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.
\nIt is one GPU-resident chain with no CPU readback between stages:
\ndemux -> 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.
\nPreview 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.
| Backend | Stack |
|---|---|
| Windows | Direct3D 11, HLSL, D3D11VA decode, hardware encode |
| macOS | Metal (all nine shader entry points ported to MSL), VideoToolbox decode/encode, CoreText text rasterizer |
| Linux | wgpu/WGSL, software H.264 encode, MP4 mux with AAC audio |
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.
\nProfiling 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.
\nSo 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.
\nHardware 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.
\nNext: v1.9.0 through v1.9.6 in twelve days, and v1.10.0.
", "url": "https://getopenscreen.com/blog/2026/08/04/local-whisper-and-a-rust-compositor/", "title": "v1.8.0, local whisper and a Rust compositor", "summary": "Export went from about 8 fps to about 126 fps, and the profile that explains why says the encoder was never the bottleneck. Plus an AI editing layer that runs on your own machine and stays off unless you turn it on.", "date_modified": "2026-08-04T00:00:00.000Z", "author": { "name": "Etienne Lescot", "url": "https://github.com/EtienneLescot" }, "tags": [ "release", "ai", "rendering" ] }, { "id": "https://getopenscreen.com/blog/2026/07/19/eight-first-time-contributors/", "content_html": "Two releases in the first month, v1.6.0 on July 4 and v1.7.0 on July 19. The second one is the one worth writing about. Eight people who had never touched the project shipped most of it, and several of those changes fix things that had been broken since before the archive.
\nThe 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.
\nThe 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.
\nThe 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.
\nThree 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).
\nIf 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.
Eight first-time contributors:
\nThe 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.
\nAn 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.
\nThat 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.
\nNext: v1.8.0, where an AI layer and a whole new rendering engine shipped under one version number.
", "url": "https://getopenscreen.com/blog/2026/07/19/eight-first-time-contributors/", "title": "v1.7.0 was mostly written by people I'd never met", "summary": "Eight first-time contributors shipped most of v1.7.0, including memory-safe handling of long recordings and a software H.264 fallback. Before it, v1.6.0 built the release process that made merging their work safe.", "date_modified": "2026-07-19T00:00:00.000Z", "author": { "name": "Etienne Lescot", "url": "https://github.com/EtienneLescot" }, "tags": [ "release" ] }, { "id": "https://getopenscreen.com/blog/2026/06/15/picking-up-openscreen/", "content_html": "The last commit on siddharthvaddem/openscreen landed on June 6, 2026. It bumped the Nix package to v1.5.0. Then the repo went read-only, like the README had been warning it would for a while. 39k stars, and v1.5.0 as the final release.
\nI 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.
\ngithub.com/getopenscreen/openscreen. It started as a personal fork and moved under the getopenscreen org in the first week. It stays there.
The archived original is still online and still read-only. Every commit of it is in this repo's history.
\nI 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.
\nForking 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:
\nThe 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.
\nFour 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.
\nThat'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.
\nI'll write up what ships and what breaks here. Next: v1.6.0 and v1.7.0.
", "url": "https://getopenscreen.com/blog/2026/06/15/picking-up-openscreen/", "title": "Picking up OpenScreen", "summary": "The original repo was archived after v1.5.0. I forked it, kept the name and the MIT license, and moved it to a new home.", "date_modified": "2026-06-15T00:00:00.000Z", "author": { "name": "Etienne Lescot", "url": "https://github.com/EtienneLescot" }, "tags": [ "announcement" ] } ] }