# Smelter: a Rust toolkit for programmable real-time video mixing > Smelter is a Rust toolkit for low-latency video and audio composition, combining sources from different origins into one stream or file, with React components, a web renderer built on CEF, and RTMP and WebRTC output. It suits developers building a live product rather than a studio, and its default feature set pulls in a full Chromium. **software-mansion/smelter** — Toolkit for real-time, low latency, programmable video and audio mixing. - Repository: https://github.com/software-mansion/smelter - Website: https://smelter.dev - Stars: 738 · Forks: 47 - Language: Rust - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/software-mansion-smelter ## Composition as code, with React components for the interface Smelter is a toolkit for real-time, low-latency, programmable video and audio composition, and the readme lists three things you can do with it. You can combine multimedia from different sources into a single video or live stream. You can enrich your content with text, custom shaders, and embedded websites. And you can do it with ready-to-use React components. That third point is what separates Smelter from a conventional mixer. The composition is defined in code, and the control surface is a React application, which means a browser-based studio or an operator dashboard is a normal frontend project rather than a bespoke GUI. For a product team that already ships React, that is a large reduction in friction. The second point is about the content model. Text, custom shaders and embedded websites are three different ways to put something into a video frame, and having all three in one pipeline means a title card, a generated background and a live web page can be composed in the same output rather than requiring separate tools chained together. The audience is therefore developers building live video products. The repository is by Software Mansion, described as a software agency with experience in web and mobile apps and complex multimedia solutions, Core React Native Contributors, and experts in live streaming and broadcasting technologies. The topics are livestream, low-latency, react, real-time, rust, video and video-composition. ## The Rust workspace, and the crates that make up the pipeline The Cargo.toml at the root of the repository is the best single view of how the system is put together. It is a workspace with a resolver of 2, edition 2024, and the members are grouped by role: ```toml [workspace] members = [ # Core crates "smelter-api", "smelter-core", "smelter-render", "smelter-render-wasm", # Libraries "decklink", "gpu-video", "libcef", "rtmp", ``` The four core crates are the API surface, the core pipeline, the renderer, and a WASM build of that renderer. The libraries are the integrations, and each one is a specific capability: decklink for Blackmagic DeckLink capture hardware, gpu-video for hardware video coding, libcef for the Chromium Embedded Framework, and rtmp for RTMP ingest and egress. The presence of smelter-render-wasm next to smelter-render is the interesting structural signal. It means the rendering side can exist in a WebAssembly build as well as the native one, which is what makes a browser-based control surface plausible rather than hypothetical. The dependency list gives a sense of the engineering. ffmpeg-next 9.0.0 for the media plumbing, webrtc 0.17.1 and webrtc-util for the WebRTC side, opus for audio, rubato for resampling, glyphon pulled from a git revision for font rendering, tokio with the full feature set for the async runtime, and utoipa with schemars for generating the OpenAPI schema. The toolchain includes tracing for logging and signal-hook for shutdown handling, and the project depends on tokio full, which tells you the whole server is async. The top-level tree matches: there are sdks/ and ts/ directories alongside the Rust crates, an integration-tests directory with its own macros crate, a tools directory, and a .cargo directory for cargo configuration. ## The web-renderer default pulls in a full Chromium The features block in the Cargo.toml is short and consequential: ```toml [features] default = ["web-renderer"] update-snapshots = [] decklink = ["smelter-api/decklink"] web-renderer = ["dep:libcef", "smelter-api/web-renderer"] ``` The default feature set enables the web renderer, and enabling it pulls in libcef, the Chromium Embedded Framework. That means the default build of Smelter embeds a browser engine so it can render web pages into the video output. This is the single most consequential fact for anyone evaluating the project. The web renderer is what delivers the embedded websites feature, and it is on by default, so a default build carries a Chromium dependency and the associated deployment weight. The feature exists as a named flag, so a build that only needs text, shaders and file sources can turn it off. The other feature, decklink, is the opposite shape: it is opt-in and it only enables the DeckLink capability in the API crate. That is the correct pattern for a capability that needs special hardware, and the fact that the two features are treated differently tells you which one the maintainers consider core. The update-snapshots feature is a testing convenience, and the presence of a snapshot testing workflow alongside integration-tests suggests the rendering output is compared against reference images, which is a sensible way to catch unintended changes in a pipeline that is mostly visual. ## Hardware video coding lives in the same repository, under gpu-video Readers looking for gpu-video are pointed at a subfolder of this repository, and the readme is clear that it is the open source hardware video coding library, located in the gpu-video subfolder. That arrangement is worth understanding. A hardware encoder is a component with its own driver surface, its own backends and its own testing needs, and bundling it in the same tree means the two can be versioned and released together. The Cargo.toml shows how it is wired in, with the workspace dependency enabling two specific features: ```toml gpu-video = { path = "gpu-video", features = ["expose-parsers", "expose-backends"] } ``` Exposing parsers and backends means the crate is not a sealed implementation but a set of pluggable pieces, which is what a library like this needs to be if the pipeline is going to be able to use it for encoding rather than only for testing. There is also a decklink folder for Blackmagic DeckLink capture devices, which is the other half of a real broadcast setup. Input and output hardware are the pieces that make a compositor usable in a studio rather than in a demo, and having both here means a project can go from file sources to live capture and hardware encoding without leaving the workspace. The rtmp crate completes the set. RTMP is still the default ingest protocol for most streaming platforms, and shipping it as a first-class library rather than a shell-out to ffmpeg is a real design decision about latency and control. ## Getting started, and what the documentation does not tell you The readme is short, and it points you elsewhere for the mechanics. The documentation is at smelter.dev/docs with a Getting Started section, and there is a separate set of guides at the TypeScript SDK guides quick start page. That two-location structure is a hint about how the project is meant to be used. The core is Rust, but the interface to it is the TypeScript SDK, and the guides under that SDK are where the composition model is explained. If you are evaluating Smelter for a product with a React frontend, the TypeScript guides are the part you will actually work from, and the Rust side is what you embed behind it. The readme itself does not give an installation command, a build command, or a sample configuration, so there is nothing to copy from it directly. The repository does carry DEVELOPMENT.md, RELEASE.md, a CHANGELOG.md and a .envrc, which suggests a documented developer environment and a defined release process, and there is a .hadolint.yaml plus a .dockerignore, so container builds are part of the workflow. Because the public documentation in the repository is thin, the honest way to assess this project is to read the guides and look at the code. The Cargo.toml is unusually informative, more so than the readme, and the crate names alone tell you that this is a server-side pipeline with hardware I/O, not a browser library. ## Licence, cadence and the shape of a fast-moving project Two things a buyer or adopter needs to know. The first is the licence. The repository's licence field is not a standard identifier, it is recorded as a custom licence that GitHub cannot classify, and the manifest points at the file with license-file = "./LICENSE". The LICENSE file in the repository is the one to read. This is a description of how the licensing is arranged rather than legal advice, and for a company that plans to embed Smelter in a commercial product, resolving what those terms require is work to do before you build, not after. The second is cadence. The repository is not archived, and the last push was on 2026-10-20. The recent releases are v0.6.0 on 2026-06-09, v0.5.0 on 2025-12-02 and v0.4.2 on 2025-04-29, so the project is on a 0.x line and has been shipping roughly every few months. A 0.x version with a custom licence is a combination worth weighing. The version number tells you the public API is not yet promised to be stable, which is normal for a young infrastructure project but real when you are going to build a product on it. The custom licence tells you the terms are bespoke, which is not a red flag in itself but is one more thing to read carefully. The dependencies tell the same story from the other side. ffmpeg-next is at 9.0.0, webrtc at 0.17.1, tokio with the full feature set, and a font crate pinned to a specific git revision rather than a published version. Pinning a dependency to a commit is a normal thing for a project that needs an unreleased change, and it is also a supply chain fact you inherit when you depend on it. ## Conclusion Smelter fits a developer building a live video product, such as a browser-based studio or a streaming overlay service, who needs programmable composition and React components rather than a fixed mixer interface, and it does not fit someone who needs a desktop switching application or a light dependency footprint. Before building on it, read the Getting Started documentation and the quick start guides, decide whether you need the web-renderer feature at all since it pulls in CEF, and check the licence file in the repository directly, because the project uses a custom licence rather than a standard identifier. ## FAQ ### What is Smelter and what can it do? Smelter is a Rust toolkit for real-time, low-latency, programmable video and audio composition. You can combine multimedia from different sources into a single video or live stream, enrich content with text, custom shaders and embedded websites, and drive it with ready-to-use React components. ### Where is the Smelter documentation and quick start guide? The documentation is at smelter.dev/docs with a Getting Started section, and there is a separate set of guides under the TypeScript SDK quick start path. The repository README itself gives no install or build command, so the guides are where the composition model is explained. ### What does the default web-renderer feature pull in? The default feature set is web-renderer, and it enables dep:libcef, so a default build embeds the Chromium Embedded Framework to render web pages into the video output. A build that does not need embedded websites can turn the feature off, and the separate decklink feature is opt-in for Blackmagic DeckLink capture hardware. ### Where is the gpu-video library and how is it used? gpu-video is the open source hardware video coding library and lives in the gpu-video subfolder of the Smelter repository. The workspace depends on it with the expose-parsers and expose-backends features enabled, so the parsers and backends are usable rather than sealed. ### What licence is Smelter released under? The repository does not use a standard licence identifier: it is recorded as a custom licence that GitHub cannot classify, and the Cargo manifest points at the LICENSE file in the repository. That file is the text to read before using Smelter in a product, rather than assuming a permissive licence. ## Sources - [Issues](https://github.com/software-mansion/smelter/issues) - [Project website](https://smelter.dev) - [README](https://github.com/software-mansion/smelter/blob/master/README.md) - [Releases](https://github.com/software-mansion/smelter/releases) - [software-mansion/smelter on GitHub](https://github.com/software-mansion/smelter) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/software-mansion-smelter