Speed

[LuisB79]

Remove the "Fastest" claim until it outperforms svt or aomenc.

[barrbrain]

See the summary in https://github.com/xiph/rav1e/releases/tag/p20210518 for the current basis of claim. We will revisit this when MSU Video Codecs Comparison 2022 results are released. The range of speeds tested will be wider and subjective performance is expected to have improved.

[veikk0]

I think changing this claim is long due. Anyone who has used SVT-AV1, libaom, and rav1e recently is aware that speed isn't a category rav1e is competitive in.

The current slogan "The fastest and safest AV1 encoder" is seriously misleading to users. See this StackExchange question for example. The discrepancy is so large that users are wondering if they're being stupid and not using the encoder correctly, because rav1e describes itself as the "fastest" but only operates at ~10% the speed of SVT-AV1's fastest preset. This isn't the first time I've seen this question either, just one example.

Misleading claims have traditionally been the domain of proprietary encoders rather than FOSS ones. I think we should keep it that way.

"The safest AV1 encoder" would be sufficient IMO, as it emphasizes the project's use of Rust.

[LuisB79]

Agreed, current iterations of svt and libaom really outperform in terms of speed

[vibhoothi]

Agreed, current iterations of svt and libaom really outperform in terms of speed

Probably due to the fact that we do not have an army of full-time developers to develop rav1e, and we are just doing it in our free-time;)

[LuisB79]

Agreed, current iterations of svt and libaom really outperform in terms of speed

Probably due to the fact that we do not have an army of full-time developers to develop rav1e, and we are just doing it in our free-time;)

As sad as that may be, it still isn't the fastest