FreeMoCap: markerless motion capture from webcams, and what the AGPL build actually asks of you

What FreeMoCap is for, and who it is aimed at

Commercial motion capture rigs bundle calibrated cameras, markers and proprietary software, and the cost puts them out of reach for a lot of labs, classrooms and solo animators. FreeMoCap takes the opposite position: the README describes it as a "free-and-open-source, hardware-and-software-agnostic, minimal-cost, research-grade, motion capture system and platform for decentralized scientific research, education, and training". The emphasis on decentralized research is the real scope. This is not a product aimed at a studio pipeline. It is aimed at people who want to capture human movement without buying a suit or a marker set, and who are willing to run a Python server and an Electron window to get there.

The hardware-agnostic claim matters. The project does not ship cameras. You supply them, and the software does the tracking. That is what makes the cost claim credible, and it is also the source of most of the quality variance, because the result depends on the cameras you bring and how you arrange them.

How the tracking pipeline is put together

The repository is split into a Python backend and a TypeScript front end. The Python side is the actual capture and tracking engine, and the GUI is a separate Electron application living in freemocap-ui. The README's development instructions make the split explicit: you start the Python server, which listens on http://localhost:8005, and then start the React GUI in a second terminal, at which point an Electron window appears. The two processes talk over that local port.

The tracking itself is not implemented inside the main repository. The pyproject.toml pulls in a set of sibling packages by git source: skellycam, skellytracker, skellyforge, skelly_synchronize (from the skellysync repository), and freemocap_blender_addon. So the camera handling, the pose tracking, the post-processing and the Blender export are all separate projects that FreeMoCap composes. This is a deliberate architecture, and it has a practical consequence: a bug in tracking is often a bug in skellytracker, not in freemocap itself, and the issue tracker you want may be a different repository.

The main package also depends on opencv-contrib-python, numba, scikit-learn, pydantic and numpydantic, among others. The presence of numba and scikit-learn is consistent with a pipeline that does numerical work on video frames rather than a thin wrapper around a single model.

Installing FreeMoCap from pip and running a first capture

The README's quickstart targets Python 3.9 through 3.11, with 3.11 recommended, while pyproject.toml declares requires-python >=3.11. If you are on 3.9 or 3.10, the packaging metadata and the quickstart text disagree, so treat 3.11 as the safe choice.

The published package requires you to pick a tracker extra. A plain pip install freemocap installs without its tracker, which is the most common way to end up with a GUI that cannot track anything. Pick one of the two documented extras:

pip install freemocap[cuda]   # Windows/Linux with an NVIDIA GPU

pip install freemocap[cpu]    # macOS, or Windows/Linux without a supported GPU

Once installed, the GUI launches from a single command:

freemocap

According to the README, a GUI window should appear. The README then adds, in its own words, "Have fun! It might break! Work in Progress lol", which is worth taking at face value rather than as modesty.

If you want to run from source instead, the README is explicit that conda plus pip install -e . will not work, because dependencies are pulled from private git repositories through uv. The source path is uv venv, then uv sync, then uv run python freemocap/__main__.py. On Windows or Linux without a supported GPU you force the CPU build with uv sync --no-default-groups --group cpu. The GUI then needs Node.js and two commands inside freemocap-ui: npm install and npm run dev.

Where FreeMoCap breaks, and when it is the wrong tool

The most concrete limitation is stated by the project itself: the current release line is 2.0.0-alpha.24. Every recent release is an alpha. If you need a version number you can pin in a production dependency and trust not to change behaviour between minor bumps, this is not that. The README's "It might break!" line is consistent with the release history rather than a throwaway joke.

The second limitation is the install surface. The tracker is not installed by default, so pip install freemocap alone gives you an incomplete system. The GPU path is automatic on Windows and Linux but resolves to CPU-only on macOS, and the README offers no macOS GPU alternative. If your workflow assumes GPU-accelerated tracking on a Mac, the documentation does not describe a way to get it.

The third is architectural. Because skellycam, skellytracker, skellyforge and freemocap_blender_addon are separate repositories pulled by git branch rather than pinned releases, the source install tracks moving branches. A source build today and a source build next month are not guaranteed to be the same software. For a lab that needs reproducible results across a study, that is a real problem, and the answer is to pin commits yourself rather than rely on the branch references in pyproject.toml.

Finally, markerless capture from ordinary cameras is inherently less precise than a marker-based system. The project calls itself research-grade, but nothing in the README claims accuracy parity with a commercial rig, and you should not assume it.

FreeMoCap compared with MediaPipe and Rokoko

MediaPipe is the most common alternative people search for alongside FreeMoCap, and the difference is scope rather than algorithm. MediaPipe is a set of perception libraries you embed in your own application; it gives you pose landmarks and leaves the capture session, synchronization, calibration, post-processing and export to you. FreeMoCap is an application. It bundles camera handling through skellycam, tracking through skellytracker, processing through skellyforge and a Blender exporter, and wraps the whole thing in an Electron GUI. If you want to build a custom pipeline, MediaPipe is the lower-level and more flexible choice. If you want a working capture tool today, FreeMoCap is the assembled product.

Rokoko sits on the other side. It is a commercial ecosystem with dedicated hardware and a supported software stack, and the trade is money for reliability and support. FreeMoCap's pitch is the inverse: no hardware purchase, but you accept alpha software, a self-managed install and a community Discord as your support channel. The README links a Discord server and asks users to report how it went, which tells you where support actually lives.

Licence terms and what the AGPL means for adopters

FreeMoCap is licensed AGPL-3.0, and the README states this plainly. The AGPL's defining feature compared with the GPL is the network clause: if you run modified software and let users interact with it over a network, you are expected to offer them the corresponding source. For a desktop capture tool this may never come up. For anyone thinking about wrapping FreeMoCap in a hosted service, it very much does.

The README also acknowledges that the AGPL will not suit everyone and says the maintainers are willing to discuss alternative licensing at a price that "increases exponentially as you move spiritually away from the AGPL". That is a clear signal that commercial licensing exists as a conversation, not as a published price list. If your company cannot ship AGPL code, the documented path is to contact the maintainers, and the cost is negotiated rather than fixed. This is not legal advice; if the licence decision is material to your business, that is a question for a lawyer, not for a README.

Maintenance status and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-17, four days before this writing. Releases are frequent: alpha.21 in August, alpha.23 later in August, alpha.24 in mid September. So the project is being worked on now, and the release cadence is fast.

That cadence is also the upgrade cost. Alpha releases by definition do not promise stability, and a project moving through alpha.21, alpha.23 and alpha.24 within roughly five weeks is changing quickly. Upgrading is not a matter of bumping a version and reading a changelog entry; the practical approach for anything you depend on is to pin the exact version or commit, test the upgrade against your own capture data, and only then move. For source installs, the git branch references in pyproject.toml mean you should pin commits in your own lockfile rather than track the branches the project points at.

On the positive side, the release notes and the repository layout show active maintenance rather than a dormant project, and the split into skelly* packages means fixes to tracking or camera handling can land without a full FreeMoCap release.

Editorial conclusion

Adopt FreeMoCap if you need low-cost markerless capture for research, teaching or experimentation and you can live with a 2.0.0 alpha release and the AGPL-3.0 obligations. Do not adopt it if you need a stable commercial pipeline or a permissive licence for closed-source distribution. Before committing, verify that your Python version is 3.11 or newer, that your GPU path matches one of the two documented install extras, and that your intended use is compatible with the licence.

Frequently asked questions

Official sources

1. freemocap/freemocap on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases