MediaPipe vs MoveNet: Decide by What You Compute Downstream

The wider field — YOLO-pose, OpenPose, legacy PoseNet — is covered in our pose model roundup. This page exists because most single-user fitness builds come down to exactly these two Google models, and the choice usually gets made for the wrong reason: a benchmark screenshot instead of the question that actually settles it — what are you going to compute from the keypoints?

The difference that decides it#

Both models detect a person's pose from a plain RGB camera, and both vendors name fitness as the target domain in their own words. MoveNet's model card says it is "targeting movement/fitness activities" and is "tuned to be robust on detecting fitness/fast movement with difficult poses and/or motion blur". The BlazePose GHUM model card says "optimized for on-device, real-time fitness applications" and lists "fitness and repetition counting" as an intended domain. The overlap ends at the output tensor.

MediaPipe Pose (BlazePose GHUM) gives you geometry to compute with. It predicts 33 landmarks — the 17 COCO keypoints plus additional points for the face, hands, and feet, including heels and toe-line (FOOT_INDEX) points. Each landmark carries x, y, z, visibility, and presence. Beyond the normalized image-space landmarks, the API also returns world landmarks, documented by Google as "real-world 3D coordinates in meters with the origin at the center between hips", plus an optional segmentation mask. The depth axis is estimated from a single camera, not measured — the model card is blunt that per-landmark z "is not metric but up to scale" — but hip-origin world coordinates are what let you compute a knee angle or hip-hinge angle in space rather than in the camera plane. That distinction is the whole subject of 2D vs 3D pose estimation.

MoveNet gives you speed and simplicity. It predicts the 17 COCO keypoints as (y, x, confidence) triplets in normalized image coordinates. That is the entire output: 2D only, no depth, no separate visibility flag. The two single-pose variants share one architecture (MobileNetV2 with a feature pyramid and CenterNet-style heads) at different capacities: Lightning takes 192x192 input at depth multiplier 1.0 and is positioned by the card for latency-critical applications; Thunder takes 256x256 at 1.75 for higher prediction quality while, per the card, still running at real-time speed on most modern laptops.

Now map that to what you build downstream. Joint angles measured in the camera plane collapse when the user rotates away from the camera; form feedback that survives a viewpoint change wants the extra foot and hand landmarks and the estimated 3D — that is MediaPipe's case. A rep counter is a state machine over one or two joint trajectories; it needs stable 2D keypoints at a high, consistent frame rate on whatever phone the user already owns — that is MoveNet Lightning's case.

Side by side#

The published numbers, read honestly#

Everything below comes from the vendors' own 2021-era model cards and docs. Quote them, but do not treat them as our measurements — and do not treat them as comparable to each other.

• BlazePose GHUM model card (dated April 2021): Lite runs about 44 FPS on CPU via XNNPack TFLite and about 49 FPS on TFLite GPU, on a Pixel 3; Full about 18 and 40 FPS; Heavy about 4 and 19 FPS. Accuracy on the card's geographically diverse evaluation, as PDJ (PCK@0.2): Heavy 94.2 percent, Full 91.8 percent, Lite 87.0 percent.
• Legacy MediaPipe docs quality table (single person, 2–4 m from camera): Pixel 3 TFLite GPU latency of 20 ms Lite, 25 ms Full, 53 ms Heavy, with PCK@0.2 on yoga, dance, and HIIT sets ranging from 90.2 (Lite, yoga) to 97.5 (Heavy, HIIT).
• MoveNet model cards: TF.js in Chrome, median of 500 runs — on an Intel UHD 620, 39 ms Lightning and 64 ms Thunder; on an RTX 2080 Ti, 10.5 and 15 ms. MultiPose Lightning at 256x256: 40 ms and 19 ms on the same two GPUs. Accuracy as keypoint mAP on Google's "Active" single-person fitness set: Lightning roughly 87.8 to 90.2, Thunder roughly 92.3 to 93.7 depending on subgroup.

Notice what just happened: BlazePose reports FPS on a 2018 phone via TFLite; MoveNet reports milliseconds in a desktop browser via TF.js. Different hardware, different runtimes, different accuracy metrics (PCK@0.2 versus keypoint mAP) on different datasets. No cell in one card cross-compares with any cell in the other. The only cross-model number that means anything is the one you measure on your own target devices at your own input resolution — pose estimation accuracy covers which metrics to use when you do.

Multi-person is not a tie#

