MAMMA: multi-person markerless mocap through a five-step SMPL-X pipeline

What MAMMA reconstructs, and for whom

MAMMA targets a specific gap: recovering the bodies of several people at once from a synchronized multi-view capture, without markers and without tracking each subject in isolation. The repository description calls this markerless accurate multi-person motion acquisition, and the topic list confirms the scope with entries such as mocapmultiperson, multiview and smpl-x. The intended user is not someone who wants a pose overlay on a phone video. It is a lab or studio with a calibrated camera rig, footage of more than one person in frame, and a reason to want parametric body meshes rather than skeleton keypoints. The output step, ma_3d, is described as multi-view SMPL-X optimization, so the deliverable is an SMPL-X fit per person per frame, not a 2D detection list. That choice sets the hardware bar. You need several views, a calibration that maps them into one coordinate system, and enough GPU memory to run segmentation and optimization over the whole sequence. The bundled example is deliberately small: a four-camera clip of roughly 56 MB, downloaded by `bash data/download_example.sh` into `data/mamma_example/`, with the sequence named pushing_and_lifting_from_ground. Four cameras is the floor the authors chose for a smoke test, which is a reasonable hint about the minimum rig they consider meaningful.

The five steps and how data moves between them

The pipeline is named as a chain: ma_cap, ma_masks, ma_2d, ma_3d, ma_vis. Each stage maps to a top-level directory in the repository layout, so the architecture is legible from the file tree alone. capture/ holds the ma_cap step, which loads the multi-view capture. segmentation/ holds ma_masks, which does per-person segmentation using SAM plus YOLO. landmarks/ holds ma_2d, which runs 2D landmark detection through a component the README calls MammaNet. optimization/ holds ma_3d, the multi-view SMPL-X optimization. visualization/ holds ma_vis, which produces per-camera overlays and an interactive scene. The data flow is therefore capture frames in, person masks out, landmarks per camera per person, then a joint optimization that reconciles those 2D observations across views into a single 3D body, then rendering. Two details matter for anyone planning to modify it. First, segmentation precedes landmark detection, so the person identity is established before the 2D detector sees anything; errors in ma_masks propagate into ma_2d and cannot be repaired later in the chain. Second, the optimization step is where the multi-view constraint actually lives, which is why calibration is a required input rather than an optional refinement. The runner itself sits in inference/, with the entry point at inference/cli/run.py, and the README describes inference/ as containing the runner, step builders and a doctor CLI. That doctor CLI is the only built-in self-check the README documents.

Getting a first run out of the bundled example

Installation is a clone plus an environment. The README gives `git clone https://github.com/cuevhv/mamma.git`, then `cd mamma`, then points to docs/INSTALL.md for the full environment, CUDA and weights setup. After activating the environment with `micromamba activate mamma` or `conda activate mamma`, the verification command is `python -m inference doctor`, which the README says checks environment variables and weight paths. The claim that the pipeline is zero-config applies only when weights live under data/, which is gitignored along with output/, so a fresh clone has neither. The quick demo is then two commands: `bash data/download_example.sh` to fetch the four-camera sample into data/mamma_example/, and `python -m inference run` with `--cfg configs/examples/presets/quick.yaml`, `--footage data/mamma_example`, `--seq_name pushing_and_lifting_from_ground`, `--calib configs/examples/calib/iphones_outdoors.yaml`, `--out-tag demo` and `-v`. Outputs land under output/ma_*/demo/mamma_example/. For your own data the argument set is the same shape: `--cfg` points at a preset, `--footage` at a directory of sequence subdirectories, `--seq_name` selects exactly one of them, `--calib` supplies the calibration, and `--out-tag` names the output subdirectory (default `local`). The README is explicit that one run equals one sequence, and that the calibration applies to every sequence under `--footage`. If you have many sequences, the alternative is a capture JSON passed via `--capture`, which enumerates sequences, cameras and calibration in one file so the runner walks them in a single invocation. Two shipped presets are named: quick.yaml as a roughly five-minute smoke test and full.yaml for full-frame processing, with docs/CONFIGS.md covering how to modify or author one.

Three inputs you must supply, and the one that fails silently

The README reduces the prerequisites to three items: a calibration file, a folder with your sequence, and a preset. The calibration accepts .yaml, .xcp or OpenCV .json, which is a wider net than most research code casts and suggests the authors expected people to arrive with existing rigs rather than their own format. The footage side is stricter: `--footage` must be a dataset root containing sequence subdirectories, and `--seq_name` picks one, with the layout documented in docs/YOUR-DATA.md. The capture descriptor is the third path, a JSON that points at footage, calibration, sequences and camera names, and the README frames it as the advanced option for iterating over many sequences. The failure mode worth flagging is that a preset is capture-independent by design. It declares which steps run and their hyperparameters, and nothing about your cameras. So a preset that runs cleanly on the bundled iPhone example tells you nothing about whether your calibration is sane, whether your camera count is sufficient, or whether your subjects are separable. The doctor command checks environment variables and weight paths, not calibration geometry or footage layout. Nothing in the material describes a validation pass over the calibration, so a mis-specified extrinsic matrix would surface as a bad SMPL-X fit in ma_3d rather than as an error before the run.

The licence is unresolved, and that is a blocker for some teams

