Widley inconsistent results :(

1080p, Preset 5 is sub 10fps
Preset 7 is all over. 10 to 20fps

Doesn't seem to get much faster than this.

Preset 10 is errr. I need to add more precision to the FPS counter. <1fps

Not much user for the typical end user but maybe worth leaving as a compile time flag?

Slower presets are really slow for a negligible quality improvement, but the medium one are comparable to svt-av1 slower one, with less visual artefacts.
To speed it up you can enable tiles if you have many cores, with tile-columns=1:tile-rows=1 or tile-columns=2:tile-rows=2 . Quality will be a bit worse, but it could be faster.

Any thing is strange, i can not compile it.

  : compilation terminated.
  : gmake: *** [../libhb/module.rules:37: libhb/hb.dll] Error 1
  : gmake: *** Deleting file 'libhb/hb.dll'
  : gmake: *** Waiting for unfinished jobs....
  : /home/thomas/toolchains/mingw-w64-x86_64/bin/x86_64-w64-mingw32-strip -s ./HandBrakeCLI.exe
-------------------------------------------------------------------------------
time end: Sat Apr  1 15:52:16 2023
duration: 10 minutes, 6 seconds (606.07s)
result: FAILURE (code 2)

The full log should contain some reference on what's gone wrong, the last lines are not useful.

OK i upload the build.txt
build.txt
config.info.txt
config.verbose.txt

collect2: fatal error: ld terminated with signal 9

I guess you need more ram.

You were right. Increased the memory from 2GB to 4GB and it works.

aomenc is very very slow in Handbrake. Only have around 10 fps and 40% CPU utilization, while with notenoughencoder I have around 25-30 fps and 100% utilization. Something doesn't seem to be going right.

Play with the tiles setting like I wrote above.

I pay with tile-columns and tile-rows. But it's also slowly, very slowly.
The strange preset 4, 5 and 6 have the same fps and the same CPU utilization
But it's nice to see another av1 encoder.

any news about libaom? Version 3.6.1 is out.

any news about libaom? Version 3.7 is out.

I'd also like to see this encoder implemented.

In my tests, libaom-av1 produces about 15-20% lower bit rate than svtav1 for the same psnr, ssim, and vmaf scores. For me, the smaller size along with fewer artifacts are worth the extra encoding time, which can be almost completely eliminated by running multiple instances. I'm not suggesting Handbrake should manage parallelized encoding. Though, that would be nice. Even svtav1 and x265 make fuller use of cpu when I'm running two instances of them.

Handbrake's customized nlmeans implementation having temporal awareness works great for removing flicker from old TV shows, with minimal quality loss. I was unable to get as good a result with ffmpeg's filters. Davinci Resolve worked well but that was a manual process requiring several steps to end up with an mkv containing av1 video and opus audio since it supports neither. So, I've been waiting to encode some old shows until Handbrake has libaom-av1.

@Mister-XY The reason you get faster encodes with libaom-av1 (or aomenc) using other apps (NEAV1E, av1an, etc.) is they split the source into pieces and run multiple instances of the encoder in parallel, then merge the encoded pieces together. The slow speed and low cpu utilization you saw are normal for one instance due to this encoder's poor multi-threading.

Hello,

Thank You,
The HandBrake Bot

On my old Intel Mac this was horrible slow, so I wanted to check how it performs on my new Apple Silicon Mac. But it fails to build because it is missing some latest HandBrake changes. Would it be possible to update this branch to latest HandBrake:master?