Rav1e, an AV1 encoder written in Rust and assembly

I was unable to find any evidence of this anywhere I looked. For instance this webpage: https://www.webmproject.org/docs/container/ shows only VP8 and VP9 as acceptable video codecs.

Given Apple is an AOM governing member it's pretty likely Apple will eventually support AV1 (and AVIF).

VP9 is simply not on their roadmap at all, it's not a "yet" thing.

This is a very misleading statement.

AV1 encoders are slow because they're slow, not because they're not hardware accelerated.

x264 and x265 are not hardware accelerated, either.

This is also often true for cryptographic software, particularly fixed-parameter optimized code.

The performance gain usually comes from some mixture of good scheduling or register allocation that the compiler fails at and the use of instructions that the compiler won't (reliably) emit.

For these kinds of straight-line codes, I haven't found mechanically validating them to be significantly more complicated than verifying C code... and as C code these functions tend to be the lowest risk type.

So, without any direct experience, I'd expect there to be more risk in rav1e from the unsafe-rust than the asm.

That said, already the 'attack surface' of an encoder is pretty small. I'd personally expect rav1e's gain from rust's safety would be less security and more in avoiding wasting time on blind alleys caused by memory corruption in the codebase. I've seen more than one poor design decision made in a multimedia codec which was ultimately due to a bug that a better language might have prevented.

By focusing on an encoder (at least initially) you can just support a subset of features that work well for you. Then focus on making a decoder that can at least play back videos from your encoder.

More people will find it useful to have an encoder that works all the time, rather than a decoder that only works on a subset of videos.

> ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues

https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

There are similar reports from other organizations.

For any reasonable definition of "safer", yes. 100% safe? no.

[1]: https://www.theverge.com/2018/1/4/16805216/google-chrome-onl...

[2]: https://www.computerworld.com/article/3199425/top-web-browse...

[3]: https://erik.itland.no/chrome-is-the-new-internet-explorer-4...

There are some cloud providers that offer this as a service, allowing you to have the end-points of, e.g., video calls to use different audio and video codecs.

This is quite useful, e.g., when some people join the call only using audio via a cell phone in a different country using a different audio standard (or a land line, etc.). Or when somebody joins the video call from laptop tethering from a phone on a train. Or for switching video codecs depending on whether somebody is sharing their desktop or using a webcam to record their face.

The client can picks the codecs that are the best fit for the current situation (content, bandwidth, latency, etc.) and a could server transcodes the video from everyone else in the meeting to their clients format.

The main enabler of more advanced compression strategies is the higher performance available to the encoder. Decoders are essentially deterministic state machines. Encoders however have to search a large space of transformations to find ones that captures the entropy for a given situation.

In the development of AV1 they called these transformation "tools" and the research encoder experimented with lots of them and only the most profitable ones made it into the standard.

The compression can thus still evolve even with the AV1 standard frozen, just like how x264 and LAME have gotten so much better over their lifetime.

That's quite thought provoking.

What do you see when the current generation codec is heavily bitrate constrained? First thing you'll notice are the ugly blocks with non-matching colors on the edges. Such primitive expression of lack of bitrate is showing quite clearly these codecs have very little understanding.

With a codec of the (probably far) future where both encoder and decoder have good "understanding", you wouldn't see any blocks, lower color depth, smudged details or so. If some detail is missing because of constrained bitrate, decoder will just fill it in intelligently.

It can go crazy far - when constrained with bit rate, the encoder can just send sort of a movie script - "Man stands on the beach and looks into the distance" and the decoder will "understand" it and render it in awesome detail including adding non-mentioned splashing waves, man's thinking expression and perhaps sunset (decoder effectively becomes little automated film director who takes missing information in movie script as artistic license). It will most probably look very different from the original movie, but it will be believable - if you didn't see the original then you won't really have a reason to suspect it's fake.

With more bitrate available you can add more detail to the movie script - the man is black and old, he wears this and that which the decoder would take into account when reconstructing the video. At some point you're always constrained on the bitrate, but "understanding decoder" can always go deeper and fill in more realistic details when needed.

https://vimeo.com/blog/post/av1-new-standard-codecs/