Skip to content

Use faster AOM encoding for the AVIF realtime preset - #489

Open
gregbenz wants to merge 3 commits into
google:mainfrom
gregbenz:codex/avif-realtime-aom-speed
Open

gregbenz wants to merge 3 commits into
google:mainfrom
gregbenz:codex/avif-realtime-aom-speed

Conversation

@gregbenz

Copy link
Copy Markdown
Contributor

The AVIF realtime preset currently speeds up gain-map generation but leaves AOM at its default encoding speed. This change sets AOM speed to 8 for both the base image and gain map when the caller selects UHDR_USAGE_REALTIME.

Default and best-quality encoding keep their existing behavior. The change also preserves libheif's choice of encoder: it only sets the speed when the selected encoder is AOM. An unsupported speed parameter falls back to the encoder's default; other errors are returned to the caller.

The HDR-only API internally switches to realtime gain-map generation even for best-quality requests. This patch retains the caller's original preset so that internal switch does not accidentally enable faster AOM encoding.

Performance and quality

On an M5 Max with patched libheif 1.19.7 and AOM 3.14.1, speed 8 reduced median request time by 64%, with files about 9% larger. The comparison used 11 images at base/gain-map quality 95/95 and gain-map scale 1, with the same decoded inputs for each encoder speed.

Median change from the default AOM speed 6 Speed 7 Speed 8
Input decode + AVIF encode time -37.1% -63.6%
Process CPU time -34.8% -72.2%
File size +3.0% +9.4%
SDR PSNR -0.40 dB -0.95 dB
HDR log-domain RMSE +0.5% +3.4%

Speed 8 offers a larger time saving than speed 7, at the cost of larger files and some quality loss. File growth ranged from 1.3% to 15.2% in this set. Quality was measured against the decoded source Ultra HDR JPEG; the HDR error metric is not a perceptual score.

A four-image subset tested at quality 90/85 and gain-map scales 1, 2 and 4 brought the total to 23 conditions. Across those conditions, request time fell by 42.5% to 74.8%. Decode time was usually lower, but increased by up to 11.8%, so faster encoding does not guarantee faster decoding. Timings used balanced 6/7/8/8/7/6 ordering, with one warmup and three measured iterations per encoding process.

Native x86 performance and native HDR-display inspection were not available. SDR and tone-mapped HDR crop comparisons showed some texture and gradient differences, without gross artifacts in the inspected crops.

Validation

  • The full local suite passed: 1,103 tests, with 229 environment or existing skips. The final API suite, including the added regression, passed 15 tests with five HEVC skips. The new HDR-only regression fails against the original library and passes with this change.
  • The no-HEIF build and its seven API tests pass. Nine focused tests pass under ASan/UBSan; dependencies were not instrumented and leak detection was disabled on macOS.
  • Direct checks confirm speed 8 for both images in realtime mode and unchanged settings for default/BEST requests. Eighteen default/BEST controls produce identical output bytes. A build using rav1e also preserves output bytes and decodes successfully.
  • Injected errors verify the unsupported-parameter fallback and cleanup for other failures. All 69 quality comparisons were independently recalculated.

A separate encoder-speed setting could be considered later for callers who want faster compression alongside best-quality gain-map generation. This change uses the existing realtime preset and adds no public API.

Related: #482

Retain the AVIF realtime AOM policy tests on current main while preserving upstream routing coverage. The focused sanitizer run passes the policy, API-0 caller-preset, and routing tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant