Repository navigation
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
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
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