# Momo: a native WebRTC client that runs on a Raspberry Pi or a Jetson

> Momo is an Apache 2.0 licensed C++ client that uses libwebrtc to do WebRTC without a browser, with P2P, Ayame and Sora signalling modes, hardware encoding paths for Raspberry Pi, Jetson, Apple, NVIDIA and Intel hardware, and binaries for Windows, macOS, Ubuntu and Raspberry Pi OS. The judgement is that the hardware coverage is the reason to use it, and that the support model, Japanese only on Discord, is the thing to plan for.

**shiguredo/momo** — WebRTC Native Client Momo (C++)

- Repository: https://github.com/shiguredo/momo
- Website: https://momo.shiguredo.jp/
- Stars: 859 · Forks: 179
- Language: C++
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/shiguredo-momo

## WebRTC without a browser tab

Momo is a native WebRTC client built on libwebrtc, so it speaks the same protocol stack as a browser while running as an ordinary program on the platforms where browsers are awkward. The README describes it as a WebRTC native client that uses libwebrtc and works in many environments without a browser, and the repository is the OpenMomo project, which open sourced Momo and continues to develop it, with the stated aim of letting people use WebRTC for purposes beyond browsers and smartphones. The libwebrtc badge pins the upstream version it tracks, m150.7871.3.0 on the 7871 branch, which matters for a project that is really a native binding to a moving upstream. The practical pitch is straightforward. A camera on a Pi or a Jetson has to originate video to a browser, and a browser based page on that device is a heavy way to do it. Momo is the alternative, and the rest of the feature list is about making that alternative capable.

## Three signalling modes, and they are not equivalent

The mode decides who brokers the connection, and Momo has three. In P2P mode Momo carries its own signalling server, so it can be used in a complete peer to peer arrangement, and the README notes that you can use it simply by pointing a browser at Momo. Ayame mode connects to the WebRTC Signaling Server Ayame, and the README says Momo to Momo usage is possible in that mode as well. Sora mode is for the WebRTC SFU Sora, which Shiguredo both develops and sells, and that is where the feature set expands, since simulcast with several qualities at once is listed as supported in Sora mode, as is client certificate support. The three modes also differ in what you have to run. P2P needs nothing but Momo, Ayame needs an Ayame server, and Sora needs a Sora deployment, which is a commercial product and the source of the funding model discussed later.

## Hardware encoding across five different vendors

The hardware accelerator support is the core of the project, and the README lays it out vendor by vendor. On a Raspberry Pi the GPU acceleration is used through V4L2 M2M with H.264 encode and decode, and the README notes that the Raspberry Pi 5 has no H.264 hardware accelerator so it cannot be used there. On Apple hardware the accelerators are reached through VideoToolbox, with H.264 and H.265 both directions. NVIDIA video cards go through the NVIDIA Video Codec SDK, covering VP9, AV1, H.264 and H.265. Intel graphics use Intel VPL, available on Windows x86_64 and Ubuntu x86_64, with the same four codecs. NVIDIA Jetson boards use the JetPack SDK with the same codec set. These paths are what make the rest of the list possible, because Momo supports uncompressed camera input such as YUY2 and NV12, and when the encoder is on the hardware the pipeline can carry 4K, and because the camera feeds it directly, 120 fps streaming is possible with a hardware encoder. H.265 and AV1 are both supported, and OpenH264 provides the software H.264 path for machines with no accelerator.

## Devices, latency and the data channel

The device handling is documented per operating system, which is the kind of detail that usually decides whether a native client is usable. On Linux, with Ubuntu or Raspberry Pi OS, and on macOS, Momo can list the audio input, audio output and video input devices, and you can select a video input device on Windows, Linux and macOS, and audio input and output devices on Linux and macOS, with separate documents for the Linux video and audio device paths. Raspberry Pi cameras are supported through libcamera, with a dedicated LIBCAMERA.md. Two features stand out. The data channel can be used to read and write serial devices directly, and the README is explicit that this use case prioritises lower latency over reliability, which is an honest description of a channel that is not designed for it. And in a GUI environment, SDL is used to receive audio and video. The README also points at a policy document for known issues, linked as issue 89, which is where a buyer should look before assuming a bug is unfixed.

## Binaries, supported systems and the build tree

