fix(inspector): timeline time uses footer time table, not avg fps - #45
Merged
Conversation
The timeline window derived frame time as frame_index / (total_frames / duration_seconds). On captures with recording stalls the average fps is far below the live rate, so displayed times drift by the total stalled time (observed: a frame stamped 13:54 wall clock displayed as ~6:47 on a capture with 643s of stalls at ~29fps live rate). Map frame -> elapsed seconds through the footer ReplayTimeData table instead: created_utc preferred, game_time fallback, walking back to the nearest stamped frame for frames recorded without a value. Files without a time table keep the old linear mapping. Applies to the current-time readout and the strip hover tooltip.
BuildDroppedFrameMap flags every frame whose wall-clock span from the previous stamped frame (footer created_utc, game_time fallback) exceeds 1.5x the expected interval, and estimates the missing frame count per gap. The timeline strip paints flagged frames red, the info panel shows a gap/missing-frame summary plus an editable "Drop FPS" expected rate (default 30), and the hover tooltip reports the gap duration and estimated missing frames. Files without a time table flag nothing.
…tional Each gap from the dropped-frame map is overlaid on the slider track as a red band positioned and sized by wall clock (start_seconds / duration), so band width reads as gap duration - unlike the frame strip, where a two-minute stall spans only a few bars.
The slider axis is now elapsed seconds over the full capture duration: the grab sits at the current frame's footer-table time, and dragging resolves the frame via binary search for the last stamp at or before the grabbed time (zero entries skipped; linear fallback without a table). Equal slider distance now means equal wall-clock time, and the red gap bands align with the grab. Inside a gap the grab resolves to the frame at the gap's start, snapping to it on release.
Captures never sustain their nominal rate, so gap detection now runs at entered_fps * 0.75 (30 -> 22.5 effective). The input label shows the factor and the resulting effective rate.
onur-zenos
force-pushed
the
fix/inspector-timeline-utc
branch
from
July 24, 2026 20:46
8483cab to
c36c349
Compare
onur-zenos
force-pushed
the
fix/inspector-timeline-utc
branch
from
July 27, 2026 10:19
c36c349 to
a7e2cc2
Compare
virtexalejandro
pushed a commit
that referenced
this pull request
Jul 27, 2026
* fix(inspector): timeline time uses footer time table, not avg fps * chore: ignore build-inspector/ * feat(inspector): paint recording gaps red on the timeline strip * feat(inspector): paint recording gaps on the main slider, time-proportional * feat(inspector): main slider scrubs wall-clock time, not frame index * feat(inspector): derate entered Drop FPS by 0.75 for real-world rates
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
2 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.
Problem
The inspector timeline computes frame time as
frame_index / (total_frames / duration_seconds)-- a uniform average-fps mapping. On captures containing recording stalls, average fps is far below the live capture rate, so every displayed time is wrong by up to the total stalled duration.Real case: a 16,556-frame capture with 643 s of stalls (avg 13.6 fps, live rate ~29 fps). A frame stamped 13:54 wall clock displays as ~6:47 on the timeline; scrubbing to 13:54 lands ~3.4 minutes of gameplay away. This breaks any workflow that aligns VTX frames with external video/audio by time.
Fix
TimelineViewService::FrameToElapsedSecondsmaps frame -> elapsed seconds through the footerReplayTimeDatatable:created_utc(data-writer wall clock) preferred,game_timefallbackWired into both timeline consumers: the current-frame
Time:readout and the frame-strip hover tooltip. The total duration and strip layout are untouched.Testing
vtx_inspectorbuilds clean (VS2022 Release) with-DBUILD_VTX_INSPECTOR=ONvtx_cliframeon the capture above: frame 5537 -> 834.3 s (13:54) matches the writer UTC stamp; old code displayed 406.8 s (6:47).clang-format) applied to changed files