If more than one person will be in frame, this pair has one verified answer. MoveNet MultiPose Lightning is documented to detect up to 6 people simultaneously while, per its card, staying real-time on most modern laptops, returning 17 keypoints plus a bounding box per person. The BlazePose GHUM card, by contrast, states the model "tracks only one person on scene if multiple present" and lists multiple people in an image as out of scope.

One caveat we will not paper over: the newer MediaPipe Tasks API may expose a multi-pose option, but Google's live documentation was unreachable in our latest research pass, so we could not verify it. Check the current Pose Landmarker docs before you assume single-person is still a hard limit — and before you assume it is not. Multi-person scenes also need identity tracking across frames, which neither model provides; see the roundup for models built for that scenario.

Where the models live today — and whether anyone is home#

Checked 2026-08-02:

• MediaPipe. The supported path is the MediaPipe Tasks Pose Landmarker; the legacy Pose solution was retired in favor of it on May 10, 2023, per the repo docs. The three model bundles — pose_landmarker_lite, pose_landmarker_full, pose_landmarker_heavy — download as .task files from Google's mediapipe-models storage bucket, and we verified all three URLs return HTTP 200 as of 2026-08-02. The served files were last modified in April 2023, so the weights have not changed in over three years. Download sizes are roughly 5.5, 9.0, and 29.2 MiB; the model card's 3, 6, and 26 MB figures describe the landmark models alone, and the .task bundle packages more than that (the pipeline is a two-step detector plus landmarker).
• MoveNet. Originally distributed on TF Hub. Per the tensorflow/hub README, tfhub.dev links have redirected to their Kaggle Models counterparts since November 15, 2023, and the TF.js docs still reference tfhub.dev URLs that now redirect. We could not inspect the Kaggle listing itself in our latest research pass, so we will not claim what it says. Maintenance signal: the last commit touching pose-detection in tensorflow/tfjs-models was May 21, 2024 — a documentation typo fix. No updates observed since 2024 in the public repo, and the model cards date to 2021.

The honest summary is that both models are frozen. That cuts both ways: you are integrating a stable, known-quantity target, and you should expect zero improvements or fixes. Pick on today's outputs, not on a roadmap — neither has one that we can see.

Licensing#

Both are Apache-2.0 by their primary sources: the MediaPipe framework's LICENSE file and the BlazePose GHUM model card on one side, the MoveNet SinglePose model card on the other. One gap worth flagging: the text we extracted from the MoveNet MultiPose card contained no license line, so confirm MultiPose licensing independently before shipping it commercially. Compared with the AGPL and non-commercial traps elsewhere in the field (covered in the roundup), this pair is refreshingly boring on legal terms.

How to decide#

• Form feedback from joint angles that must survive viewpoint changes — squat depth, hip hinge, heel lift: MediaPipe. The 33 landmarks (with feet) and hip-origin world coordinates are the inputs that math needs; MoveNet simply does not emit them.
• Rep counting at the lowest latency on the widest range of hardware, or in a browser: MoveNet Lightning. A rep counter does not benefit from depth it will never use.
• Single-user 2D accuracy without a 3D requirement: MoveNet Thunder and MediaPipe Full are both plausible — this is the one bracket where we would genuinely benchmark both on target devices before committing.
• More than one person in frame: MoveNet MultiPose, the only verified multi-person option in this pair.
• Camera setup is constrained: respect the vendors' own framing guidance — MoveNet's cards say 3 to 6 feet from a webcam; BlazePose lists beyond 14 feet / 4 m, and a hidden head, as out of scope.

Whichever you pick, the model is the easy part — the camera pipeline, frame pacing, and smoothing around it are where the integration work lives, and that is covered in our camera pose tracking guide.

The honest limits#

• MediaPipe's depth is an estimate. The card says z is "up to scale", not metric, and explicitly lists "applications requiring metric accurate depth" as out of scope. Use world landmarks for angles, never for measurements.
• Every accuracy figure above is vendor-reported, on vendor-chosen datasets, from 2021-era cards. Treat them as positioning, and verify on your own hardware, cameras, lighting, and exercises before quoting a number to anyone.
• Both model cards exclude surveillance and identity recognition from intended use.
• Frozen weights mean today's failure modes are permanent. If either model struggles on your key exercise, no update is coming to save you — test that exercise first.

If your downstream computation is angles in space, take MediaPipe and accept the heavier model. If it is thresholds on 2D trajectories, take MoveNet Lightning and enjoy the headroom. If you find yourself unable to say what you will compute downstream, that — not the model — is the decision to go make.