metaRTC: a WebRTC stack in C for embedded devices

A WebRTC stack that skips the browser

metaRTC is described as a WebRTC SDK for embedded, IoT and robotics devices, and the README frames it as a pure C version of WebRTC that runs on Linux, RTOS, Windows, Mac, Android and iOS. The problem it addresses is concrete: a conventional WebRTC stack arrives with a browser runtime attached, and on a device with a few hundred megabytes of RAM and an RTOS instead of Linux, that runtime is the part you cannot ship. The README says the stack can run in fully offline environments.

The scope claimed is a complete one: ICE and ICE-Lite, configurable STUN and TURN, DTLS and SRTP, full RTP and RTCP, adaptive bitrate and congestion control, flexible media pipelines, peer to peer connection logic, UDP with optional TCP fallback, and multi-stream multi-track support. Signaling is listed as customizable session and signaling logic, which is the key qualifier. You get the transport, the security, the codecs, and the congestion handling. You supply the part that tells two devices to talk to each other.

For a robotics vendor streaming camera frames to a control room, that division is the point rather than a gap.

Four modules, one of them not C

The repository splits into four libraries, and the split is the fastest way to understand it. libmetartccore8 is pure C and holds the WebRTC protocol stack. libyangutil8 is pure C and covers AEC, ANS, AGC and other audio and video processing. libyangwhip8 is pure C and implements the whip, whep, sfu and mcu connection protocols. libmetartc8 is the odd one out: it is C++, and its job is audio and video collection, encoding, decoding, transmission, rendering, and push and pull streaming.

So the protocol and the DSP work sit in C, which is what you want when the target is a microcontroller or an RTOS, while the higher level media plumbing is C++, which is easier to write and easier to integrate with application code. Anyone porting to a new RTOS only has to port the core library and the whip layer, not the whole surface.

The top level tree supports that reading. It carries include/, thirdparty/, arch/, codec/, bin/, and per platform build scripts named cmake_lib_x64.sh, cmake_lib_ios.sh, and cmake_lib_android.sh, plus project_msvc/ for Visual Studio. The presence of arch/ and codec/ as separate directories suggests the platform-specific and codec-specific code is factored out of the shared core, which is what makes a single codebase across RTOS, Linux and Android plausible.

Getting the dependencies and the build

The README is candid that the build instructions live in the wiki rather than on the page. Compilation is covered by the metaRTC Compilation, metaRTC (ARM linux64) Compilation, and metaRTC mbedtls (PolarSSL) Compilation wiki pages, and there is a separate Third-party library download page for the dependencies. There is no command sequence in the README itself, so treat the wiki as the source of truth for your target rather than guessing at a cmake invocation.

What the README does state precisely is the dependency set for compiling libmetartccore8: OpenSSL or Mbedtls for the TLS side, libsrtp for SRTP, and usrsctp for the DataChannel layer carried over SCTP. Either OpenSSL or Mbedtls satisfies the first requirement, which matters on devices where one of the two is already present. The thirdparty/ directory in the tree is where those external pieces live.

A practical first step is therefore to read the compilation wiki page for your platform, place the three dependencies where that page expects them, and run the per platform build script that matches your target:

cmake_lib_x64.sh
cmake_lib_ios.sh
cmake_lib_android.sh

The demo directory gives you two reference programs to check the build against: demo/metaplayer8/ for playback and demo/metapushstream8/ for pushing a stream.

The codec list is the hardware constraint in disguise

The audio and video feature list is where an embedded project hits reality. Video support is H264 and H265 (HEVC). Audio is OPUS, G711A, G711U, AAC, MP3 and SPEEX, and the audio processing chain offers AEC, ANS, AGC, VAD and CNG. On an embedded device the encoder side is rarely the library's problem; it is usually the hardware encoder, and a codec the SoC cannot accelerate is a codec that will not keep up.

Recording is offered as MP4 and FLV, with AAC and H264, and separately AAC and H265 (HEVC). Multi-stream, multi-track support means you can carry more than one track over a session, and DataChannels are supported for non media traffic, with NACK, PLI, FIR, FEC and TWCC listed for loss handling and bandwidth estimation on the RTP side.

Two things stand out as good news for constrained hardware. ICE-Lite is supported, which suits a device that sits behind a NAT and only ever answers. UDP with optional TCP fallback is supported, which covers networks that block UDP. Neither feature lets you skip the question of whether your encoder keeps up, so the codec list still needs to be checked against the target SoC before anything else.

Signaling is the part you still have to write

The README lists customizable session and signaling logic among the stack's features, and the API and programming guides are pointed at through the wiki: metaRTC 8.0 API, the metaRTC 8.0 P2P Programming Guide, and the metaRTC 8.0 API Programming Guide. What this means in practice is that metaRTC gives you the machinery to establish and secure a session once two peers have found each other, and leaves the discovery and rendezvous mechanism to your application.

That is a design decision rather than an omission, and it is the right one for a device that may be on a private network with no public signaling server. But it does mean your backlog includes a signaling service or protocol, and the corresponding operational cost of running it.

There is a second route that avoids much of that work, and it sits in the same repository. libyangwhip8 implements the whip, whep, sfu and mcu connection protocols. The README also links a wiki page on streaming from metaRTC to janus over the whip protocol. Rather than pairing two devices peer to peer with your own signaling, you can have the device publish through a whip endpoint and let an SFU or MCU handle fan-out. The difference in approach is real: the peer to peer path keeps media between two endpoints and gives you full control, while the whip path adds a server in the middle in exchange for not writing rendezvous logic.

The 8.0 modules and the 7.0 release tags

Here is a wrinkle worth checking before you plan an upgrade. The module directories, the API pages, and the demo folders are all version 8: libmetartccore8, libmetartc8, libyangutil8, libyangwhip8, demo/metaplayer8/, demo/metapushstream8/. The recent release tags, however, are 7.0 betas: v7.0-b6 on 2025-12-13, v7.0-b5 on 2025-10-28, and v7.0-b4 on 2025-08-29. The last push to the repository was on 2026-07-11.

The README describes the 8.0 line as successfully adapted to RTOS, and there is a wiki page titled One Codebase Across RTOS, Linux and Android, which is the strongest claim in the project. But the public tags have not caught up with that naming. If you need a pinned, tagged release, the tags you can name are the 7.0 betas, and the API you will be reading in the wiki is the 8.0 API. Read the metaRTC 8.0 API page and the compilation pages together and treat version agreement as something to confirm rather than assume.

The licence is Apache-2.0, and the wiki also carries a guide for the H265 HEVC path, a Mac and iOS path, and a datachannel programming guide, which tells you the media paths are documented one by one rather than in a single reference.

Editorial conclusion

metaRTC fits teams shipping real time media from constrained hardware, where a browser stack will not fit and a hosted WebRTC endpoint is not acceptable, and its Apache-2.0 licence keeps commercial embedding simple. It is the wrong choice if you want a turnkey browser peer, if you cannot supply OpenSSL or Mbedtls plus libsrtp and usrsctp, or if you need a signalling service included rather than written. Check first that the wiki compilation page for your target covers your toolchain, since the README itself carries no build commands, then confirm whether the module you need is libmetartccore8 in C or the C++ libmetartc8 wrapper.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. metartc/metaRTC on GitHub
4. README
5. Releases