RAV1E: The "Fastest & Safest" AV1 Encoder

[Weasel]

Don't know what kind of videos you're making but if you're covering some news event then you'll film and get some good a and b roll before and a bit after lunch and then edit and encode and upload. "overnight" isn't an option. same applies if you're live-streaming, if you can't encode real-time with a codec then that codec's no good. vp9 doesn't work for either of those use-cases - thus it's useless.

Wah VP9 doesn't cover my niche use cases, must be useless garbage.

All mainstream OSes don't handle some critical but extremely niche use cases. They must be useless garbage also.

[Grinch]

Why is encoding VP9/AV1 too slow, besides lack of optimizations? Is the algorithm too complex or what?

Well, lack of optimizations is the largest factor right now for AV1, given that there is a lot of optimizing/rewriting into hand-written assembly to be done in order to maximize performance.

However even when fully optimized, it will be slower than HEVC given that it is using more complex compression, how much the difference will be is something we will have to wait and see.

[Grinch]

As it stands right now, though.. I'm not going to render a video in VP9 and wait two months for it to finish. AV1 will pretty much be dead to me too if it's situation remains similar.

I recall reading that Google split up the videos in chunks and encode them in single thread modes across huge clusters, and I would imagine the same holds true for Netflix/Amazon, meaning there's no pressing need for them to improve multi-threaded encoding.

On the positive side, there are alternate encoder versions like RAV1E in the works that can fill this niche, and the developers of x265 have stated that they will 'follow the market' in a response concerning a future AV1 encoder from them.

[leiptrstormr]

Input videos must be 8-bit 4:2:0, in y4m format.

Why not try to get this implemented in FFMPEG? It's borderline worthless on its own.

[juno]

Will AV1 CPU de- and encoding even be usable in the upcoming years?
VP9 and h.265 are several years older and still slow.

I mean, it's not so bad once fixed function hardware shows up. But GPU vendors already took quite long for HEVC and VP9...

[ZeDestructor]

Is it google not caring or rather Google and the entire industry moving on? My impression is that Google moved on when the industry got on board with the idea of an open standard.

I recall reading that Google split up the videos in chunks and encode them in single thread modes across huge clusters, and I would imagine the same holds true for Netflix/Amazon, meaning there's no pressing need for them to improve multi-threaded encoding.

On the positive side, there are alternate encoder versions like RAV1E in the works that can fill this niche, and the developers of x265 have stated that they will 'follow the market' in a response concerning a future AV1 encoder from them.

Dingdingding. For Google and Netflix and everyone else in web media, they don't care about threading the encoder, because there's always enough other videos in the queue that they can saturate their (typically commodity x86) processors just fine.

Don't know what kind of videos you're making but if you're covering some news event then you'll film and get some good a and b roll before and a bit after lunch and then edit and encode and upload. "overnight" isn't an option. same applies if you're live-streaming, if you can't encode real-time with a codec then that codec's no good. vp9 doesn't work for either of those use-cases - thus it's useless.

I f you need a fast encoder, you do it in hardware (like on phones - mine has bothe VP9 and HEV hardware encoders), use a less efficient, but faster codec (most broadcast media is still on H.264 at best, with manny still lagging behing on H.263, or even H.262, even for 1080p broadcast), or just take a bitrate and/or quality penalty and use faster encoding algorithms/settings.

Why not try to get this implemented in FFMPEG? It's borderline worthless on its own.

It'll get there when it's ready. Don't worry about it.

Will AV1 CPU de- and encoding even be usable in the upcoming years?
VP9 and h.265 are several years older and still slow.

I mean, it's not so bad once fixed function hardware shows up. But GPU vendors already took quite long for HEVC and VP9...

GPGPU was fairly quick to pick up VP9 and HEVC using hybrid methods (partial decode on the H264 and older decoder blocks, remainder done on the GPU itself). Mobile devices lagged on H.264 until full fixed-function blocks showed up, but they showed up only about a year late to the full mass-market adoption.

[xiando]

With decent quality settings vp9 falls down into single digit fps, like 2-3fps and only manages to load the cpu at about 25% which does make me a bit sad, but it's usable for short videos.

And that's why I go so far as to call it "useless". In practice it's just too slow to be usable for anything beyond creating less than 3 MB clips for 4chan. But those have to be VP8 not VP9 for some reason. 2-3 fps just ain't good enough and throwing more cores at it doesn't actually help.

[dwagner]

Why not try to get this implemented in FFMPEG? It's borderline worthless on its own.

This is a Mozilla project, their attitude towards programming is almost the opposite of how ffmpeg developers approach things.

My advise would be to wait until some encoder (probably not one written in Rust) becomes part of the ffmpeg project, by then there will be a chance it is actually good and decently fast.

[Guest]

It seems stupid to depend on hand written assembly for faster encoding/decoding. Wouldn't compiling with march=native and mtune=native take you atleast part of the way there? (If not all the way)

Also, good encoding performance is important for several home use cases, including video calls, casting your screen elsewhere, recording or livestreaming applications and games.

[Gusar]

It seems stupid to depend on hand written assembly for faster encoding/decoding. Wouldn't compiling with march=native and mtune=native take you atleast part of the way there? (If not all the way)

Doesn't the fact that x264 and x265 devs have spent years writing assembly answer your question? Why would they do that, spend all that time and money, if a simple march=native would do the trick? The answer is that C/C++ (or rust, which is what rav1e is written in) compiler optimizations don't even come close to hand-written assembly. Of course it depends on the application. But multimedia is what all those extensions (MMX, SSE, AVX) were created for, so multimedia (audio and especially video codecs) is where you see the biggest gains with hand-written MMX/SSE/AVX assembly.