Version 2.1.6 swaps one source face into video or a camera
The open-source README identifies Deep-Live-Cam as version 2.1.6 and gives it two main jobs. Image and video mode writes a processed file, while webcam mode opens a live preview that can be captured with software such as OBS. A single face image supplies the replacement identity. Mouth masking can retain the original mouth, and face mapping can assign different sources to multiple people. The interface is the center of the maintained experience because the command-line argument list is explicitly labeled unmaintained.
That simple workflow sits on a substantial local environment. Our checkout contained 70 files, about 8,429 lines of source, and 67.7 MB before installation. It uses InsightFace-derived analysis, ONNX models, frame processors, and FFmpeg for media handling. The app can process on CPU or use hardware providers, but each provider changes the dependencies and troubleshooting path. A live preview is therefore closer to a local ML workstation app than to a small camera filter.
What happened when we ran it
Our sandbox installed 93 Python packages in 48 seconds and used 1,887 MB on disk. The build succeeded in 3 seconds. We ran commit bc48ba4 inside a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. The repository had one CI workflow, no Dockerfile, and a tests directory. These results describe repository setup only; the supplied run did not evaluate output quality, latency, camera compatibility, or any accelerator.
Pytest passed all 5 tests in 5 seconds, with 0 failures. Pip-audit found 0 known vulnerabilities in the installed packages. The complete test result is encouraging for the paths it covers, though 5 cases are a narrow safety net for a GUI that spans recorded video, live cameras, multiple face processors, and several hardware providers. The measurement does not include the separate model downloads or the runtime behavior of a generated face swap.
The open checkout and 2.7 Ultimate are different offers
The repository README says 2.1.6 at the top, while GitHub's latest release is 2.7 Ultimate, published August 1, 2026. That release sends users to the project's external site for a downloadable build and describes features that are absent from the 8,429-line checkout we measured. Buyers should not read the 2.7 release notes as a description of the open source at commit bc48ba4. Decide first whether you are evaluating the AGPL repository or the separately distributed Ultimate product.
This split also changes what 'three clicks' means. The README's three actions describe use after a working application and models are present. Manual source setup needs Python 3.11 to 3.14, FFmpeg, a virtual environment, and two named ONNX files placed in models. Our dependency installation alone occupied 1,887 MB. A commercial prebuilt may remove some setup effort, but its claims and terms need their own review because our sandbox tested the repository, not that download.
GPU support requires exact provider and runtime pairings
Nvidia instructions specify CUDA 12.8.0, cuDNN 8.9.7, a PyTorch CUDA index, and onnxruntime-gpu. CoreML, DirectML, and OpenVINO each replace the default ONNX Runtime package. The OpenVINO table pairs runtime 1.24.1 with OpenVINO 2025.4.1, with different pairings for 1.23.0 and 1.22.0. This documentation is useful, but it leaves the operator responsible for matching Python, drivers, runtime wheels, models, and hardware.
Open reports show why the exact combination matters. Issue 1819 says an Intel Arc A380 was detected but OpenVINO inference stayed on CPU. Issue 1816 reports that two GPEN enhancers crashed live mode on Apple Silicon because the caller passed an unsupported argument. Issue 1868 describes CUDA crashes during videos longer than 500 frames on a 6 GB GPU. None of those reports proves every machine will fail. Together they make a strong case for testing a full-length workload on the deployment hardware.
Two model downloads carry licensing and integrity questions
Manual setup asks users to obtain 2 ONNX files before the app can swap faces. The README credits InsightFace for its library and models and warns that model use is limited to non-commercial research. The repository itself is AGPL-3.0, but that software license does not cancel separate model terms. A company cannot infer commercial permission from the code license. Ask counsel to review every model and weight used in the final pipeline, especially if output will be sold or used for clients.
The same assets deserve a supply-chain check. Open issue 1890 points to macOS download code that creates an unverified TLS context and then stores model files without an integrity check. Pip-audit found 0 known package vulnerabilities in our 93-package environment, but that result does not inspect downloaded model bytes or transport code. Security-conscious users should obtain models through a verified route and record hashes before loading them. The project should publish trusted checksums and keep certificate validation enabled on every platform.
August 2026 activity coexists with unresolved live-mode reports
The last push was August 29, 2026, and GitHub listed 96,447 stars plus 41 combined issues and pull requests. Those figures show attention and recent maintenance; the combined open count is not a bug total. Current reports cover model parsing, face swaps that appear successful in logs but do not change the preview, accelerator selection, camera access, and crashes. A large audience helps surface hardware combinations, although it cannot substitute for broader automated coverage.
Deep-Live-Cam passed 5 of 5 tests in our sandbox, yet that test run never opened a camera or loaded the 2 required face models. Treat the project as a hands-on media experiment, not a verified identity system. Use only faces you have permission to use, label shared results as synthetic, and test the exact model, driver, provider, resolution, and video length you intend to run. The model license alone is enough for many commercial teams to stop before deployment.