--tiles 1 --speed 1 produces lower quality nearly same filesize output than --tiles 8 --speed 3 with same quantizer

[CounterPillow]

The input file was the following: http://fratti.ch/mediasamples/chansu.y4m

Sample A was encoded with --tiles 8 --speed 3 --quantizer 150: https://fratti.ch/mediasamples/chansu_slow.ivf

Sample B was encoded with --tiles 1 --speed 1 --quantizer 150: https://fratti.ch/mediasamples/chansu_slower.ivf

As one can see, sample B took longer to encode (duh), looks worse in several places that I could find, and is larger than about the same size as sample A.

My expectation is that the encoder being allowed to use slower algorithms and look at the entire frame should produce higher quality or lower filesize output at the same quantizer level.

[metroidchild]

I don't think there's anything inherently wrong with the encoder in this case, I think it's just a matter of lacking documentation to understand how it should (and does) behave.

The quantizer parameter (QP) can be thought of as: "higher QP = reduced quality" (which typically causes a lower bitrate).

The speed parameter can be thought of as: "higher speed = less intensive to compute" (which typically causes a higher bitrate).

I tried encoding with the same flags as your Sample A but instead using a speed of 10, and the size only increased by about 23%. This had the same quality due to the same QP, but it was over 5x faster to encode, so the lack of space savings you see in your test is likely just the effects of diminishing returns.

If you want to get a different quality from the same bitrate you can use the --bitrate flag and then chose different speeds as usual.

A bitrate of 2000 is roughly what your encoded samples have, I felt there were diminished returns above a speed of 4 since the encoding time increases much faster than I perceive the quality to increase.

[CounterPillow]

Thanks, I know how encoders work though. The problem is that I can spot several frames in which the lower speed setting causes certain frames to look worse. Furthermore, it's not just speed that is being adjusted; tiling should have an impact on the efficiency of the encoder, deactivating tiling seemingly not making any difference hints that something isn't quite right.

[shssoichiro]

Could you see if speed 2 is better or worse than speed 3? Speed 1 activates a feature called bottom-up encoding, which is basically an alternative algorithm for how rav1e will choose block and transform types. If anything is causing this, I suspect it would be that feature, because it takes the encoder through an entirely different path.

[shssoichiro]

Scratch that. I was researching something unrelated, and I accidentally stumbled on the finding that setting the min block size to 4x4 (which we do at speed 2 and below) results in significantly worse compression than 8x8. Spreadsheet of results here.

[shssoichiro]

Okay, time for the weird part. I couldn't reproduce these findings in AWCY. Here is what AWCY shows:

Speed 6 to 5
Speed 5 to 4
Speed 4 to 3
Speed 3 to 2
Speed 2 to 1

[ycho]

Sample B was encoded with --tiles 1 --speed 1 --quantizer 150: https://fratti.ch/mediasamples/chansu_slower.ivf

Hi, thanks for sharing the case.
It seems the 2nd bitstream is corrupted, so could you upload it again please?

lassen:rav1e yushin$ ls -al ~/Downloads/chansu*.ivf
-rw-r--r--@ 1 yushin staff 1255449 Jan 6 11:09 /Users/yushin/Downloads/chansu_slow.ivf
-rw-r--r--@ 1 yushin staff 312 Jan 6 11:12 /Users/yushin/Downloads/chansu_slower.ivf