Fix VMAF cadence origin alignment - #47
Merged
Merged
Conversation
Jellman86
marked this pull request as ready for review
July 29, 2026 08:45
Owner
Author
|
Post-merge live verification is complete on Riker using the published A fresh Personal quality session prepared all 12 clips and reached Comparing with monotonic progress and no calibration failures. Reveal measured all three scenes for every preset:
Every output was 12.000–12.039 seconds and the greatest video/audio start separation was 40 ms. The browser media endpoints returned distinct files with preset-specific codecs, containers, sizes, and modification times. The temporary library, session, preview records, synthetic media, and scratch artifacts were then removed; Optimisarr remains healthy. |
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.
What changed
fps(start_time=0)cadence normalisationWhy
Riker live validation exposed a false VMAF result after the clipped-timeline fix: QSV H.264/HEVC samples were correctly cut and had SSIM ≈0.998 against the requested source scene, but VMAF reported ≈32. The same software AV1 scene reported ≈98.8.
FFmpeg documents that
fps(start_time=0)may pad or trim based on the input's existing first PTS. Applying it beforePTS-STARTPTSallowed MP4 and Matroska inputs with different timestamp origins to select adjacent pictures. Rebasing first makes cadence rounding deterministic.Official references:
Evidence
Using the exact completed Riker calibration sample without re-encoding:
This isolates the correction to the scorer: the encoded files are unchanged.
Verification
dotnet build Optimisarr.slnx --no-restore -warnaserror— 0 warnings, 0 errorsdotnet test Optimisarr.slnx --no-build --no-restore— 1,487 passednpm --prefix web run check— clean, including locale/setup checkspython3 scripts/check_docs.py— links and OpenAPI references validgit diff --check— cleanSafety
No database, replacement, retry, exclusion, quality-threshold, or encoder changes. This corrects the shared VMAF measurement timeline only.