akvirtualcamera: a virtual camera for Windows and macOS

A camera device, not an application

akvirtualcamera is a virtual camera for Mac and Windows, and the description is precise about how it achieves that. It is implemented as a DirectShow filter in Windows, and as a CoreMediaIO plugin on Mac.

That distinction is the whole design. It is not a program you open and point at something, and it does not capture or record. It registers itself with the operating system as a capture device, so it appears in the device list of anything that enumerates cameras: a video call, a broadcast tool, an image capture application, a test harness.

That gives it a reach that a virtual camera implemented as a window on top of a video stream cannot have. A filter or a plugin is enumerated by the platform's own media stack, which means the operating system's camera privacy settings, the device list in every application, and the standard capture path all work without the application knowing anything about it.

The topics attached to the repository match the implementation exactly, with coremediaio and directshow alongside macos, windows and virtual-camera. The primary language is C++, the licence is GPL-3.0, the default branch is master, and the last push was on 2026-05-15.

For the audience, the interesting cases are generating content, streaming with a second source, and testing camera handling in software. The project is hosted by the Webcamoid organisation, and the repository contains a capi directory alongside the platform code, which suggests a programmatic interface, though the readme does not describe one.

Two features: emulated controls and a default picture

The features list is short, and each entry solves a specific problem that a video stream cannot solve on its own. The documentation states it as follows.

akvirtualcamera is virtual camera implemented as a DirectShow filter in Windows, and as a CoreMediaIO plugin in Mac.
Supports emulated camera controls in capture devices (brightness, contrast, saturation, etc.).
Configurable default picture in case no input signal is available.

The first is support for emulated camera controls in capture devices, with brightness, contrast and saturation given as the examples. A real webcam exposes these controls, and applications expose a UI for them. A virtual camera that does not implement them appears to applications as a device with no adjustable properties, which is a difference users notice immediately and developers have to work around. Emulating the controls means the virtual device looks like a real one to the application.

The second is a configurable default picture, used in case no input signal is available. This is the fallback behaviour, and it is the detail that makes the device usable in practice. A virtual camera with no input has to show something, and showing nothing, or showing a black frame that the application then treats as a real signal, produces confusing failures. A configurable picture gives you a deterministic placeholder.

Together these two features say something about the intended use. The emulated controls are about compatibility with applications that expect a real camera. The default picture is about a device that is present and stable whether or not something is feeding it. Both are the small compatibility details that decide whether a virtual camera is usable in a test harness or a stream, rather than a curiosity.

Building it: CMake and four toolchains in CI

The build is a CMake project, and the readme does not attempt to document it. It sends you to the wiki for comprehensive compile and install instructions, which is a reasonable division of labour for something with this much platform variation.

What the repository does show is the shape of the build. There is a CMakeLists.txt at the root and a commons.cmake beside it for the shared configuration, and the top level is divided into a Manager directory, a Service directory and a VCamUtils directory, alongside the platform specific cmio directory for the macOS side, the windows directory, a ports directory, a share directory and the capi directory.

The status badges show how many toolchains the project keeps alive. There are separate workflows for Linux MinGW, for Mac, for Windows MSYS and for Windows MSVC, which is a good indicator of the range of environments the code is expected to build in, and of how much of the effort goes into keeping four build paths working rather than in the feature set.

There is also a Codacy grade badge and an OpenHub project statistics badge. The Codacy one in particular is a code quality signal that is worth a look before you build on this, since the repository also carries a ChangeLog, a CONTRIBUTING guide, an issue template, a pull request template and a SECURITY file.

The practical conclusion for an adopter is that this is a project where the wiki is the documentation, and where the build matrix rather than the feature list is the maintenance burden.

Installing it: releases, a daily build, and the wiki

Installation is where the readme is most terse, and that is a real limitation for anyone who wants to try it without reading the wiki.

What you are pointed at first is the releases page, and there is a separate daily build tag linked beside it, which is the automated build of the current branch rather than a numbered release. The readme also carries a total downloads badge fed from a release statistics service, so the download history is public and the daily build tag is a separate artefact from the versioned releases.

The version history is infrequent. Version 9.3.3 was published on 2025-10-31, 9.4.0 on 2026-03-23 and 9.4.1 on 2026-05-15, and the last push to the repository was on 2026-05-15 as well. So a gap of several months between releases is normal for this project, which means that a user who wants the current code has the daily build tag rather than the latest release.

One more thing the readme offers is a donations page, hosted on the Webcamoid site, which is the conventional arrangement for a project whose upstream organisation carries the running costs.

For a first use, the sequence is therefore: read the wiki for the platform you are on, take either the latest release or the daily build, install the driver or plugin, and confirm the device appears in your operating system's camera list before you try to use it in an application.

Where akvirtualcamera is the wrong tool

Four limits, and the first is about scope rather than quality.

It is a device, not a recorder. The documentation describes a capture device that appears in the camera list, and there is nothing in the feature list about writing files, encoding, or streaming. If what you want is a screen recorder or a virtual camera that also records, this is the wrong component and you would pair it with something else.

The second is that installing it is a system level operation. A DirectShow filter and a CoreMediaIO plugin are installed into the platform's media stack, not into an application directory, and the readme's decision to keep the instructions in the wiki rather than inline is a hint at the complexity. That makes it a poor fit for a shared or locked down machine, and a poor fit for an environment where a user is expected to install a driver.

The third is the platform coverage. Windows and macOS are the two supported targets, and the topic list says the same. A Linux user has no path here, and the Linux MinGW workflow in the status badges is a cross compilation check rather than a supported device, since the readme describes the filter and plugin only for Windows and Mac.

The fourth is the thin documentation. Two features, a link to a wiki, and a link to the issue tracker for bugs. There is no API description in the readme, no configuration reference beyond the default picture, and no explanation of what the capi directory exposes. Anyone planning to script against it is reading the source.

Licence, releases and the state of the repository

The licence is GPL-3.0, with a COPYING file at the root of the repository alongside the ChangeLog. The copyleft obligations are the usual ones for a driver or filter that a commercial application might link against or redistribute, so a company shipping a product that bundles this should take legal advice rather than assume the MIT terms of a comparable tool. This is not legal advice.

The version line is a 9.x series, with 9.4.1 the most recent tagged release on 2026-05-15, and the last push on the same date. The repository is not archived, and the daily build tag gives you a continuous artefact alongside the infrequent numbered releases. That combination is normal for a project that has to keep four toolchains building rather than one, and it is worth remembering when you decide which artefact to pin.

The project also keeps the housekeeping that matters for something that runs inside the operating system's media pipeline. There is a SECURITY file, an issue template and a pull request template, a CONTRIBUTING guide, a ChangeLog and an issue tracker that the readme points at for reporting bugs, along with a Codacy grade badge in the status section.

The one thing the readme does not do is document the feature set beyond the two lines, so a decision to adopt has to be based on the wiki and the code. Given that the device model, the emulated controls and the default picture are the whole point, that is a reasonable trade, but it does mean the evaluation takes longer than reading a readme usually does.

Editorial conclusion

akvirtualcamera is the right tool for a developer who needs a camera device to point at generated or synthetic content, for a streaming setup that needs a second capture source, or for testing an application that enumerates cameras, and it works on both major desktop platforms from one source tree. It is the wrong tool if you want to record video, since it is a device and not a recorder, and it is the wrong choice for a shared machine where installing a system level capture filter is more than you should be doing. Before adopting, read the wiki for the compile and install steps that the readme deliberately leaves out, and check the daily build tag against the last tagged release, since the releases are infrequent and the daily builds are where the current work lands.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. webcamoid/akvirtualcamera on GitHub