Open Source,Remade with Rust

FFmpeg is the swiss-army knife of media — decode, encode, transcode, mux, probe, repackage just about any audio or video format ever shipped. It is also one of the largest C codebases in continuous production use, with two decades of CVEs in bitstream parsers, container demuxers, and codec arithmetic. Every browser that ships hardware video, every streaming service, every social media app depends on it — and inherits that surface.

ffmpeg (the remade_ffmpeg_rs repo) is a ground-up clean-room rebuild in safe Rust — not a wrapper around the C library, an entirely new codebase using the same wire protocols and file formats. The CLI is drop-in compatible: ffmpeg -i in.mp4 -c:v libaom -c:a libopus out.webm works the same way against upstream FFmpeg flags, plus an ffprobe binary for inspection. Image codecs (AVIF, PNG, JPEG, WebP, GIF, JPEG XL), audio (Opus, AAC, FLAC, Vorbis, PCM), video (AV1, H.264, VP9), and containers (MP4, WebM, AVI, WAV, OGG) all flow through one safe-Rust pipeline.

Apache-2.0 throughout the core library, CLI, and server — no GPL or LGPL dependencies, embeddable in closed-source products without the copyleft tax that upstream FFmpeg's GPL build carries. Many codecs already ship faster and higher-quality than upstream FFmpeg on the paths we've tuned; the project is pre-1.0 and honest about the full-parity work still ahead.

AI media processing today means gluing together half a dozen model runtimes — Whisper.cpp for speech-to-text, one of a dozen SDKs for text-to-speech, Tesseract for OCR, a fresh vision-language model every quarter for image and video understanding — each with its own build system, its own memory-safety story, and its own operational sharp edges. Every application that wants to touch audio, video, or image content ends up shipping a small archipelago of C and Python.

FFAI consolidates the four core AI media tasks into one Rust library and one CLI. ASR (automatic speech recognition) and TTS (text-to-speech) via the Mercury engine; OCR through Carmenta; VLM (vision-language model for image captioning and video understanding) via Argus. Common backbone is the Candle tensor framework; weights are downloaded from manifests rather than vendored, with per-model licensing surfaced transparently so you know what you're shipping. Streaming-capable pipelines throughout.

Library-first design — the ffai CLI is a thin surface over reusable crates, so anything the binary can do your app can call directly. Early benchmarks land at 15% faster than whisper.cpp with 7% better quality on the ASR path. Optional GPU acceleration behind feature flags; core still compiles and runs on CPU-only targets.

OpenAI Whisper became the reference for open-source speech recognition the moment it shipped — journalists, podcasters, enterprise transcription pipelines, and every offline voice interface reach for it first. The catch: every open-source Rust integration today either binds to whisper.cpp over FFI or shells out to the Python reference implementation, meaning a C or Python runtime sits on the hot path for one of the most latency-sensitive workloads an app can run.

Mercury is a pure-Rust reimplementation of Whisper on the Candle tensor framework. Custom mel-spectrogram pipeline, custom tokenization, custom decoding, hand-written AVX2 kernels — no Python runtime, no C/C++ dependencies by default. tiny.en and base.en models today; greedy decoding with full logit-filter grammar. Against whisper.cpp on LibriSpeech: 0.19 percentage points behind on clean speech, marginally ahead on noisy speech, roughly 1.12× slower on end-to-end throughput today — while running 1.38× faster than whisper.cpp's unfused encoder.

Dual-licensed MIT or Apache-2.0 for the code (model weights carry their own licenses). Mercury is the ASR engine that powers FFAI above and ships as a standalone crate so any Rust project can pull it in without the rest of the toolkit. Experimental today — beam search, streaming APIs, and larger models are next.

Object detection today runs through Python — Ultralytics' YOLO stack, PyTorch's runtime, ONNX Runtime for cross-platform inference. Every app that wants to identify or track objects in images ends up shipping a Python interpreter, CUDA userland, and a small stack of native libraries. Every deployment inherits that surface.

