MediaPipe: Google's on-device ML toolkit, its two entry points, and the telemetry and GPU defaults you inherit

The GitHub README forwards you to developers.google.com

The README.md in google-ai-edge/mediapipe starts with front matter that reads layout: forward and target: https://developers.google.com/edge/mediapipe, and its first line of prose tells you that the developer site is the primary documentation. That is the most important thing to know about the repository before you start: the repo holds source, build scripts and Dockerfiles, while installation steps, API references and per-solution guides live on developers.google.com/edge/mediapipe.

The practical consequence is that you will not find a pip, npm or Gradle line to copy from the repository front page. The README links out to four setup guides, one each for Android, iOS, Python and Web apps, and to per-solution developer guides. If you search the repo for install commands you will land on build scripts such as build_android_examples.sh, build_desktop_examples.sh, build_ios_examples.sh and build_manylinux_wheel.sh, which build from source and are not the quick path for an application developer. Bookmark the developer site rather than the GitHub tree, and treat the GitHub repository as the place to read code, file issues and follow releases. Questions, per the README, belong on Stack Overflow under the mediapipe tag, while GitHub issues are reserved for requests and bugs.

Solutions and Framework are two separate entry points with different platforms

MediaPipe is split into two layers, and picking the wrong one costs time. MediaPipe Solutions is the high-level product. It bundles MediaPipe Tasks, which are cross-platform APIs and libraries for deploying a solution, with MediaPipe models, which are pre-trained and ready to run with each solution. Solutions are grouped into six areas: audio (audio classifier), decision (decision maker), genai (LLM inference), retrieval (semantic retriever), text (text classifier) and vision (object detector). Setup guides exist for Android, iOS, Python and Web apps.

MediaPipe Framework is the low-level component for building efficient on-device machine learning pipelines similar to the premade Solutions. You assemble your own on-device pipeline from three concepts: packets carry data, graphs wire the processing together, and calculators do the work at each node. The README points Framework users at a separate install guide and says example applications are built in C++, Android and iOS. Python and the web do not appear in that Framework sentence, so if your project lives in Python or a browser, the Tasks APIs are the documented route, and dropping to the Framework means moving into C++ and Bazel. A third piece, MediaPipe Studio, runs in the browser and lets you visualize, test and benchmark solutions before writing any code, which helps you decide whether a stock model is good enough before you commit to customizing it.

Tasks keep your input on the device but report usage metrics to Google

The privacy notice in the README, last modified June 5, 2026, makes two separate claims, and you need both in your head. First, when you use MediaPipe Tasks, processing of input data such as images, video and text happens on the device, and MediaPipe does not send that input to Google servers. That is why the project pitches Tasks for data that should not leave the device: a camera frame used for hand tracking stays local.

Second, MediaPipe Tasks APIs do send metrics about the performance and utilization of the APIs in your app to Google, which uses them to measure performance and usage, debug, maintain and improve Tasks under the Google Privacy Policy. The notice then puts the legal burden on you: the app developer is responsible for obtaining informed consent from app users about Google's processing of MediaPipe metrics data where applicable law requires it.

The consequence is concrete. An app that markets itself as fully offline or as sending nothing to third parties cannot make that claim while embedding Tasks without addressing this telemetry, and your privacy policy and consent flow need to cover it. The README does not say how to switch the metrics off, and it does not say whether the lower-level Framework sends the same metrics, so verify both on the developer site before you ship into a regulated setting.

A setup.py source build leaves the GPU off unless MEDIAPIPE_DISABLE_GPU is exactly 0

If you build the Python package from a checkout, the GPU decision is made by one line in setup.py:

MP_DISABLE_GPU = os.environ.get('MEDIAPIPE_DISABLE_GPU') != '0'

Read the comparison carefully. The GPU is disabled whenever the variable is anything other than the string 0, which includes the case where it is not set at all. Setting it to 1, true or an empty string also leaves the GPU disabled. In the disabled case the build passes a single Bazel flag:

GPU_OPTIONS_DISABLED = ['--define=MEDIAPIPE_DISABLE_GPU=1']

Only with MEDIAPIPE_DISABLE_GPU=0 does setup.py switch to the enabled option list, which adds the copts -DTFLITE_GPU_EXTRA_GLES_DEPS, -DMEDIAPIPE_OMIT_EGL_WINDOW_BIT, -DMESA_EGL_NO_X11_HEADERS and -DEGL_NO_X11. On macOS it appends one more, -DMEDIAPIPE_GPU_BUFFER_USE_CV_PIXEL_BUFFER. The EGL and Mesa defines show that the Linux GPU path targets EGL and GLES without X11 headers.

The effect for you: a wheel you compile yourself with default settings runs on the CPU path, and nothing in a default build will warn you. If you need GPU inference from a self-built package, set the variable explicitly and confirm your system has the EGL and GLES development headers that the Dockerfile installs.

