fix: SG-42144: Fix off-by-one frame count error for audio-only files#1068
Merged
cedrik-fuoco-adsk merged 8 commits intoAcademySoftwareFoundation:mainfrom Feb 24, 2026
Merged
Conversation
skyhhh666
requested review from
bernie-laberge,
cedrik-fuoco-adsk and
eloisebrosseau
as code owners
|
|
Signed-off-by: skythj <214037181@qq.com>
skyhhh666
force-pushed
the
fix/audio-frame-rounding
branch
from
1d25d04 to
296c87c
Compare
pbergeron-adsk
approved these changes
Jan 19, 2026
Contributor
Author
|
Hi @bernie-laberge @eloisebrosseau @cedrik-fuoco-adsk , just a gentle ping. Could you please take a look when you have a chance? Thanks! |
bernie-laberge
approved these changes
Jan 22, 2026
Contributor
bernie-laberge
left a comment
bernie-laberge
left a comment
There was a problem hiding this comment.
Thanks for the fix @skyhhh666 !
cedrik-fuoco-adsk
approved these changes
Jan 22, 2026
eloisebrosseau
approved these changes
Jan 22, 2026
cedrik-fuoco-adsk
changed the title
cedrik-fuoco-adsk
changed the title
cedrik-fuoco-adsk
merged commit c4e0e15
into
AcademySoftwareFoundation:main
19 checks passed
This was referenced Feb 23, 2026
This was referenced Feb 26, 2026
chenlj1
pushed a commit
to chenlj1/OpenRV
that referenced
this pull request
Mar 6, 2026
…cademySoftwareFoundation#1068) # PR Description: Fix off-by-one frame count error for audio-only files ## Summary This PR fixes a bug where pure audio files (like `.wav`) could be misidentified as having one frame less than their actual duration. This was caused by floating-point truncation when converting the audio duration (in seconds) to a frame count. ## The Issue When OpenRV calculates the frame count for an audio file, it multiplies the duration reported by FFmpeg by the target FPS. For example: - An audio file with 28,000 samples at 48kHz is exactly 14 frames at 24fps. - Because of microsecond precision in FFmpeg's duration reporting, the `timeDuration` might be `0.583333`. - `0.583333 * 24 = 13.999992`. - Assigning this to an integer `frames` variable resulted in `13` due to truncation. ## The Fix Changed the calculation to use `std::round()` on the result before assigning it to the integer `frames` variable. This ensures that tiny precision errors don't cause the loss of the final frame. ## Affected File - `src/lib/image/MovieFFMpeg/MovieFFMpeg.cpp` ## Verification Results - Manual calculation: `std::round(13.999992)` now correctly yields `14`. - This matches the behavior of other industry tools like Maya and Nuke. Signed-off-by: skythj <214037181@qq.com>
eloisebrosseau
pushed a commit
to eloisebrosseau/OpenRV
that referenced
this pull request
Apr 1, 2026
…cademySoftwareFoundation#1068) # PR Description: Fix off-by-one frame count error for audio-only files ## Summary This PR fixes a bug where pure audio files (like `.wav`) could be misidentified as having one frame less than their actual duration. This was caused by floating-point truncation when converting the audio duration (in seconds) to a frame count. ## The Issue When OpenRV calculates the frame count for an audio file, it multiplies the duration reported by FFmpeg by the target FPS. For example: - An audio file with 28,000 samples at 48kHz is exactly 14 frames at 24fps. - Because of microsecond precision in FFmpeg's duration reporting, the `timeDuration` might be `0.583333`. - `0.583333 * 24 = 13.999992`. - Assigning this to an integer `frames` variable resulted in `13` due to truncation. ## The Fix Changed the calculation to use `std::round()` on the result before assigning it to the integer `frames` variable. This ensures that tiny precision errors don't cause the loss of the final frame. ## Affected File - `src/lib/image/MovieFFMpeg/MovieFFMpeg.cpp` ## Verification Results - Manual calculation: `std::round(13.999992)` now correctly yields `14`. - This matches the behavior of other industry tools like Maya and Nuke. Signed-off-by: skythj <214037181@qq.com>
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
5 participants
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.
PR Description: Fix off-by-one frame count error for audio-only files
Summary
This PR fixes a bug where pure audio files (like
.wav) could be misidentified as having one frame less than their actual duration. This was caused by floating-point truncation when converting the audio duration (in seconds) to a frame count.The Issue
When OpenRV calculates the frame count for an audio file, it multiplies the duration reported by FFmpeg by the target FPS.
For example:
timeDurationmight be0.583333.0.583333 * 24 = 13.999992.framesvariable resulted in13due to truncation.The Fix
Changed the calculation to use
std::round()on the result before assigning it to the integerframesvariable. This ensures that tiny precision errors don't cause the loss of the final frame.Affected File
src/lib/image/MovieFFMpeg/MovieFFMpeg.cppVerification Results
std::round(13.999992)now correctly yields14.