| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Name | Name | Last commit date | ||
|---|---|---|---|---|
Use this SDK to add realtime video, audio and data features to your C++ app. By connecting to LiveKit Cloud or a self-hosted server, you can quickly build applications such as multi-modal AI, live streaming, or video calls with just a few lines of code.
Platform-Specific Requirements:
Note: If the SDK was built with Protobuf 6.0+, you also need libabsl-dev (Linux) or abseil (macOS).
Make sure to initialize the Rust submodule (client-sdk-rust):
# Option 1: Clone with submodules in one step
git clone --recurse-submodules https://github.com/livekit/client-sdk-cpp.git
# Option 2: Clone first, then initialize submodules
git clone https://github.com/livekit/client-sdk-cpp.git
cd client-sdk-cpp
git submodule update --init --recursive
# Note: If running tests, pull Git LFS to bring in test data:
git lfs pullLinux/macOS:
./build.sh clean # Clean CMake build artifacts
./build.sh clean-all # Deep clean (C++ + Rust + generated files)
./build.sh debug # Build Debug version
./build.sh release # Build Release version
./build.sh debug-examples # Build Debug with examples
./build.sh release-examples # Build Release with examples
./build.sh debug-tests # Build Debug with tests
./build.sh debug-all # Build Debug with tests + examples
./build.sh release-tests # Build Release with tests
./build.sh release-all # Build Release with tests + examplesWindows Using build scripts:
.\build.cmd clean # Clean CMake build artifacts
.\build.cmd clean-all # Deep clean (C++ + Rust + generated files)
.\build.cmd debug # Build Debug version
.\build.cmd release # Build Release version
.\build.cmd debug-examples # Build Debug with examples
.\build.cmd release-examples # Build Release with examples
.\build.cmd debug-tests # Build Debug with tests
.\build.cmd debug-all # Build Debug with tests + examples
.\build.cmd release-tests # Build Release with tests
.\build.cmd release-all # Build Release with tests + examplescmake -S . -B build -DCMAKE_TOOLCHAIN_FILE="$PWD/vcpkg/scripts/buildsystems/vcpkg.cmake" # Generate Makefiles in build folder
# Build (Release or Debug)
cmake --build build --config Release
# or:
cmake --build build --config Debug
# Clean CMake build artifacts
Remove-Item -Recurse -Force buildNote (Windows), This assumes vcpkg is checked out in the repo root at .\vcpkg. You must install protobuf via vcpkg (so CMake can find ProtobufConfig.cmake and protoc), for example:
.\vcpkg\vcpkg install protobuf:x64-windowsFor more control and platform-specific builds, see the detailed instructions in README_BUILD.md.
Prerequisites (Windows only):
# Windows PowerShell
$env:VCPKG_ROOT = "C:\path\to\vcpkg"Prerequisites (Linux/macOS):
Quick start:
# Windows
cmake --preset windows-release
cmake --build --preset windows-release
# Linux
cmake --preset linux-release
cmake --build --preset linux-release
# macOS
cmake --preset macos-release
cmake --build --preset macos-release📖 For complete build instructions, troubleshooting, and platform-specific notes, see README_BUILD.md
The Dockerfile COPYs folders/files required to build the CPP SDK into the image. NOTE: this has only been tested on Linux
docker build -t livekit-cpp-sdk . -f docker/Dockerfile
docker run -it --network host livekit-cpp-sdk:latest bashNOTE: if you are building your own Dockerfile, you will likely need to set the same ENV variables as in docker/Dockerfile, but to the relevant directories:
export CC=$HOME/gcc-14/bin/gcc
export CXX=$HOME/gcc-14/bin/g++
export LD_LIBRARY_PATH=$HOME/gcc-14/lib64:$LD_LIBRARY_PATH
export PATH=$HOME/.cargo/bin:$PATH
export PATH=$HOME/cmake-3.31/bin:$PATHEnsure one of the *-examples build script options was run prior.
Before running any participant, create JWT tokens with the proper identity and room name, example
lk token create -r test -i your_own_identity --join --valid-for 99999h --dev --room=your_own_room```bash` ./build-release/cpp-example-collection-build/simple_room/SimpleRoom --url $URL --token
You can also provide the URL and token via environment variables: ```bash export LIVEKIT_URL=ws://localhost:7880 export LIVEKIT_TOKEN=<jwt-token> ./build-release/cpp-example-collection-build/simple_room/SimpleRoom
End-to-End Encryption (E2EE) You can enable E2E encryption for the streams via --enable_e2ee and --e2ee_key flags, by running the following cmds in two terminals or computers. Note, jwt_token needs to be different identity
./build-release/cpp-example-collection-build/simple_room/SimpleRoom --url $URL --token <jwt-token> --enable_e2ee --e2ee_key="your_key"Note, all participants must use the exact same E2EE configuration and shared key. If the E2EE keys do not match between participants:
Press Ctrl-C to exit the example.
The SimpleRpc example demonstrates how to:
Before running any participant, create JWT tokens with caller, greeter and math-genius identities and room name.
lk token create -r test -i caller --join --valid-for 99999h --dev --room=your_own_room
lk token create -r test -i greeter --join --valid-for 99999h --dev --room=your_own_room
lk token create -r test -i math-genius --join --valid-for 99999h --dev --room=your_own_roomEvery participant is run as a separate terminal process, note --role needs to match the token identity.
./build-release/cpp-example-collection-build/simple_rpc/SimpleRpc --url $URL --token <jwt-token> --role=math-geniusThe caller will automatically:
Before running any participant, create JWT tokens with caller and greeter identities and your room name.
lk token create -r test -i caller --join --valid-for 99999h --dev --room=your_own_room
lk token create -r test -i greeter --join --valid-for 99999h --dev --room=your_own_roomStart the receiver first (so it registers stream handlers before messages arrive):
./build-release/cpp-example-collection-build/simple_data_stream/SimpleDataStream --url $URL --token <jwt-token>On another terminal or computer, start the sender
./build-release/cpp-example-collection-build/simple_data_stream/SimpleDataStream --url $URL --token <jwt-token>Sender (e.g. greeter)
Receiver (e.g. caller)
The SDK uses spdlog internally but does not expose it in public headers. All log output goes through a thin public API in <livekit/logging.h>.
| Tier | When | How | Cost |
|---|---|---|---|
| Compile-time | CMake configure | -DLIVEKIT_LOG_LEVEL=WARN | Zero -- calls below the level are stripped from the binary |
| Runtime | Any time after initialize() | livekit::setLogLevel(LogLevel::Warn) | Minimal -- a level check before formatting |
Set once when you configure CMake. Calls below this threshold are completely removed by the preprocessor -- no format-string evaluation, no function call.
# Development (default): keep everything available
cmake -DLIVEKIT_LOG_LEVEL=TRACE ..
# Release: strip TRACE / DEBUG / INFO
cmake -DLIVEKIT_LOG_LEVEL=WARN ..
# Production: only ERROR and CRITICAL survive
cmake -DLIVEKIT_LOG_LEVEL=ERROR ..Valid values: TRACE, DEBUG, INFO, WARN, ERROR, CRITICAL, OFF.
Among the levels that survived compilation you can still filter at runtime without rebuilding:
#include <livekit/livekit.h>
livekit::initialize(); // default level: Info
livekit::setLogLevel(livekit::LogLevel::Debug); // show more detail
livekit::setLogLevel(livekit::LogLevel::Warn); // suppress info chatterReplace the default stderr sink with your own handler. This is the integration point for frameworks like ROS2 (RCLCPP_* macros), Android logcat, or any structured-logging pipeline:
#include <livekit/livekit.h>
livekit::initialize();
livekit::setLogLevel(livekit::LogLevel::Trace);
livekit::setLogCallback(
[](livekit::LogLevel level,
const std::string &logger_name,
const std::string &message) {
// Route to your framework, e.g.:
// RCLCPP_INFO(get_logger(), "[%s] %s", logger_name.c_str(), message.c_str());
myLogger.log(level, logger_name, message);
});
// Pass nullptr to restore the default stderr sink:
livekit::setLogCallback(nullptr);See cpp-example-collection/logging_levels/custom_sinks.cpp for three copy-paste-ready patterns: file logger, JSON structured lines, and a ROS2 bridge that maps LogLevel to RCLCPP_* macros.
| Level | Typical use |
|---|---|
| Trace | Per-frame / per-packet detail (very noisy) |
| Debug | Diagnostic info useful during development |
| Info | Normal operational messages (connection, track events) |
| Warn | Unexpected but recoverable situations |
| Error | Failures that affect functionality |
| Critical | Unrecoverable errors |
| Off | Suppress all output |
The SDK includes built-in support for Chromium tracing, allowing you to capture detailed performance traces for debugging and optimization.
#include <livekit/livekit.h>
// Start tracing to a file
livekit::startTracing("trace.json");
// ... run your application ...
// Stop tracing and flush to file
livekit::stopTracing();You can optionally filter which categories to trace:
// Trace only specific categories (supports wildcards)
livekit::startTracing("trace.json", {"livekit.*", "webrtc.*"});Open the generated trace file in one of these viewers:
The SDK includes integration and stress tests using Google Test (gtest).
Linux/macOS:
./build.sh debug-tests # Build Debug with tests
./build.sh release-tests # Build Release with testsWindows:
.\build.cmd debug-tests
.\build.cmd release-testsAfter building, run tests using ctest or directly:
# Run all tests via ctest
cd build-debug
ctest --output-on-failure
# Or run test executables directly
./build-debug/bin/livekit_integration_tests
./build-debug/bin/livekit_stress_tests
# Run specific test suites
./build-debug/bin/livekit_integration_tests --gtest_filter="*Rpc*"
./build-debug/bin/livekit_stress_tests --gtest_filter="*MaxPayloadStress*"| Executable | Description |
|---|---|
| livekit_integration_tests | Quick tests (~1-2 minutes) for SDK functionality |
| livekit_stress_tests | Long-running tests (configurable, default 1 hour) |
RPC integration and stress tests require a LiveKit server and two participant tokens:
# Required
export LIVEKIT_URL="wss://your-server.livekit.cloud"
export LIVEKIT_CALLER_TOKEN="<token with caller identity>"
export LIVEKIT_RECEIVER_TOKEN="<token with receiver identity>"
# Optional (for stress tests)
export RPC_STRESS_DURATION_SECONDS=3600 # Test duration (default: 1 hour)
export RPC_STRESS_CALLER_THREADS=4 # Concurrent caller threads (default: 4)Generate tokens for RPC tests:
lk token create -r test -i rpc-caller --join --valid-for 99999h --dev --room=rpc-test-room
lk token create -r test -i rpc-receiver --join --valid-for 99999h --dev --room=rpc-test-roombrew install cmake protobuf rustsudo apt update
sudo apt install -y cmake protobuf-compiler build-essential
curl https://sh.rustup.rs -sSf | shcd client-sdk-cpp
git fetch origin
git switch -c try-rust-main origin/main
# Sync submodule URLs and check out what origin/main pins (recursively):
git submodule sync --recursive
git submodule update --init --recursive --checkout
# Now, in case the nested submodule under yuv-sys didn’t materialize, force it explicitly:
cd ..
git -C client-sdk-rust/yuv-sys submodule sync --recursive
git -C client-sdk-rust/yuv-sys submodule update --init --recursive --checkout
# Sanity check:
git submodule status --recursivecargo clean -p yuv-sys
cargo build -p yuv-sys -vvIn some cases, you may need to perform a full clean that deletes all build artifacts from both the Rust and C++ folders:
./build.sh clean-allThis SDK leverages various tools and checks to ensure the highest quality of the code.
Note: clang-tidy is not currently supported on Windows for this project because the Visual Studio CMake generator does not produce the compile_commands.json database that clang-tidy requires.
To run locally, first install the following:
macOS:
brew install llvmThis installs clang-format, clang-tidy, and run-clang-tidy. Homebrew may ask you to add /opt/homebrew/opt/llvm/bin to your PATH.
Linux:
# Ubuntu / Debian:
sudo apt-get install clang-format clang-tidy clang-toolsTo run:
clang-tidy -p . src/*.cppRun valgrind on various examples or tests to check for memory leaks and other issues.
valgrind --leak-check=full ./build-debug/bin/livekit_integration_tests
valgrind --leak-check=full ./build-debug/bin/livekit_stress_testsStart the livekit-server with data tracks enabled:
LIVEKIT_CONFIG="enable_data_tracks: true" livekit-server --dev# generate tokens, do for all participants
lk token create \
--api-key devkey \
--api-secret secret \
-i robot \
--join \
--valid-for 99999h \
--room robo_room \
--grant '{"canPublish":true,"canSubscribe":true,"canPublishData":true}'| LiveKit Ecosystem | |
|---|---|
| Agents SDKs | Python · Node.js |
| LiveKit SDKs | Browser · Swift · Android · Flutter · React Native · Rust · Node.js · Python · Unity · Unity (WebGL) · ESP32 · C++ |
| Starter Apps | Python Agent · TypeScript Agent · React App · SwiftUI App · Android App · Flutter App · React Native App · Web Embed |
| UI Components | React · Android Compose · SwiftUI · Flutter |
| Server APIs | Node.js · Golang · Ruby · Java/Kotlin · Python · Rust · PHP (community) · .NET (community) |
| Resources | Docs · Docs MCP Server · CLI · LiveKit Cloud |
| LiveKit Server OSS | LiveKit server · Egress · Ingress · SIP |
| Community | Developer Community · Slack · X · YouTube |
| Back | FazBrowse Home | New Git URL |