Rav1e 0.4 Released For Faster Rust AV1 Encoding - But Still Is Quite Slow

[milkylainen]

Also, what's your "minimum age" for an account to say something without you automatically assuming that they're a troll?

42...?
I think mostly keeping the discussion related to topic somewhat is my bar. No age really.
15 posts and beginning a thread with "trolls something" will trigger a filter for a lot of people.

q.e.d, back to topic.

[BlueSwordM]

When looking at encoder speed, you always need to look at 2 factors:
- Single threaded encoding.
- Multi-threaded encoding.

In regards to the 1st point, all the current AV1 encoders(rav1e, aomenc-av1, SVT-AV1) are actually quite similar in terms of speed.

The difference comes to multi-threaded encoding:
1. rav1e has no threading other than tile-threading IIRC.
2. aomenc-av1 has tile threading, row threading(row-mt), and more recently, temporal threading, but no frame parallel threading.
3. SVT-AV1 has tile threading, row-mt, and frame parallel threading, which is why SVT-AV1 is overall the fastest in terms on single encoder testing, but aomenc-av1 has improved in this regard, which is nice. That is true mostly for the higher speeds(4-8). Once you get down to lower speeds, the encoder becomes less threaded and quite a bit slower.

That's basically a wide overview of the situation.

[kloczek]

i can't tell if this is a tongue-in-cheek response to my remark, which if that's the case, kudos, you nailed the "average Phoronix troll" nail right on the head.

if it's not a joke, well, do they need a reason to write it in Rust other than "we want to and can reasonably do so"? (people seem to forget that it's entirely possible to just compile rust with rustc directly, but like, why? cargo is better than most other languages' automation systems, and there's decent solutions for integrating with other build automation systems anyways)

So you want to say that you don't have any rationale argument which can crush what I wrote and instead you want to talk about me or trolls?
Really sorry to disapoint you but I'm not interested your new subject.

Do you have anything to add in context of usig rust currenty?

If you want to some good example of not using rust just try to compare librsvg used by gnome/gtk written in rust and SVG support in qt5.
Parser/saver and renderer code is written in c++ in case of qt5 and acual code is few times smaller (the same is about actuall binary code).
Both parsers/savers/renderres are multiithraded (just if anyone will be asking).

PS. FYI I'm system/software eng with already +25y career. What you've been doing 25y ago?

[Mitch]

When looking at encoder speed, you always need to look at 2 factors:
- Single threaded encoding.
- Multi-threaded encoding.

In regards to the 1st point, all the current AV1 encoders(rav1e, aomenc-av1, SVT-AV1) are actually quite similar in terms of speed.

The difference comes to multi-threaded encoding:
1. rav1e has no threading other than tile-threading IIRC.
2. aomenc-av1 has tile threading, row threading(row-mt), and more recently, temporal threading, but no frame parallel threading.
3. SVT-AV1 has tile threading, row-mt, and frame parallel threading, which is why SVT-AV1 is overall the fastest in terms on single encoder testing, but aomenc-av1 has improved in this regard, which is nice. That is true mostly for the higher speeds(4-8). Once you get down to lower speeds, the encoder becomes less threaded and quite a bit slower.

That's basically a wide overview of the situation.

I thought that I had read that speed / thread count had some impact on the quality or space efficiency of the resulting video. Is that true?

[BlueSwordM]

Mitch That is true for both parts, yes. Higher speed presets = higher speed and theoretically, less encoder efficiency.

Also, some forms of parallelism do have downsides in terms of quality. Tile threading for example has higher efficiency losses as you up the tile count, and frame parallelism has the same downside, although less severe and comes with a bigger speedup comparing to other methods of threading.
Row threading basically has negligible efficiency losses, so it is a form of threading which is activated by default in most modern encoders that feature it, including SVT-AV1, aomenc-av1, x264, x265, etc.

[aspen]

So you want to say that you don't have any rationale argument which can crush what I wrote and instead you want to talk about me or trolls?
Really sorry to disapoint you but I'm not interested your new subject.

Do you have anything to add in context of usig rust currenty?

If you want to some good example of not using rust just try to compare librsvg used by gnome/gtk written in rust and SVG support in qt5.
Parser/saver and renderer code is written in c++ in case of qt5 and acual code is few times smaller (the same is about actuall binary code).
Both parsers/savers/renderres are multiithraded (just if anyone will be asking).

PS. FYI I'm system/software eng with already +25y career. What you've been doing 25y ago?

Your post is barely coherent. If you want to be an elitist nitwit, go to HN instead. Actually no, Phoronix is perfect for elitist nitwits, it's a good containment forum. Keeps them away from everywhere else.

I'm tired of idiots saying that everything should be C or C++ instead. Rust has it's clear advantages and disadvantages, and so does C/C++, most things have both pros and cons, but ultimately, whoever is willing to put in the work to maintain a project gets to decide how they do so, and unless you want to maintain their software for them, you don't get a say in it.

I've looked through many posts relating to Rust - whether it's relating to Rav1e, bzip2, Mesa, Linux kernel modules, whatever, someone like you always bursts in and tries to play chess like a pigeon.

I am not interested in what career you have or however many years you've been toiling away in said career. I just want it to be very well known that you kinda don't get to bash the methods being used for anything unless you're fully willing to do it whichever way you feel is "right", but most people who complain on online forums are the kind of people who would never actually put in the effort to do it "right".

Also, once again, I can't really refute whatever you're going on about unless you can rewrite it in coherent english, because nobody has any clue what you're saying, to put it lightly.

[andreano]

I thought that I had read that speed / thread count had some impact on the quality or space efficiency of the resulting video. Is that true?

The speed setting, obviously, but other than that, tiles. Splitting the video up in tiles makes the encoding a few percent less efficient, but makes it possible to use tile threads on both the encoder- and decoder side. → Worth it at high resolutions.

[aspen]

When looking at encoder speed, you always need to look at 2 factors:
- Single threaded encoding.
- Multi-threaded encoding.

In regards to the 1st point, all the current AV1 encoders(rav1e, aomenc-av1, SVT-AV1) are actually quite similar in terms of speed.

The difference comes to multi-threaded encoding:
1. rav1e has no threading other than tile-threading IIRC.
2. aomenc-av1 has tile threading, row threading(row-mt), and more recently, temporal threading, but no frame parallel threading.
3. SVT-AV1 has tile threading, row-mt, and frame parallel threading, which is why SVT-AV1 is overall the fastest in terms on single encoder testing, but aomenc-av1 has improved in this regard, which is nice. That is true mostly for the higher speeds(4-8). Once you get down to lower speeds, the encoder becomes less threaded and quite a bit slower.

That's basically a wide overview of the situation.

Huh, is there anywhere I can read up on the different types of threaded encoding? I'm curious about all this ngl

[BlueSwordM]

aspen For tile threading, there's a very good article about it by rav1e devs:

https://blog.rom1v.com/2019/04/implementing-tile-encoding-in-rav1e/

For block based row threading, you have this from ittiam:

https://www.ittiam.com/vp9-video-encoder-faster-turnaround/#

And this for a more in depth explication about a similar method to row-threading and frame parallelism:

https://x265.readthedocs.io/en/stable/threading.html

[andreano]

There is some truth to this: The state of AV1

… cpu-used=1 by default and no one knows what tiling is …