Memory-Safe WebP Decoding

omoikane

I am not sure what's the current status of Wuffs-based WebP decoder, but that would be another implementation worth comparing since it shares the same goals of safety and speed. https://github.com/google/wuffs/tree/main/std/webp

jessa0

Related is Signal Messenger's webpsan crate, which validates webp container syntax before it is passed to libwebp. It stops just short of decoding actual pixel data, however, as the way webp works requires the entire canvas to be allocated in order to fully decode pixel data, which would have just made webpsan a full-on decoder anyway.. https://docs.rs/webpsan/latest/webpsan/

ZeroGravitas

As part of Google's PR for their upcoming Gemini 4 Argon LLM release they said they'd rewritten a few things in rust replacing hand written simd. But I don't think webp was mentioned. They said: > Large Scale Codebase Migrations and Optimizations: Argon agents are working on migrating C/C++ codebases to Rust across Google — scaling from tens of thousands of lines in core libraries like re2, libgav1 up to 800K+ lines for the Fuchsia Zircon kernel. Given the criticality of many of these systems, such large-scale rewrites are undergoing rigorous automated and manual auditing, emulation testing, and review before rolling out to production. > For libgav1, Google's open source software for decoding video, Argon agents took an existing Rust port and replaced 32K lines of SIMD code by running many rounds of profile-guided experiments, studying the compiler's output, producing safe Rust so the compiler would vectorize it automatically. The end result is a memory-safe video decoder that runs 2.7x faster than the Rust port, with identical video output, bringing it closer to the optimized C++.

pyrolistical

Why not just just have most of it in wasm? There are wasm runtimes that don’t require js, and I’m sure Google can adapt their engine. Then they could integrate the other side with rust

F3nd0

Not directly mentioned in the article: The decoder is licensed as free software and/but seems to have been developed with extensive use of Claude. It’s neat that you can compile it without hand-written assembly for more safety, but what does the performance look like in that case? I assume the presented benchmarks don’t show this?

burntcaramel

I’ve compiled libwebp to WebAssembly and made a web page to use it: https://qip.dev/webp-to-png You can also run the same wasm on the command line: npx @qip.dev/qipx qip.dev run \ image/webp/webp-to-ktx2-r8g8b8a8-srgb.wasm \ image/ktx2/ktx2-r8g8b8a8-or-b8g8r8a8-srgb-to-png.wasm \ < input.webp > output.png

pizlonator

webp builds with fil-C just fine if you want actual memory safety. This is great but it’s got caveats: - assembly code. They may have been careful but it’s an escape hatch - if it has basically any dependencies then those are likely to transitively pull in more unsafe code