Ordinary cameras can produce a 3D skeleton
FreeMoCap is built around a useful compromise. Instead of reflective markers, dedicated suits, and proprietary capture hardware, it uses video from ordinary cameras plus pose-estimation models. The system synchronizes views, detects a person, triangulates tracked points into 3D coordinates, and prepares data for analysis or animation. That opens motion capture to classrooms and small labs, but the output still depends on camera placement, calibration, visibility, and the selected tracker.
Version 2.0 is a Python server paired with a React and Electron interface. The development instructions start the server on port 8005 and run the desktop interface from a second terminal. Source dependencies include FreeMoCap's skellytracker and skellycam projects, pulled through uv; the README says a normal editable pip install will not work for this checkout. Packaged releases are the easier route for users who only want to record.
A 1,276 MB environment still missed a graphics library
Our fresh Debian sandbox installed 114 Python packages in 75 seconds, consuming 1,276 MB. That is a substantial environment beside a 7.4 MB checkout. The build itself completed in 1 second, but that result should be read narrowly. It does not cover camera calibration, the Electron interface, a CUDA tracker, or the quality of a reconstructed movement. Those need the operating system and hardware path you intend to use.
The source instructions split further by platform. Windows and Linux default to an NVIDIA-accelerated skellytracker group, with an explicit CPU alternative for unsupported hardware. macOS uses the CPU path. The latest release provides Windows, Apple silicon macOS, and x64 Linux installers, including large CUDA builds hosted away from GitHub because some assets exceed its 2 GB limit. Intel Macs are not supported by the current pose models.
What happened when we ran it
Our run used commit 75c8acc, 3 CPUs, 8 GB of RAM, Python 3.12, and an unprivileged container. Pytest ended with exit code 1 after 8 seconds. It reported 35 passing tests and no failed assertions, but 9 modules could not complete collection or setup. The summary covered 44 discovered outcomes and listed 6 warnings.
Every listed error shared one concrete message: libGL.so.1 could not be opened because the file was absent. The affected areas included calibration math, HTTP routers, pipelines, pubsub, rigid-body work, center of mass, and triangulation. We should not infer a code defect from that log. The useful finding is that the README's Python source setup did not prepare this clean Debian image with a graphics system library required during test imports.
Pip-audit also reported 4 known vulnerabilities in the installed Python environment. The supplied audit result does not name the packages, advisory IDs, or severities, so it cannot support a stronger risk claim. The repository scan found 7 CI workflow files, no Dockerfile, and no top-level tests directory, although tests exist under the package path and 35 of them ran successfully in our sandbox.
The current alpha warns of a 10% scale error
Release v2.0.0-alpha.25 was published on September 24, 2026. It fixes CPU-only startup, Linux server startup, Blender export options, and hand detection. Its own warning says alpha means errors, missing features, rough edges, and possible data-affecting bugs. The most consequential known problem is a skeleton reconstruction scale error of roughly 10%, which the maintainers connect to the current calibration or triangulation pipeline.
That warning changes the buying decision. An animator can rescale or clean a take after visual inspection. A researcher measuring reach, gait, or joint trajectories cannot quietly accept a 10% distance error. FreeMoCap can still be part of a study, but the lab needs a known-length object, a repeatable calibration procedure, and an acceptance threshold defined before participants arrive. The repository does not make that validation disappear by calling the system research-grade.
Linux packages and 1.x data need careful trials
Two open reports describe alpha.21 AppImage failures on an Arch-based distribution. One stores a temporary mount path and fails on the next launch; another ships an older libstdc++.so.6 that conflicts with the system audio stack and prevents camera and microphone detection. They concern an older alpha, so they do not prove alpha.25 fails the same way. Their open status is enough reason to test two launches and actual camera detection on the target Linux image.
The 2.0 release notes also recommend keeping a 1.x environment while the stable version is unfinished. Recordings can be reprocessed across versions, but full data compatibility has not been verified. A serious lab should preserve raw videos, calibration files, application versions, model choices, and exported data together. That record matters more than whether the 1-second build step stays green.
Current activity is high, while stability is deliberately low
GitHub recorded a push on September 27, 2026, three days after the alpha.25 release. The project had 10,322 stars and 167 open issues and pull requests when fetched. Recent merged work covers tests, installers, Blender output, hand detection, and multi-camera synchronization. The combined open count is not a defect count, but the dated push and release show active maintenance.
FreeMoCap earns attention because it packages capture, tracking, reconstruction, and export into something a small lab can inspect and modify. The same package is still an alpha with a documented scale problem, platform-specific installer reports, 4 audited dependency advisories, and a source test suite that needs more system preparation than the README states. Use it for exploration now. Put numbers from it into a paper only after your own measurement protocol proves they are trustworthy.