Amazon Kinesis Video Streams WebRTC C SDK: raw media control in pure C
Amazon Kinesis Video Streams Webrtc SDK is for developers to install and customize realtime communication between devices and enable secure streaming of video, audio to Kinesis Video Streams.
At a glance
- What is it?
- The Kinesis Video Streams WebRTC C SDK is a pure C client that lets a device join a WebRTC session backed by Amazon Kinesis Video Streams, with the media pipeline left to the developer and the option to ingest what you send into a video stream. Building it means CMake, a dependency matrix, and one detail about DTLS keys that is easy to miss.
- Who is it for?
- This SDK fits a device with a C toolchain and no managed runtime, an embedded or IoT client that needs to drive its own encoder and react to congestion control and PLI feedback, or a team that wants its WebRTC traffic to land in a Kinesis Video Stream without building that pipeline itself.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A pure C client, aimed at devices that have no managed runtime
This repository is the Amazon Kinesis Video Streams WebRTC SDK written in C, and the project describes itself as a pure C WebRTC client for Amazon Kinesis Video Streams. Its stated purpose is to let developers install and customise realtime communication between devices and to enable secure streaming of video and audio into Kinesis Video Streams.
The media formats it carries are listed up front. Video is VP8 and H264, audio is Opus, plus G.711 PCM in A-law and µ-law flavours. On the signalling side the client is included rather than left to you, and the arrangement is that Kinesis Video Streams provides the STUN, TURN and signalling backend, so your device only has to talk to the service. NACKs, DataChannels, STUN and TURN support, and both IPv4 and IPv6 are in the feature list.
Portability is a stated goal rather than an aspiration. The library is tested on Linux and macOS, tested on x64 and ARMv5, and the build system is designed for pleasant cross-compilation. The install size claim is sub 200k for the library, with dependencies on OpenSSL, libsrtp, libjsmn, libusrsctp and libwebsockets. A small C library is exactly what an embedded device can carry and exactly what a phone application does not need.
The media pipeline is handed to the developer
The interesting design choice is the developer controlled media pipeline: raw media for input and output, so the SDK does not insist on owning your encoder, your frame timing or your file format handling.
Around that, the SDK exposes the feedback signals a real pipeline needs. There are callbacks for congestion control, and FIR and PLI are set on the RtcRtpTransceiver, which is the hook a video encoder needs to react to a keyframe request. NACK support is listed among the features, which is the retransmission path for packet loss.
The repository shows this being exercised. The samples directory contains a p2p sample, a webrtcstorage sample, h264SampleFrames, h265SampleFrames and opusSampleFrames directories of pre-generated frames, and discoverNatBehavior.c, which suggests a sample that looks at how the local network behaves before a call is attempted. Benchmarks live in bench/ and the test suite in tst/, with Doxygen configuration at the root for the API reference, which is published as the group__PublicMemberFunctions page.
The practical reading is that this is a transport with hooks for media control, not a media engine. You supply the frames, and the SDK negotiates, encrypts and delivers them.
Building on Linux is a clone, a build directory and CMake
The download step is a single clone into a directory named kvs-webrtc-sdk, on the main branch, which the project notes as a change from the earlier master branch.
git clone https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c.git --single-branch -b main kvs-webrtc-sdkYou also need pkg-config and CMake, and the version constraint is stated plainly: CMake requires 3.x, and 4.x is not yet supported.
mkdir -p kvs-webrtc-sdk/build; cd kvs-webrtc-sdk/build; cmake ..By default the build downloads all the libraries from GitHub and compiles them locally, so the note about installing anything ahead of time is mostly about the toolchain. On Ubuntu and Raspberry Pi OS the documented package list covers the build and GStreamer pieces.
sudo apt-get install cmake m4 pkg-config libssl-dev libcurl4-openssl-dev liblog4cplus-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-bad gstreamer1.0-plugins-good gstreamer1.0-plugins-ugly gstreamer1.0-toolsThe GStreamer based capture and encode example is only compiled if pkg-config finds GStreamer on the system, so that dependency is optional in the sense that you can build the SDK without it.
Windows comes with a script, a Perl requirement and a path length trap
The Windows path is heavier. The documented prerequisites are Visual Studio Community or Enterprise, Strawberry Perl, and Chocolatey. The libraries arrive through Chocolatey, including GStreamer and its development package, and the pthreads build is downloaded from the sourceware mirror and unpacked under C:\tools.
choco install gstreamer
choco install gstreamer-devel
curl.exe -o C:\tools\pthreads-w32-2-9-1-release.zip ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-9-1-release.zip
mkdir C:\tools\pthreads-w32-2-9-1-release\
Expand-Archive -Path C:\tools\pthreads-w32-2-9-1-release.zip -DestinationPath C:\tools\pthreads-w32-2-9-1-releaseTwo adjustments are expected before the build runs. The cmake invocation has to point at the pthreads include and library directories, and the batch file that drives the build has to point at your Visual Studio installation.
cmake -G "NMake Makefiles" -DBUILD_TEST=TRUE -DEXT_PTHREAD_INCLUDE_DIR="C:/tools/pthreads-w32-2-9-1-release/Pre-built.2/include/" -DEXT_PTHREAD_LIBRARIES="C:/tools/pthreads-w32-2-9-1-release/Pre-built.2/lib/x64/libpthreadGC2.a" ..
call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvarsall.bat" x86_amd64The path trap is worth naming, because it fails late and cryptically. Long paths have to be allowed first, and the project says that if the paths are still too long, which can cause the build to fail, you should rename the folders to something shorter and move them under C:.
git config --system core.longpaths trueAfter that the SDK is built by running the batch file, and the sample application needs the OpenSSL binaries, the pthreads DLLs and the build output directory added to the path.
The dependency matrix is where builds actually break
The version constraints are strict enough to be worth copying into your own notes. If you link against system dependencies rather than letting the SDK build them, the requirements are libmbedtls at 2.25.0 or newer with a default of 3.6.x, libopenssl at exactly 1.1.1x or 3.0.0 and newer, libsrtp2 at 2.5.0 or older, libusrsctp at 0.9.5.0 or older, and libwebsockets at 4.2.0 or newer. Several of those are upper bounds, which is unusual and means a system with newer packages will not simply work.
The mbedTLS line is selectable, and the build matrix spells out the three options. The 2.28.x line is legacy and opt-in through BUILD_OLD_MBEDTLS_VERSION=ON, 3.6.x is the default, and the 4.x line is opt-in through USE_MBEDTLS4=ON, which implies USE_LIBSRTP3=ON.
The 4.x line has a prerequisite that catches people out. It builds TF-PSA-Crypto from source, and its code generation needs Python 3.8 or newer with two modules available at configure time.
pip install jinja2 jsonschemaWithout them the dependency build fails with a ModuleNotFoundError for jinja2 or jsonschema, which reads like a broken checkout rather than a missing Python package.
Storage for WebRTC changes what the client is for
The newest item in the feature list is storage for WebRTC, and it is the one that changes the shape of a project. The SDK can ingest media into a Kinesis Video Stream, so what you send does not have to end at the peer. A camera in a vehicle, a sensor in a warehouse, a device on a private network, and the recordings land in a stream you can consume later.
That capability is why the samples directory includes a webrtcstorage sample alongside the p2p one. The difference in approach between them is the point of comparison: a peer to peer sample keeps the media between two endpoints, while the storage sample writes the same media into a Kinesis Video Stream on the way past.
The rest of the ecosystem is in place for platforms that are not C. The project points at sibling SDKs for Android, iOS and Web, each with pre-made samples, and the Web build in particular is where the browser is the natural client. That is the honest alternative to this repository: for a phone or a browser, use the SDK written for that platform rather than porting the C client.
For a device that has to run C, the choice is between this SDK and building the client yourself against the Kinesis signalling and media backend, which is a considerably larger job than a CMake invocation.
Apache-2.0, a small library, and a steady release line
The licence is Apache-2.0, which is permissive and carries the usual patent grant. The repository is not archived and the last push was on 2026-10-15. Releases come at a steady pace: v1.20.0 on 2026-08-18, v1.19.2 on 2026-07-07 and v1.19.1 on 2026-06-22, with the project directing you to the release notes page for new feature announcements.
The size claim is the number to keep in mind when you embed this. A sub 200k library plus OpenSSL, libsrtp, libjsmn, libusrsctp and libwebsockets is a reasonable footprint for a device, and the cross-compilation design is what makes ARMv5 and embedded targets practical rather than aspirational.
One behaviour is worth checking before you supply your own credentials. The SDK clones the configured DTLS certificate key into each peer connection through PSA, and keys it generates with createRtcCertificate set PSA_KEY_USAGE_EXPORT for that reason. If you pass your own RtcCertificate, its PSA key has to allow export as well, or the copy into the peer connection fails. That is the kind of detail that appears as an opaque error unless you read the release notes for the version you are on.
Editorial conclusion
This SDK fits a device with a C toolchain and no managed runtime, an embedded or IoT client that needs to drive its own encoder and react to congestion control and PLI feedback, or a team that wants its WebRTC traffic to land in a Kinesis Video Stream without building that pipeline itself. It does not fit a mobile app, where the sibling Android, iOS and Web SDKs are the shorter path, nor a project that wants a general purpose WebRTC stack, since this client is bound to the Kinesis signaling and media backend. Verify three things first: that your CMake version is 3.x, because 4.x is not supported yet, which mbedTLS line you are linking against and whether it is the 3.6.x default, and whether a DTLS certificate you supply yourself permits PSA export, since the SDK clones that key into each peer connection.
Frequently asked questions
What does it take to build the Amazon Kinesis Video Streams WebRTC C SDK?
You need pkg-config and CMake, and CMake must be 3.x because 4.x is not supported yet. On Windows the documented prerequisites are Visual Studio, Strawberry Perl and Chocolatey, and the build is driven by the build_windows_openssl.bat script. By default the SDK downloads its dependencies from GitHub and builds them locally.
Which codecs does the Kinesis WebRTC C SDK support?
Video is VP8 and H264, and audio is Opus plus G.711 PCM in A-law and µ-law. The sample frames shipped in the repository cover h264, h265 and opus.
How do I build against mbedTLS 4 with this SDK?
Pass -DUSE_MBEDTLS4=ON, which implies -DUSE_LIBSRTP3=ON. That line builds TF-PSA-Crypto from source and its code generation needs Python 3.8 or newer with jinja2 and jsonschema installed, otherwise the dependency build fails with a ModuleNotFoundError. The default line is 3.6.x and 2.28.x is available through -DBUILD_OLD_MBEDTLS_VERSION=ON.
Can the SDK store the video it streams?
Yes. Storage for WebRTC is a listed feature, and the SDK can ingest media into a Kinesis Video Stream. The repository ships a webrtcstorage sample for that path and a p2p sample for the peer to peer case.
Do I need to run my own STUN and TURN servers?
No. A signaling client is included, and Kinesis Video Streams provides the STUN, TURN and signalling backend. The SDK also supports STUN and TURN directly, DataChannels, NACKs, and both IPv4 and IPv6.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/awslabs-amazon-kinesis-video-streams-webrtc-sdk-c)Was this useful?