The repository metadata reports the licence as NOASSERTION, which in practice means no recognised licence file was detected. The README does not state a licence either. This is not a detail to defer. The code is described as official code for a paper, and the datasets live behind a free account on the project page at mamma.is.tue.mpg.de, with registration and email confirmation required. That separation between code and data is common in this research area and usually deliberate, but it means the terms governing the weights and the released captures are not necessarily the terms governing the repository. The body models and weights are downloaded into data/, which is gitignored, so they are not part of the clone. If you are evaluating MAMMA for anything beyond a personal experiment, the licence question has to be answered by the maintainers or the institution, not inferred from the repository. I am not giving legal advice here, and the material does not contain enough to say what the intended terms are. What the material does support is the observation that a NOASSERTION licence combined with account-gated datasets is a combination that requires an explicit answer before adoption in a commercial or published setting.

What is still missing, and the maintenance picture

The README carries a TODO list with one item: release the evaluation scripts, meaning 2D landmark and benchmark evaluation, along with the processed evaluation datasets. Until that lands, the quantitative claims in the CVPR 2026 paper cannot be reproduced from this repository. You can run the pipeline and look at the ma_vis overlays, and you can read the paper, but you cannot rerun the benchmark that produced its numbers. For a review of whether to adopt, that is the single most consequential gap, because it means the accuracy in the title is currently taken on trust rather than verified on your own hardware. The maintenance picture is otherwise thin in the material. No releases were retrieved, so there is no versioned artefact to pin against; the default branch is main and the last push is dated 2026-07-10. The repository is not archived. The README notes that code for both inference and training was released in June 2026, which is more than many paper repositories offer, since training code lets you fine-tune rather than only run. The upgrade cost is hard to estimate from what is available. There is no changelog, no release notes and no migration guide in the supplied material, so anyone tracking main is tracking an unversioned branch. The layout suggests the cost is concentrated in configs/ and the preset YAMLs: if a preset schema changes, your authored presets are the thing that breaks, and docs/CONFIGS.md is where that contract is described.

Where MAMMA is the wrong tool, and what to use instead

MAMMA is the wrong choice when you have one camera. The whole ma_3d step is multi-view SMPL-X optimization, and the calibration input exists precisely to relate views. With a single view there is nothing to optimize across, and you would be paying for segmentation, calibration plumbing and an optimization stage that has no constraint to enforce. It is also the wrong choice when you need results in real time. The chain runs segmentation, then 2D detection, then a per-frame optimization, and the README's own smoke preset is described as roughly five minutes for a small four-camera clip. That is an offline batch shape, not a streaming one. The natural alternative for single-view or real-time work is a monocular human mesh recovery model in the SMPL-X family, of which there are several widely used open implementations. The difference in approach is fundamental rather than incremental: a monocular model learns a prior over plausible bodies and infers depth from that prior plus image evidence, accepting ambiguity in absolute position and scale. MAMMA resolves that ambiguity with geometry instead, triangulating observations across calibrated cameras. The trade is rig cost and offline runtime against metric accuracy in a shared world coordinate frame. If your question is where two people are relative to each other in a room, the multi-view route is the one that can answer it. If your question is what one person's pose looks like in a phone clip, the monocular route answers it with no rig at all. For multi-person work specifically, the alternative to MAMMA is usually a per-person pipeline: detect and track each subject, run monocular reconstruction on each track independently, then reconcile. That approach degrades exactly where MAMMA's design helps, when people occlude each other or when a per-track monocular fit drifts in depth, because independent per-person fits have no shared constraint tying them into one scene.

Who should adopt it, and what to check before you commit

Adopt MAMMA if you already run a calibrated multi-camera rig, you have footage of more than one person, and you want SMPL-X bodies in a common coordinate frame rather than keypoints. The training code being released alongside inference matters here: it means the repository is a starting point for fine-tuning on your own captures, not only a demo runner. Do not adopt it if you need single-camera input, real-time throughput, or a citable accuracy number produced by code you can run today, because the evaluation scripts and processed evaluation datasets are still on the TODO list. The licence being NOASSERTION is a separate gate that has to be cleared before any commercial or published use. Before investing time, run the bundled example end to end, because it exercises the same three inputs your own data will need and it fails fast if the environment is wrong. Concretely: `bash data/download_example.sh`, then `python -m inference doctor`, then the `python -m inference run` invocation with configs/examples/presets/quick.yaml and configs/examples/calib/iphones_outdoors.yaml. If that produces output under output/ma_*/demo/mamma_example/, your environment, weights and preset wiring are sound, and the remaining risk is entirely in your calibration and footage layout. If it does not, the problem is in setup and no amount of work on your own captures will fix it.

Editorial conclusion

Adopt MAMMA if you already own calibrated multi-camera footage of several people and want SMPL-X bodies out of it, and if you can accept the licence file being unresolved until the maintainers clarify it. Do not adopt it if you need a single RGB camera, a real-time stream, or published accuracy numbers you can cite: the README lists the evaluation scripts and processed evaluation datasets as an open TODO, so the paper's benchmark is not reproducible from this repository yet. Verify three things first: that `python -m inference doctor` reports your env vars and weight paths as valid, that your calibration file parses in one of the three accepted formats, and that your footage directory matches the layout in docs/YOUR-DATA.md, because a mismatch there fails before any model runs.

Official sources

1. cuevhv/mamma on GitHub
2. Issues
3. Project website
4. README