openvid: screen recording and mockup composition rendered entirely in the browser

Everything runs client side, and that is the whole premise

The README's pitch is one line: record your screen or upload a video, add smooth zooms, device mockups, 3D effects and custom backgrounds, then export a cinematic demo. The interesting word in the technology section is fully in-browser rendering for FFmpeg.wasm.

That single decision cascades through the architecture. Video processing is FFmpeg.wasm plus the Canvas API for preview plus MediaBunny as the video pipeline plus Three.js for 3D effects plus HTML to Image for mockup export. Storage is IndexedDB for locally recorded videos, LocalStorage for user settings, with Supabase Storage listed for cloud backups and marked coming soon.

So a recording never leaves the browser unless you deliberately move it. For product demo videos that contain internal UI, or for anyone with a policy against uploading screen content to a third party, that is not a nice to have, it is the feature.

The cost is equally concrete. Encoding a 4K H.264 file in a tab is CPU work on the client's machine, and the browser will sit there doing it. Anything that makes the export faster would have to move the encode to a server, which is exactly what this design refuses to do.

The application itself is a Next.js 16 project on React 19, written in TypeScript, with `app/` for routes, `components/`, `lib/`, `utils/`, `hooks/` and `types/` for code, plus `messages/` and `i18n.ts` for internationalisation. There is a `navigation.ts` at the root and a `proxy.ts`, both of which are new enough Next.js conventions to be worth noticing if you plan to upgrade.

The feature list is a spec for a video editor, not a mockup tool

It is tempting to read openvid as a screenshot tool with 3D decoration. The feature list is broader than that, and it is worth sorting into what the video timeline does versus what the canvas does.

Input is either browser screen recording with no installation required, or an upload in MP4, WebM, QuickTime or MKV. The timeline supports zoom in and out at specific moments, with speed and easing control, plus 3D camera movement described as tilt and dynamic rotation based on points of interest. Audio has multi-track support and an auto-trim based on video duration.

The canvas is a separate layer sitting over the video. Shapes include rectangles, circles and triangles. Text takes custom fonts, colours and sizes. SVG import brings in vector graphics, and PNG, JPG and WebP work as overlays. Backgrounds are 100 plus pre-designed options, plus custom images or Unsplash, plus solid colours and gradients. Mockups can be applied to images, and 3D transformations are a listed feature of their own.

So this is a compositor: a video track with camera moves, an overlay canvas with vector and raster elements, and a 3D layer that can bend the whole frame into a device shape. The screenshots linked from the README show a multi-track timeline, which is the part that makes it feel like a real editor rather than a preset generator.

Export settings, and why the format list matters

The export section lists five quality presets: 4K at 3840 by 2160 and 30fps, 2K at 2560 by 1440 and 30fps, 1080p at 1920 by 1080 and 30fps, 720p at 1280 by 720 and 30fps, and 480p at 720 by 480 and 24fps.

The format list is the more interesting half. MP4 with H.264 is the default choice, WebM with VP9 is offered and explicitly supports transparent background, then GIF, then PNG, WEBP, JPG and AVIF as stills.

Transparent WebM is the feature that distinguishes this from most screen recorders. A device mockup with the screen cut out is exactly the deliverable a hardware company or a mobile app team needs for a launch page, and getting alpha out of H.264 is not possible. The PNG, WEBP and AVIF stills cover the other half of that use case, exporting a single composited frame at high resolution for a design file or a social post.

The 24fps at 480p entry is a small tell about how the presets are chosen. Screen content does not need high frame rates, so the lowest tier is fine at 24 while everything above it runs at 30, which keeps file sizes down on the settings most people actually export.

Running it locally, and the API keys you need

The Quick Start is three commands in a fenced block, with comments:

pnpm install
cp .env.example .env
pnpm dev

That is genuinely the whole setup. The `package.json` pins the package manager to pnpm 12.3.4, and the dev script is `next dev`, so the dev server is localhost:3000.

