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

[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]

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.

[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.

[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?

[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?

[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.

[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.

[skeevy420]

I never said anyone with an opinion is a troll. I'm saying that almost any thread involving Rust will have at least one person gripe about Rust, and said person usually doesn't have a good-faith argument and just spews strawmans.

And I will gladly respond to strawmans and bad-faith arguments with actual arguments and facts.

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

FWIW, this language sucks for reasons happens in every thread about any language.

[aspen]

Well. That was sort of the point. The less than ideal way of starting a thread.
A fresh account and calling everybody with an annoyance/opinion a troll...
And yes, we digress.

Rust has some points SVT-AV1 has others. But comparing them seems a little bit apples to oranges when you're talking a magnitude of speed.
So what I'm trying to say, I guess, is that they probably have different users with very different needs.
If I was doing encoding for a product/platform/content, I would not spend 10x CPU cycles to do encoding for the same quality etc, unless something very specific is needed. But that's just me.

I never said anyone with an opinion is a troll. I'm saying that almost any thread involving Rust will have at least one person gripe about Rust, and said person usually doesn't have a good-faith argument and just spews strawmans.

And I will gladly respond to strawmans and bad-faith arguments with actual arguments and facts.

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

[aspen]

Bl*dy hell .. but why it is wrytten in rust?
It is fundamental design issue using tooling which forces to use own build automation (cargo) and still is very unstable! (from design perspective)

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)