Repository navigation
Conversation
The encoded stream starts at its first frame, and get_frame_at maps a wall-clock time to video time by subtracting video_start_time, which was the moment the writer opened. macOS ScreenCaptureKit only delivers a frame when the screen changes, so the first frame can arrive many seconds later, and every frame lookup then landed past the end of the video.
abrichr
added
the
review-needed
This branch has not been deployed
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.
Anchors a recording's
video_start_timeto the timestamp of its first encoded frame instead of the moment the video writer opened.Why: the encoded stream starts at its first frame, and
CaptureSession.get_frame_atturns a wall-clock time into video time by subtractingvideo_start_time. macOS ScreenCaptureKit only delivers a frame when the screen changes, so on a static screen the first frame can arrive many seconds after the writer opens. Every lookup was then shifted by that delay and could land past the end of the video. I hit this on a macOS 15 VM recording: the first frame arrived about 15 s late, the video was 1.54 s long, and compiling failed with "no captured frame available for click at t=15.682s".Change: in
write_video_event, when the first frame is written (nolast_frameyet), store its timestamp as the video start time viacrud.update_video_start_time.Testing:
packages/capture/tests/test_video_start_anchor.py(2 tests). One checks that the first frame updates the stored start time. The other encodes real frames with ffmpeg at writer-open + 15 s and + 16 s, then checks that each frame is found again at its own wall-clock time. Both pass with the change and both fail on base main.uv run --python 3.12 pytest packages/capture/tests): 1058 passed, 34 skipped, 21 failed, 17 errors. The same 21 failures and 17 errors occur on base main. They are all in the audio, browser-bridge, narration and shadow test modules, which need optional extras that are not installed here.Untested: I have not yet replayed a full recording end to end on the VM with this change, because a separate window-scoped input problem stops that run first. I have not tested Windows or Linux capture backends, though the change only touches the shared writer path.