Proposal: faster AOM encoding for the AVIF realtime preset

[gregbenz]

I'd like to explore options for faster AVIF encoding. My initial testing shows the potential for significantly faster encoding, with modest changes in the quality metrics on the two images tested.

I see two potential approaches:

• UHDR_USAGE_REALTIME could be updated to select faster AOM encoding for AVIF.
• A new API could be offered to select AOM encoder speed. This would let callers choose encoding effort independently of gain-map generation and allow REALTIME to remain unchanged if preferred.

In the tested configuration, both presets use AOM speed 6. Realtime changes gain-map generation but does not reduce AV1 encoding effort. Setting speed 8 for both the base image and gain map gave these results, comparing current realtime against realtime with only that change:

Input	Full JPG-to-AVIF time, speed 6 → 8	CPU reduction	File-size change
1080×1080 photographic composite, 1:1 RGB gain map	271 → 113 ms	64%	−0.5%
384×512 iPhone photo, 1:2 output gain map	66 → 18 ms	74%	+0.1%

These are measurements on an Apple M5 Max using libultrahdr f3e3622, libheif 1.19.7 with the repository's gain-map patch, and AOM 3.14.1. Base/map quality settings were 90/85 in testing (vs library defaults of 95/95). Tests used warmups and balanced run order, with file I/O and verification outside timing. Each request decoded the source JPEG into HDR and SDR and encoded gain-map AVIF at the same dimensions.

There is a quality tradeoff. SDR PSNR fell about 0.4 and 1.1 dB, respectively; HDR reconstruction log-RMSE increased about 4% and 1%. Those HDR figures measure numerical error, not perceived quality loss. The composite measurements cover its photographic regions, excluding text and test patterns.

A separate synthetic test using the best-quality preset produced a file about 15% larger that took about 15% longer to decode at speed 8. I'd also check those tradeoffs across more photographs before submitting a PR.

These results look promising, but need further testing to support a PR. I'd like to gauge support for the approach before proceeding.

@DichenZhang1 Would you be open to a first PR along these lines? If so, please let me know your preferences on either/both of the proposed approaches.