Binaries are published on the GitHub releases page, and the list of supported environments is specific. Windows 11 x86_64, macOS 26, 15 and 14 on arm64, Ubuntu 24.04 and 22.04 on x86_64, Ubuntu 22.04 on ARMv8 with JetPack 6 on the Jetson AGX Orin and Orin NX, and Raspberry Pi OS Bookworm 64-bit on the Raspberry Pi 5, 4, 3, 2 Model B v1.2 and Zero 2 W. Three documents cover the rest, with USE.md for trying it, BUILD.md for building or packaging, and FAQ.md for common questions. The repository itself is a native build tree rather than a simple CMake project alone, with CMakeLists.txt at the top, a DEPS file for dependencies, a sysroot directory and sysroot_builder.py for building the toolchain sysroot, buildbase.py and run.py as the build and run entry points, canary.py for the canary release flow, jetson_postprocess.py for Jetson specific post processing, prek.toml and ruff.toml for the pre-commit and lint setup, a .clang-format file, and CHANGES.md and VERSION for the release notes.

## Support is Japanese, and pull requests need prior discussion

The support model is stated at the top of the README and it is unusual enough to plan around. Shiguredo will not respond to pull requests or issues that have not been discussed on Discord, and Discord is only available in Japanese, and the README asks that you read their open source policy document before use. The reasoning is not stated, but the effect for an adopter is clear. A bug report filed in English on the issue tracker can go unanswered, and a patch that arrives without a conversation may sit unreviewed, because the review happens on a Japanese language channel. There is also a published guide for how known issues are handled, linked as issue 89, and the original author has written a book collecting the Momo know how, sold through a Japanese storefront, which is a reasonable way to read the design decisions without the Discord archive.

## A paid tier sits next to the open source build

The licence is Apache 2.0, with the copyright line naming tnoho as the original author from 2015 and Shiguredo Inc from 2018, and the OpenH264 codec that ships with it comes with its own binary licence text from Cisco, which is a separate set of terms from the project's own. What complicates the picture for an adopter is the priority implementation arrangement. It is defined in the README as a mechanism for customers who have contracted a Sora licence, where features planned for Momo are implemented ahead of schedule, for a fee. The list of features already handled this way includes the Windows release as open source, WebRTC statistics support, NVIDIA Video Codec support on Windows and on Linux, and screen capture support on Windows and Linux, with named companies credited for several of them. The README also lists what could still be arranged, among them the --list-devices, --audio-input-device and --audio-output-device options on Windows 11 x86_64, Windows 11 on arm64, and Ubuntu 20.04 on arm64 with JetPack 5.

The option names in that list are the ones a Windows user would look for:

```text
--list-devices
--audio-input-device
--audio-output-device
``` The practical consequence is that the open source build and the shipped product are not always the same, and the gap is a commercial decision rather than a technical one.

## Conclusion

Momo fits a team shipping a device that has to originate or receive WebRTC video without a browser, on a Raspberry Pi or a Jetson, where the hardware encoder is the difference between a usable stream and an unusable one, and it fits anyone who wants to test a WebRTC path outside a browser tab. It is the wrong choice if you need support in a language other than Japanese, because the project's Discord, where its contributors discuss everything, is Japanese only, and it is a poor fit if you need the commercial Sora features, since priority implementation of planned features is a paid arrangement for Sora licence customers. Before you adopt it, check the supported environment list against your hardware, read the policy for known issues in the repository, and confirm that the OpenH264 binary licence is acceptable to you, because that codec ships under different terms from the project's own.

## FAQ

### Which platforms does Momo run on?

The README lists Windows 11 x86_64, macOS 26, 15 and 14 on arm64, Ubuntu 24.04 and 22.04 on x86_64, Ubuntu 22.04 on ARMv8 with JetPack 6 for the Jetson AGX Orin and Orin NX, and Raspberry Pi OS Bookworm 64-bit on the Raspberry Pi 5, 4, 3, 2 Model B v1.2 and Zero 2 W.

### How do I get Momo binaries?

They are published on the GitHub releases page. For everything else the repository has USE.md for trying it out, BUILD.md if you want to build or package it yourself, and FAQ.md for common questions, and the build tree includes a sysroot builder and a run script rather than a bare CMake setup.

### Which hardware encoders does Momo use?

The Raspberry Pi GPU through V4L2 M2M for H.264, which the Raspberry Pi 5 does not have, Apple hardware through VideoToolbox for H.264 and H.265, NVIDIA cards through the NVIDIA Video Codec for VP9, AV1, H.264 and H.265, Intel graphics through Intel VPL on Windows and Ubuntu x86_64, and NVIDIA Jetson through the JetPack SDK. OpenH264 provides the software H.264 path.

## Sources

- [License: Apache-2.0](https://github.com/shiguredo/momo/blob/develop/LICENSE)
- [Project website](https://momo.shiguredo.jp/)
- [README](https://github.com/shiguredo/momo/blob/develop/README.md)
- [Releases](https://github.com/shiguredo/momo/releases)
- [shiguredo/momo on GitHub](https://github.com/shiguredo/momo)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shiguredo-momo