-cpu-used 9 does not work with libaom's realtime mode

[veikk0]

Summary of the bug:

FFmpeg exits with an error message when attempting to invoke libaom's realtime mode with -cpu-used 9.

Speed 9 was added to libaom some time ago. It's only valid for realtime mode, however.

Note that #9335 affects running libaom in realtime mode, and it may or may not prevent successfully using realtime mode even if this issue is fixed.

Error message:

[libaom-av1 encoder @ 0x55af2e7b3f40] Value 9.000000 for parameter 'cpu-used' out of range [0 - 8]
[libaom-av1 encoder @ 0x55af2e7b3f40] Error setting option cpu-used to value 9.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

How to reproduce:

ffmpeg -i input.mp4 -an -c:v libaom-av1 -cpu-used 9 -usage realtime -b:v 0 -crf 40 -y cpu9.mp4

Version and build information:

ffmpeg version N-102971-g13ec6624b3
built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)

[veikk0]

This is still an issue as of current FFmpeg git.

Speed setting 10 was also introduced in libaom v3.2.0 (released on 2021-10-13). So now there are two libaom speed settings that aren't functional from FFmpeg, severely limiting FFmpeg's usefulness for real-time AV1 encoding.

[Balling]

Shpuld not it also warn on working 8 if it is used without -usage realtime`? As you said here: ​https://trac.ffmpeg.org/wiki/Encode/AV1?action=diff&version=39

[veikk0]

Within libaom, cpu-used values higher than 6 are just mapped to 6 in the "good" usage mode (with the exception of 10, which seems to fail with an out of range error, at least when I try it with aomenc... so it's not consistent even within libaom itself).

If someone wants to implement and maintain the logic of the allowed values (which have changed over time with the various libaom versions, so compatibility would also need to be considered), then sure, I guess warnings could be a thing on FFmpeg's side. I don't see that as the best idea, seeing as this issue has been open for a while. It'd be less effort to just pass the value to libaom and let it handle things rather than building a lot of logic for working around libaom's quirks.

There's also the "allintra" usage mode, which I have no experience with and thus have no idea if it has its own allowed value range or mappings. So if additional messages/limitations were implemented, that would also need to be looked into.