Building from source means Bazel, Clang 16 and a stack of system libraries

The top level of the repository tells you what a source build involves before you open a single script. It carries .bazelrc, .bazelversion, MODULE.bazel, WORKSPACE and BUILD.bazel, so the build runs through Bazel with a pinned Bazel version. There is also a Package.swift with a Sources/ directory for Swift Package Manager, a setup_android_sdk_and_ndk.sh for Android toolchains and a setup_opencv.sh for OpenCV.

The main Dockerfile is the clearest statement of the toolchain. It starts FROM ubuntu:22.04, installs build-essential, gcc, g++, ffmpeg, nodejs, npm, python3-dev, python3-opencv and a list of OpenCV development packages (core, highgui, imgproc, video, calib3d, features2d and contrib), then openjdk-21-jdk and the Mesa EGL and GLES development libraries. It then installs Clang 16 from the LLVM script and makes it the default compiler:

RUN ./llvm.sh 16
RUN ln -sf /usr/bin/clang-16 /usr/bin/clang
RUN ln -sf /usr/bin/clang++-16 /usr/bin/clang++

Two further Dockerfiles, Dockerfile.manylinux_2_28_x86_64 and Dockerfile.manylinux2014_aarch64rp4, pair with build_manylinux_wheel.sh to produce Linux wheels for x86_64 and for aarch64. The cost is plain: reproducing a release build on your own machine pulls in a JDK, a specific Clang and a full OpenCV development stack. If you only want to call Tasks from an app, the setup guides on the developer site are a much shorter road.

The Python dependency set includes OpenCV, audio I/O and plotting

The requirements.txt at the root of the repository is short, and every line is a runtime dependency you inherit:

absl-py~=2.3
certifi
numpy
sounddevice~=0.5
flatbuffers~=25.9
opencv-contrib-python
matplotlib

A few of these deserve attention. OpenCV arrives as opencv-contrib-python, so check it against any OpenCV package your project already pins. sounddevice is pinned to the 0.5 series and matplotlib is a hard requirement, so both are installed even if your code never records audio or draws a chart. absl-py is held at the 2.3 series and flatbuffers at the 25.9 series by compatible-release specifiers.

Next to that file the repository keeps requirements_lock.txt plus per-interpreter lock files: requirements_lock_3_10.txt, requirements_lock_3_11.txt, requirements_lock_3_12.txt, requirements_lock_3_13.txt and requirements_lock_3_14.txt. That set tells you which Python minor versions the build pins dependencies for. If you run an interpreter outside 3.10 to 3.14, there is no lock file for it in the tree, and you are on your own for resolving versions.

The root package.json is a build harness named medipipe-dev

Web developers who open package.json at the repository root should not mistake it for a library manifest. Its name is medipipe-dev, with the typo intact, its version is 0.0.0-alpha, its description is MediaPipe GitHub repo, and it declares only devDependencies. Those dependencies describe how the web side is built and tested: rollup 4 with the commonjs, node-resolve and terser plugins for bundling, typescript pinned at exactly 5.3.3, google-protobuf pinned at 4.0.2 alongside protobufjs, protobufjs-cli and ts-protoc-gen for generating message code, jasmine and jasmine-reporters for tests, and type packages for @webgpu/types and @types/offscreencanvas. The pnpm block allows only esbuild to run build scripts, and a pnpm-lock.yaml sits next to it.

For an application developer the takeaway is that cloning the repository and running a package manager install at the root does not give you something to import; the web setup guide on the developer site is where the consumable route is described.

Three releases in October 2026 make pinning a version mandatory

The repository is not archived and the last push landed on 2026-11-02. Releases are arriving quickly: v1.1.0 on 2026-10-07, v1.1.1 on 2026-10-14 and v1.2.0 on 2026-10-28. Three tagged releases in about three weeks, including a minor version bump, answers the question of whether MediaPipe is still supported: it is, and it moves fast.

Fast movement has a cost for anyone embedding it: each tag is a new build of everything you ship, and the GitHub release list is where each change is recorded. Pin an exact version in your app, read the release entry before you upgrade, and rerun your own accuracy and latency checks after each bump instead of floating on the newest tag. The default branch is master, so if you build from the tip rather than from a tag, you are building whatever was pushed that day.

Editorial conclusion

MediaPipe fits teams that want pre-built vision, audio, text, retrieval and genai tasks running on the device across Android, iOS, Python and the web, and it is clearly maintained, with v1.2.0 on 2026-10-28 and a push on 2026-11-02. It fits poorly if your app cannot send any usage metrics to Google or if you need to ship a GPU-enabled build from source without learning Bazel. Before adopting it, check the metrics disclosure your users must consent to, pin a specific release, and decide whether you need Tasks or the Framework.

Frequently asked questions

Official sources

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