--cpu-used=4 --cq-level=16 --end-usage=q --lag-in-frames=48 --enable-fwd-kf=1 --aq-mode=1 --deltaq-mode=1 --enable-chroma-deltaq=1 --quant-b-adapt=1 --enable-qm=1 --min-q=1 --enable-keyframe-filtering=0 --arnr-strength=1 --sharpness=2 --enable-dnl-denoising=0 --disable-trellis-quant=0 --threads=64

• 30: Youtube-ish quality
• 20: Good quality
• 16: Very good quality
• 12: Visually lossless unless you pause and zoom in 4x

• Add --tune-content=screen if encoding a recording of your PC screen (this includes both presentations and games)
• Increase --arnr-maxframes to 15 if encoding anime
• Change --enable-keyframe-filtering to 2 if you're not worried about the fact that it has the potential to break playback or seeking on certain players.
• If using av1an, you probably want to set --disable-kf to disable scenecut detection (since av1an does scenecut for us), unless you have a special use case where you know you want aomenc's extra splits. You might also get a small performance/compression increase by setting --row-mt=0 since av1an removes the need for it.

• Add --tune-content=psy for live action or --tune-content=animation for anime
• Add --tune=image_perceptual_quality
  • If you can use --tune=butteraugli, it is preferred. However, it currently only works with 8-bit encoding.
• Change --deltaq-mode to 5 if encoding HDR content
• Increase --lag-in-frames to 64, 96, or 128 (higher = more RAM usage, 128 might cause problems for av1an users with a lot of workers)
  • Multiples of 32 are good because they provide optimal memory efficiency. A group of frames is 32 frames, so aomenc wants to load in a whole group at a time. Going from e.g. 64 to 65 will increase memory usage by considerably more than e.g. 63 to 64.

• Why --cpu-used=4?
  • My opinion is that 4 is the best balance of speed and quality. If you need to go faster, you can use 6 but understand compression will take about a 15% hit (it's still much better than x264). If you don't mind encodes taking forever, you can go to 3 or 2 for a little extra compressibility. I wouldn't use 0. Not even once.
• Why disable keyframe filtering?
  • The reason for not using --enable-keyframe-filtering=1 (which is the default) is that it has a long-standing bug which can cause very bad quality drops in certain high motion scenes.
• What do each of the settings do?
  • lag-in-frames is equivalent to lookahead in x264/x265, it helps make decisions for temporal bitrate allocation e.g. giving more bits to parts of the video that are visible for longer.
  • enable-fwd-kf is the equivalent of Open GOP
  • aq-mode=1 is variance-based spatial AQ. In the psy fork, it also has a low luma bias to help preserve detail in dark areas.
  • deltaq-mode is a form of temporal AQ. chroma-deltaq is intended to be the same for the chroma planes, but it's currently quite naive (equivalent of x264 chroma qp offset).
  • enable-qm enables quantization matrices. This gives a huge compression improvement at no speed cost. It should really be the default, but it's not for some reason. The default qm-min and qm-max are ideal, going lower than 5 for qm-min begins to produce worse video quality.
  • min-q=1 prevents the encoder from going into lossless mode, which is currently Very Buggy, so we want to avoid it.
  • arnr-strength=1 reduces the strength of Alt-Ref Frame Filtering. The default strength filters quite heavily. We lower this to 1 to retain more detail in the encode. (Some members will advocate for disabling it completely. My personal opinion is that there are still issues with rate distribution when ARNR is disabled that make me prefer to keep it enabled.)
  • sharpness is a pseudo-Psy-RD setting that allocates more bits to sharp areas of the video to prevent them from blurring. Either 2 or 3 seem to be the sweet spots. Higher than that begins to reduce quality of flat areas of the video by too much.
  • --enable-dnl-denoising=0 disables denoising when using grain synthesis. It does nothing if you're not using grain synthesis, but I put it here for those who do use it.
  • --disable-trellis-quant=0 does exactly what it sounds like and enables trellis-based quantization.
  • --threads=64 lets aomenc use up to 64 threads. The default is 1 thread, so you always want to set this, even if using av1an or even if not using tiles. There are still e.g. lookahead threads that you do not want to be bottlenecked waiting on the one encoder thread.