Diana reimplements YOLO26 in pure Rust — the full inference path, no Python, no ONNX runtime, no PyTorch. Five model tiers (n / s / m / l / x) from a single architecture, ByteTrack integration for cross-frame tracking, and a WebAssembly build so the detector runs directly in a browser. Weights stay user-supplied (Ultralytics' YOLO26 weights are AGPL-3.0; the Diana crate itself is MIT or Apache-2.0).

Measured against Ultralytics on a 45-image COCO test: 0.4× the memory footprint (121 MiB vs 310 MiB), 3.71× less CPU for equivalent work, and mAP identical to PyTorch to four decimals (0.7014). Correctness matches; the runtime is dramatically smaller.

OCR — pulling text out of an image or a screen — is a two-decade-old problem with two entrenched answers: Tesseract (C++, ancient, GPL-adjacent) and PaddleOCR (Python plus heavyweight ML dependencies). Neither slots cleanly into a modern Rust or WebAssembly deployment, and both push you toward either a legacy toolchain or gigabyte-scale models.

Carmenta is pure-Rust OCR on the Candle tensor framework — no Python, no C/C++, no GPL license infection. Detection, recognition, and a geometry-based reading-order pass (recursive XY-cut, no layout model needed) so text flows out in the right sequence without a separate structure model. LIVE streaming mode reuses results for unchanged frames so screen readers stop flickering. Deployment footprint: 4.7 MB of detector weights versus competitors' gigabytes.

The OCR engine that powers FFAI above, also published as a standalone crate so any Rust project can pull it in on its own. Dual-licensed MIT or Apache-2.0. On 43 test pages the character error rate is 23.76% CPU-only vs 15.51% for the state-of-the-art GPU stack — trades some accuracy for a runtime that fits on a phone. Experimental status; documents are the strongest use case, wild photographs the acknowledged weakness.

AV2 is the next-generation successor to AV1, currently under active development at the Alliance for Open Media. Until now the only implementation has been the C reference library, libavm — which means every browser, streaming service, and codec-toolkit vendor experimenting with AV2 has been running the same C code path with the same class of footguns.

rusty_av2d is the first independent AV2 decoder, written entirely in Rust with no C bindings and no unsafe FFI. Byte-identical output to the reference across all 45 conformance test clips. This is a research preview — AV2 itself is not yet a finalized standard, and the decoder is explicitly unoptimized (fully scalar, no SIMD or assembly kernels yet). Correctness came first; performance is next.

BSD-2-Clause licensed, inherited from the dav1d and rav1d lineage. Decoder-only for now; threading is present but under-tested. The point is that a memory-safe AV2 implementation exists in parallel with the reference — so when AV2 hits mainline use, there is already an independent codebase to audit against.

AVIF is how the web serves AV1 as a still image — the same ISOBMFF/HEIF shape as HEIC, wrapping AV1 bitstreams as pictures. AV2 has no equivalent container yet because AV2 itself is still pre-standard at the Alliance for Open Media, and AVIF's spec explicitly targets AV1.

rusty_av2f wraps AV2 still-picture bitstreams in the same AVIF shape, entirely in pure Rust. Both encode and decode — take a raw AV2 bitstream, seal it into a container; parse a container back, recover the payload byte-for-byte. 100% safe Rust, zero dependencies, no FFI. Sits alongside rusty_av2d as the still-image half of the AV2 story.

The four-character codes are chosen by this crate, not specified by anyone — the README is explicit. AV2 has no ratified spec yet, so this is a research artifact: if AOM eventually publishes an official AV2 still-image container, the format may change without a compatibility story. MIT-licensed, v0.x. Use it to experiment with the future of image encoding; do not ship it as an interoperability guarantee.

AV1 is the codec every streaming service and social platform is migrating to — better compression than H.264/H.265 at royalty-free terms — but the reference open-source implementations (rav1e for encode, dav1d for decode) leave real performance on the table on general workloads. Encoding AV1 at scale still means either paying for hardware acceleration or waiting.

rusty-av1-toolkit ships a performance-tuned pair: an rav1e encoder that runs ~1.10× faster with byte-identical output by default, plus a safe-Rust port of dav1d for decode. An optional --racecar flag unlocks about 1.69× encode speed by allowing bitstream changes on the hot paths where byte-identity is not the constraint. Turn it off, get stock rav1e output; turn it on, get the fast lane.

Fork of xiph/rav1e and the memorysafety-org rav1d, kept in sync with upstream. BSD-2-Clause on the toolkit itself; the AV1 patent grant is separately governed by the Alliance for Open Media Patent License. Drops in wherever rav1e or dav1d already do.

libopus has been the reference implementation of the Opus audio codec since 2012 — every voice call, every low-latency music stream, every WebRTC session touches it. It is also a battle-tested C codebase, which means every Rust project that wants Opus today reaches through FFI into a foreign memory-safety story, and every embedded target has to build the C toolchain to link it.

rusty-opus is a pure-Rust implementation of RFC 6716 (with RFC 8251 updates) — SILK for speech, CELT for music and low latency, Hybrid for the middle. Conformance-verified encoder and decoder. Zero C in the dependency tree, no FFI. The only unsafe code lives inside SIMD kernels: hand-written AVX2/FMA for x86-64 and NEON for ARM64, each gated behind runtime CPU-feature checks with scalar fallbacks.

Performance sits at or above libopus on CELT single-thread, and lands roughly 3× libopus on speech thanks to frame-parallel encoding. BSD-3-Clause licensed, derived from opus-rs and maintained as MATA Network's performance fork. Already integrated into the ffmpeg rebuild above for the Opus paths.

x264 and Cisco's openh264 are the two libraries every browser, every video conference, and every streaming app reaches for when it needs H.264. Both are massive C/C++ codebases, and between them they account for a long catalogue of CVEs in bitstream parsing, buffer handling, and motion-compensation arithmetic. Every app that links them inherits that surface.

rusty_h264 is a clean-room ground-up rebuild in pure Rust. The codec core is marked #![forbid(unsafe_code)] — zero unsafe blocks, no C in the dependency tree, no FFI. Bit-exact decoding against ffmpeg across the entire QP range (0–51) for both intra and inter frames, with rate control and motion compensation in the encoder. Constrained Baseline Profile today, with room to grow.

BSD-2-Clause licensed — permissive enough to embed in any product, no copyleft strings. Built specifically to be the codec layer for memory-safe video pipelines: the Comet host, the Starfire client, browser-side decoders, anything that should not ship a 25-year-old C buffer parser into 2026 production.

Every JPEG on the internet flows through some descendant of libjpeg — libjpeg-turbo for performance, mozjpeg for quality, the reference IJG code for portability. All three are C with long CVE histories in DCT arithmetic, marker parsing, and Huffman decoding. Rust projects reach for them via FFI, inheriting that surface every time an image is opened.

rusty_jpeg is a pure-Rust JPEG/MJPEG codec — both encoder and decoder, no C, no FFI. Baseline and progressive DCT, planar YUV I/O, quality and chroma-subsampling controls, round-trip validation in CI. SIMD kernels (AVX2/SSE4.1 on x86, NEON on aarch64) each ship with scalar twin fallbacks, and a platform_independent feature enables forbid(unsafe_code) for environments that need it.

Against FFmpeg 8.1.2 on identical hardware: 1.19× faster encoding at matched output size, 1.05× faster decoding. Licensed (MIT OR Apache-2.0) AND IJG — the IJG obligation attaches to forward-DCT code inherited from upstream. Continuous integration includes fuzzing and real-ARM hardware verification.

PNG decoding sits on the hot path for every browser, every design tool, every OS image loader. libpng is the reference: decades of C, a long CVE catalogue, the usual story. The pure-Rust alternative image-png delivers memory safety but leaves substantial performance on the table.

rusty_png is a performance-focused fork of image-png covering the full PNG feature spectrum: every color type, every bit depth, APNG, interlacing, encode and decode. Byte-for-byte compatibility with upstream across 600 test configurations plus the full PNG conformance suite. Configurable compression levels and filter strategies so you can trade size for speed per workload.

Against FFmpeg 8.1.2: decode 2.67–2.95× faster, encode at parity to 1.17× faster while producing 0.2–6.0% smaller files when the zlib-rs feature is enabled. Dual-licensed MIT or Apache-2.0. Measurement methodology in the README is intentionally unflattering to itself — the maintainers avoid cherry-picking to keep the numbers credible.

DirectDraw Surface (`.dds`) is the texture container every serious game engine reaches for — BC1 through BC7 block-compressed formats, mip chains, cubemaps, array textures, all of it. The tooling that reads and writes DDS files today is overwhelmingly C++: Microsoft's DirectXTex, NVIDIA's nvtt, the venerable texconv. Every asset pipeline that touches textures ends up shelling out to one of these, and every one of them has a CVE track record in header parsing and block decode.

rusty_dds is the same toolkit in pure Rust. Container ops covering both legacy D3D9 and modern DX10 headers. Decode from every BC1–BC7 variant to RGBA8. Encode from RGBA8 into BC1–BC5 and BC7 (BC6H/HDR deferred). GPU upload planning that emits API-agnostic strategies compatible with Vulkan, wgpu, and DXGI — so a game engine can pull a texture off disk and hand it to the graphics API without an intermediate copy layer. CLI too: rusty-dds info | decode | encode | retag.

Memory-safe by construction — no C dependencies in the core path, no FFI. MIT-licensed. Version 0.1, productization phase. Benchmarks land competitive with or ahead of DirectXTex on both encode and decode. Aimed squarely at game asset pipelines that want to stop shipping a C++ toolchain into their build system.

The general-purpose memory allocator in any long-running process — malloc, mimalloc, jemalloc, tcmalloc — is one of the highest-impact pieces of C code in the entire dependency graph. Every allocation, every free, every page fault flows through it. When it fails silently (double-free accepted, use-after-free hidden), the bug shows up somewhere else, hours later.

rusty_alloc is a pure-Rust reimplementation of the mimalloc 2.4.5 architecture — not a binding to the C library, an independent rebuild. Unsafe is confined to genuine OS-level needs; unsafe_op_in_unsafe_fn is denied workspace-wide. Key behavioral difference: a double free aborts instead of silently corrupting the heap the way upstream mimalloc does in release builds. Turning latent memory bugs into loud crashes is the point.

MIT-licensed, no GPL or LGPL dependencies. Version 0.3.2 today, API not yet frozen. On instruction counts across lua, perl, and sqlite the allocator hits parity with upstream mimalloc; the README is explicit that there is no "faster than mimalloc" claim yet because the evidence does not exist. Correctness and safety first, performance case still being built.

Wiring a custom global allocator in Rust is a three-line ritual — #[global_allocator], a static, a type. If every crate in a workspace tries to install its own, they conflict; if none does, you're on the platform default. For a workspace that wants everyone downstream to pick up rusty_alloc without thinking about it, that ritual needs to live in one shared crate.

rusty_alloc_default is that crate. A handful of lines doing exactly one thing: installing rusty_alloc as the process #[global_allocator]. Depend on it from your top-level binary and the whole workspace — every dependency, every proc-macro, every allocation on the hot path — runs through rusty_alloc automatically. The other Remade UI crates (rusty_tokens, rusty_symbols, rusty_a11y) opt in through it as their default rusty-alloc feature.

Ships with an optional secure feature flag that swaps in a hardened rusty_alloc variant. Applications that already have their own allocator (mata-alloc, jemalloc, mimalloc-rs) should disable default features on the Remade UI crates to avoid conflicts. MIT-licensed, version 0.1.

Every Rust UI framework — Dioxus, Leptos, Yew, Iced-on-web — eventually needs a theme. And every project ends up doing the same thing: scattering hex colors and rem values through templates, hand-writing a :root { --color-fg: ... } block, and hoping every child component reads from the same tokens. There is no shared contract.

rusty_tokens is that contract. Semantic CSS custom-property names (--rt-color-fg, --rt-space-4, --rt-radius-md) paired with neutral default values, exported as Rust const — so components reference color::FG and get the variable name at compile time. An optional css feature emits a complete :root {} block via root_sheet(). Categories cover color, space, type scale, and radius.

Consumers override defaults by shipping their own :root {} block downstream — the token names are the API, the values are opinions. no_std core with an optional allocator (rusty_alloc by default, opt-out available). MIT-licensed, version 0.2.0 stable, MSRV 1.73.

The moment a Rust UI needs a checkmark, an arrow, or a status glyph, someone types the raw Unicode character directly into a string literal. It works — until the source file round-trips through a Windows-1252 encoder somewhere in the toolchain and turns into mojibake. Or until the glyph renders as its text presentation on one OS and its emoji presentation on another because no variation selector was set.

rusty_symbols consolidates the glyphs into semantically named constants. Status indicators (ok, fail, warn, timer), navigation (arrows, branches), structure (rules, tree corners), math, lists. Every glyph lives once in source as a \u{...} escape sequence — never as a raw character — so the whole crate is ASCII-safe on disk. VS15 variation selectors are pinned on glyphs that need them, so the presentation stays consistent across platforms.

no_std-compatible with an optional allocator (rusty_alloc by default), works across Windows, macOS, Linux, web, and WebAssembly. MIT-licensed. Version 0.1.0 stable. Feature-gated so an embedded target can pull in only what it needs.

Accessible Rust UIs need the same ARIA markup any web app does — aria-label, role, aria-live — but the Rust web frameworks (Dioxus, Leptos, Yew) do not ship a shared helper for it. Every project reinvents the wheel: hand-escaping strings, remembering which live-region politeness fits which announcement, forgetting role="img" on decorative icons. The bugs are silent — screen readers just skip the interface.

rusty_a11y ships the small set of helpers that cover most of what UI chrome actually needs. Labelled glyphs (label::img, label::named) so icon buttons announce themselves. Live regions (live::polite, live::assertive) so sync-status and offline banners get read aloud. Status announcements (Saved, Syncing, Offline, Error, Ready) as first-class constants. Every helper returns an HTML string with proper escaping — no browser DOM binding pulled into your crate graph.

Framework-agnostic. Works with Dioxus, Leptos, Yew, or anything that accepts a string via dangerous_inner_html or equivalent. no_std-compatible with allocator support. MIT-licensed, version 0.2.0, MSRV 1.73.

Every Rust deploy today assumes crates.io is up, that RustSec is reachable, and that the hash you locked yesterday is the hash you will get today. It is mostly true — but supply-chain incidents in the last few years (typosquats, credential exfiltration in postinstall scripts, package takedowns) have shown that "mostly" is not a security posture. And when crates.io goes down, so does your build.

Deputy is a personally-owned dependency vault. It reads your Cargo.lock, fetches every crate in the transitive closure, SHA-256-verifies each one against the lockfile checksums, and seals them into an encrypted local vault. Content-addressed storage with deduplication across your repos. From then on, your builds source from Deputy — not the internet — so a crates.io outage or takedown cannot stop them. Advisory scanning against RustSec with CVSS v3.1 severity, integrity/substitution detection that catches re-published versions with different hashes, and supply-chain risk signals (build scripts, proc-macros, unsafe usage, FFI surface) surface before the crate ever reaches production.

Complementary to existing tools rather than a replacement. Dependabot and Renovate push updates; Deputy archives and gates them. Snyk and cargo-vet scan; Deputy scans, archives, verifies, and blocks. One system for acquisition, verification, offline resilience, and promotion. Dual-licensed Apache-2.0 or MIT. Active development, library crates published on crates.io.

OAuth, OIDC, Auth0, Clerk, Firebase Auth — every off-the-shelf "Sign in with X" button on the web routes through a third-party provider you have to register with, configure client IDs for, and pay a per-monthly-active-user fee to once you cross their free tier. The provider sees every login, every site, every time.

Sovereign ID flips the model. The user's identity is a keypair on their own device; sign-in produces a token they cryptographically sign, and your backend verifies it entirely locally — no fetches to MATA, no JWKS endpoint, no DID resolver to call. Four npm packages cover the surface: browser SDK, backend verifier, statement verifier, and React bindings. MIT-licensed, zero external dependencies.

Live integration documented in the Freedom Guide. Powers the Sign in with Sovereign ID button you can drop onto any website with one component and a backend verifier call.

Most Rust web stacks today verify identity tokens by talking to an external authority — Auth0's JWKS endpoint, Clerk's verification API, AWS Cognito's token introspection. Every login is an extra round-trip out to a third party, and every outage on their side is an outage you inherit.

mID is the Rust counterpart to the Sovereign ID JavaScript verifier. A user's identity is a keypair they hold on their own device; sign-in produces a token that mID verifies entirely in-process — no I/O, no JWKS, no DID resolver. Works natively on every Rust target and via WebAssembly where native won't run. Dual-licensed Apache-2.0 OR MIT.

Pairs with the sovereign-id JavaScript SDK on the client — both speak the same wire format. Drop mID anywhere you would have called Auth0: Axum middleware, Actix extractor, an edge function, a desktop app. The verification stays in-process, the user stays in control of the keypair.

Cloud databases — Firebase, Supabase, DynamoDB, Postgres-on-RDS — assume always-on infrastructure, a single source of truth that lives in a data center, and a network round-trip for every read and write. The model breaks the moment a user goes offline, the network partitions, or the data needs to live near someone instead of in a US-East-1 rack.

SpaceDB is the opposite: a local-first database that stores encrypted app data across machines near the users who own it, with automatic CRDT convergence when replicas reconnect and offline-first operation by construction. Per-field consistency tiers (convergent, causal+, strong) so a single schema can mix eventual and strong consistency where each fits. Capability-based access control with expiry and budgets, built-in vector search that keeps the corpus local, deterministic compute-to-data with attestation, and honest freshness reporting.

Pluggable transport, storage, and crypto seams — operators implement whatever fits their environment, and no SpaceDB crate depends on any proprietary code. Dual-licensed Apache-2.0 OR MIT, free to embed in applications and run on personal devices indefinitely.

Moonlight is the open-source implementation of NVIDIA's GameStream protocol — the client that lets you stream a PC game session to a phone, tablet, Steam Deck, set-top box, or any other device on your network. It is excellent software, and like most game-streaming clients, it is written in C and C++ across a decade of accumulated networking, decoder, and input-handling code.

Starfire is the same idea, rebuilt from the ground up in Rust. The protocol surface stays compatible so existing GameStream hosts and Sunshine servers keep working, but the entire client — packet parser, video decoder bindings, input pipeline, network state machine — is memory-safe by construction. The classes of bug that historically ship as CVEs in game-streaming clients (buffer overflows in RTP parsing, integer overflows in frame-size handling, use-after-free in the decoder lifecycle) never compile in Starfire.

Built for the same hardware Moonlight runs on — desktop, mobile, embedded — with the same low-latency target. Active development; star the repo to follow along.

Sunshine is the open-source streaming host that powers most self-hosted GameStream setups today — capture the desktop, encode it with whatever hardware is available, deliver frames to a Moonlight client elsewhere on the network. It is GPLv3, written largely in C++, and carries the memory-safety surface that comes with that lineage.

Comet is the same role, rebuilt from scratch in Rust. Hardware-encode-first across NVENC, AMF, QuickSync, and VideoToolbox; a zero-copy capture-to-encode pipeline that keeps frames on the GPU; the same GameStream wire protocol so existing Moonlight clients keep working, plus a Comet-native mode that pairs with Starfire for the lowest end-to-end latency on the stack.

Measured against Sunshine + Moonlight on identical hardware: 2.1× better host latency, 3.8× better decode latency, and a sub-millisecond capture path. Shipping target is Windows desktop and gaming workloads first, with macOS host support tracking VideoToolbox.

Comet is MATA's proprietary host implementation. The Starfire client and shared protocol crates remain open source; the host stays in-house.