There's already a Rust AV1 encoder project you might want to look at: https://github.com/xiph/rav1e

Interesting, but since I could conceivably be exposed to a malicious AV1 stream, I'd value a Rust AV1 decoder even more (which might exist, I don't know).

That's a very good point. I chose Rust more to get ergonomics and more reliable threading - security was not the primary motivation. That said, the encoder is exposed directly to the web via the MediaRecorder API.

Indeed! This implementation was started by some people working on AV1 to test libaom's specification implementation correctness. There was a presentation about it at VDD17, if I remember correctly.

> There's already a Rust AV1 encoder

80% of codebase is C. How is that Rust encoder? Seems like a binding to C AV1 encoder.

The github counter is misleading - it is counting auto-generated C headers used for calling assembly code. The repo also contains a libaom submodule, but the only parts that are used are initialization tables and the transforms.

This hits me too on some projects of mine. Infuriating. I find wrong stats worse than no stats.

The stats aren't wrong. If it isn't 'real code' then you shouldn't store it in your repository, you should autogenerate it as part of your build process.

The C part is mostly for low-level functions and was brought in to help bootstrap development (it's easier to work on improving a working encoder than one that doesn't work yet). The amount of Rust code is expected to increase a lot over time, while the amount of C code is expected to either decrease or remain constant.

Isn't AoMedia supposed to provide a reference implementation? Is there any reason not to use it (an patch it along the way)?

It’s crap and slow as molasses built off an inferior earlier encoder’s codebase. It proves the concept, but it’s not something you want to need rely on in production.