The `.env.example` file is where the integration surface shows. It asks for `UNSPLASH_ACCESS_KEY` and `UNSPLASH_SECRET_KEY`, `PEXELS_API_KEY` and `PIXABAY_API_KEY` for stock imagery, `NEXT_PUBLIC_SUPABASE_URL` and `NEXT_PUBLIC_SUPABASE_ANON_KEY` for the Supabase side, `NEXT_PUBLIC_SITE_URL`, and a `GITHUB_TOKEN`.

Three image providers plus Unsplash is a deliberate choice about the backgrounds feature, and it also means you are signing up for at least two of them before the background picker is useful. The GitHub token is the least obvious entry and is presumably for fetching assets rather than for the editor itself.

The rest of the scripts are minimal: `build`, `start`, `lint` running eslint, and an `email` script pointing at `react-email` with a directory of email components.

The dependency list tells you what the 3D layer costs

It is worth reading `package.json` for what the graphics stack implies. `@react-three/fiber` and `@react-three/drei` provide the React bindings for Three.js, `three` is at 0.184 with `@types/three` alongside, and `three-stdlib` supplies the extra geometry and loaders. GSAP handles animation and `framer-motion` handles interface transitions.

Then the media layer: `@ffmpeg/core`, `@ffmpeg/ffmpeg` and `@ffmpeg/util` for the encoder, `mediabunny` for the video pipeline, `html-to-image` for turning DOM into an image, and `sharp` for image processing. `swapy` handles drag and drop rearrangement and `lenis` handles smooth scrolling.

Two entries deserve a second look. `@ffmpeg/core` is the WebAssembly build of the encoder, which is where the memory pressure comes from, and `mediabunny` sits alongside it as a second video pipeline library, so there are two abstractions over video handling in the same dependency tree. That may be a transition in progress or a division of labour between decode and encode, and the repository does not say which.

The UI side is a familiar stack: Radix UI primitives, `class-variance-authority` and `tailwind-merge` with `clsx`, `lucide-react` for icons, `leva` for a debug control panel, `driver.js` for onboarding tours, `next-intl` for translations, and Resend plus `@react-email/ui` and `react-email` for transactional mail.

The licence file exists, the metadata does not agree, and there are no releases

Two things about the project's status are worth stating plainly rather than glossing.

First, `LICENSE.md` is present in the repository tree, while the repository metadata reports no detected licence, which is what GitHub says when it cannot classify the file it found. This is not a licence you can assume. The README does not mention licensing at all, so there is no statement of terms anywhere except the contents of that file, which you should read before using this in work you own.

Second, the package is marked `private: true` at version 0.1.0 and there are no GitHub releases. The last push was on 2026-09-23 and there are no open issues, so the repository is being worked on, but there is no version history to pin against and no changelog to read.

Those two facts together describe an early project with real momentum and no stability guarantees. The application is unusually complete for a 0.1.0: the feature list reads like a shipped product, the stack is current rather than legacy, and there is a Discord community linked from the README. But the interface between the editor's internals and your own code has no contract behind it yet.

One more signal, small but telling: the storage section lists Supabase Storage for cloud backups and marks it coming soon. The feature is designed but not delivered, so treat any plan that depends on it as unbuilt.

Editorial conclusion

openvid is interesting because the entire pipeline, capture, composition, 3D preview and encode, happens client side, which means no upload bandwidth, no server-side render queue and no video leaving the machine. That also sets its limit: a 4K export on a laptop is FFmpeg.wasm working inside a browser tab, so render time and memory are your machine's problem, not a cluster's. Before you build on it, read `LICENSE.md` in the repository yourself, because the repository metadata reports no detected licence while the file exists, and the package is marked private at version 0.1.0 with no GitHub releases, which tells you to expect an interface that moves.

Frequently asked questions

Official sources

1. CristianOlivera1/openvid on GitHub
2. Issues
3. Project website
4. README