Deep-Live-Cam pins three onnxruntime builds in one requirements file and ships weights from a second host

The README heading says 2.1.6 while the newest tag is 2.7.5 Ultimate

The top of the file is an h1 reading Deep-Live-Cam 2.1.6, and that is the only version number most readers will carry away. The release tags say something else: 2.7-RC1 dated 2026-05-20, 2.7-ultimate dated 2026-08-01, and 2.7.5-Ultimate dated 2026-09-07. So the written instructions and the shipped code are separated by six minor versions, and the last push to the default branch is dated 2026-09-26, three weeks after the newest tag. The tags are not internally tidy either, because the tag named 2.7-RC1 carries a release title reading 2.7-RC6. Consequence for a reader: install by tag, not by the number in the heading, and read the tag string literally, because a tag called RC1 is not the same artifact as a release titled RC6 and the visible text gives you no way to reconcile them. The same split runs through the rest of the file, since the pre-built section advertises 2.7.5 Ultimate for five hardware targets while the manual instructions underneath were written for a different number entirely, so the two halves of one README describe two different products.

One requirements file resolves three different inference engines

The dependency file does not pin onnxruntime once. It pins it three times, on platform markers.

onnxruntime==1.28.0; sys_platform == 'darwin' and platform_machine == 'arm64'
onnxruntime==1.23.0; sys_platform == 'darwin' and platform_machine != 'arm64'
onnxruntime-gpu==1.26.0; sys_platform != 'darwin'

An Apple Silicon Mac gets onnxruntime 1.28.0, an Intel Mac gets 1.23.0, and every non-macOS platform gets the GPU build at 1.26.0. That last marker is the one to read twice, because sys_platform != 'darwin' has no GPU condition in it. Consequence: a plain `pip install -r requirements.txt` on a Linux box with no NVIDIA card installs onnxruntime-gpu anyway, on the same command line where the README says you can run the project with `python run.py` if you have no GPU. Two Linux users, one with a card and one without, run the same wheel and are expected to take different paths through it. The same file also requests opencv-python and opencv-python-headless at an identical 4.14.0.94, and those are two distributions that install into the same cv2 import name, so a fresh environment ends up holding both rather than one or the other.

The weights are downloaded from a second host, so the clone is not self-sufficient

Step three is two files, gfpgan-1024.onnx and inswapper_128_fp16.onnx, fetched from a Hugging Face repository and placed into a models folder. A models directory exists in the tree, but the bytes are not in the repository, and the install also clones shallow.

git clone --depth 1 https://github.com/hacksider/Deep-Live-Cam.git
cd Deep-Live-Cam

The run note adds that initial execution will download models, about 300MB, so there is a second fetch at first launch as well. Consequence for a reader: you have three separate download steps, the code from GitHub and the weights from Hugging Face, and nothing in the visible text pins a revision, checksum or file size for the two ONNX files, so two people installing on different days can end up with different weights and no record of which. The AGPL-3.0 grant in this repository covers the code in it, and the visible text says nothing about the terms attached to the two model files you fetch separately.

ffmpeg is a prerequisite given as remote code piped into iex

The platform setup step lists Python, pip, git, ffmpeg, and the Visual Studio 2022 Runtimes on Windows. Three of those are ordinary. ffmpeg is not: it is written as a PowerShell expression, `iex (irm ffmpeg.tc.ht)`, which fetches a script from a host and evaluates it in the current shell. There is no package manager call for it, no version, and no checksum, even though ffmpeg is the component the video path depends on. Consequence for a reader: you are asked to run remote code as a prerequisite, on a machine that is by design pointed at a live camera, and the visible text offers no alternative command for people who would rather install ffmpeg from their own package manager. It is also a Windows shell idiom sitting in a list that also has to serve macOS and Linux, which get no ffmpeg line at all.

The documented environment repair installs two packages from git master

There is a recovery block for when the virtual environment goes wrong, and the last four lines of it are the interesting part.

pip install git+https://github.com/xinntao/BasicSR.git@master
pip uninstall gfpgan -y
pip install git+https://github.com/TencentARC/GFPGAN.git@master

The block is labelled as a gfpgan and basicsrs issue fix, and it sits after the instruction to delete the venv and rebuild it. So the prescribed repair for a broken environment is to install two packages from the master branch of two other repositories, uninstalling the PyPI version of one of them first. Consequence for a reader: nothing in that block is pinned, so the same repair performed on two different days installs different code, and a fix for one symptom changes the dependency set in a way the requirements file does not describe. Anyone reproducing your environment from a bug report will not reproduce the same tree.

The built-in check filters nudity and graphic content, and consent is not in its list

The disclaimer is specific about what the guard rail does. A built-in check prevents the program from processing inappropriate media, and the named categories are nudity, graphic content, and sensitive material like war footage. opennsfw2 is pinned in the dependency file, which is the classifier doing that work. Nowhere in the visible text is consent a category the check can see. The same section says users must obtain consent before using a real person's face and must label output as a deepfake, adds that the project is not responsible for end-user actions, and reserves the right to shut the project down or add watermarks if legally required. The feature list includes a use case built around surprising strangers on a video chat service. Consequence for a reader: the automated check is a content classifier, not a consent system, and the one category it cannot detect is the one the disclaimer asks you to handle yourself.

The Ultimate build advertised under 2.7.5 is a separate download, not this tree

A large share of the README is a storefront. Pre-built Deep-Live-Cam 2.7.5 Ultimate is offered for Windows, Mac Silicon, CPU, NVIDIA and AMD, with pre-configured dependencies and optimized builds, and the pitch is 30+ exclusive features, performance optimizations, and priority support. It is sold through one site, deeplivecam.net, and the file asks readers to be careful about where they download other versions aside from that website and this GitHub repo. None of those 30-odd features, and no pre-built binary, is in the AGPL-3.0 source tree, and the same 2.7.5 name appears both as a paid tier and as a release tag here. Consequence: the headline version number does not identify an artifact, and what the paid build contains relative to the source is not described in the repository text you can read. Check which of the two you are actually installing before you compare behaviour.

The lint gate runs five rules at py310 against a 3.11 to 3.14 support claim

The pyproject file configures one tool and nothing else: no build system, no project table, no dependencies, which is consistent with a project you run from a clone rather than install. What it does configure is a deliberately small rule set, and the file explains itself in a comment.

select = ["E701", "E711", "E712", "F401", "F541"]

The comment calls these deterministic, low-risk rules enforced in CI, and says other rules, F841, E402 and F821, surface real findings but require human judgement, so they are left out of the gate for now. F821 is the undefined-name check. On top of that, the configured target-version is py310 while the setup step says Python 3.14 recommended and 3.11 to 3.14 supported. Consequence for a reader: CI will not catch an undefined name, and the linter is aimed at a version below the support floor the docs claim, so neither the syntax target nor the name check reflects the range the project says it runs on.

Editorial conclusion

Deep-Live-Cam is workable if you are on Windows with an NVIDIA card, or on Linux and willing to accept the GPU build of onnxruntime, and you follow the manual install rather than the pre-built download. Treat the version number on the README heading as stale and track a tag instead. Before you use it on anything other than your own face, read what the built-in check actually filters, get written consent from anyone whose face you swap, and check the terms on the two model files yourself, because the repository states terms for the code and not for the weights.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes