Skip to content

fix(vision mixer): a restarted border frame is due on the mixer's next output - #1038

Merged
srperens merged 2 commits into
mainfrom
fix/underlay-border-stamp
Oct 7, 2026
Merged

srperens merged 2 commits into
mainfrom
fix/underlay-border-stamp

Conversation

@srperens

@srperens srperens commented Oct 7, 2026

Copy link
Copy Markdown
Collaborator

Problem

vision_mixer_underlay_upload_test::static_underlays_are_not_reuploaded_gpu fails now and then on the macOS runner: the configured border is missing from the cut frame: (0, 0, 255). Seen on #1029's CI after its rebase, and in 1 of 5 runs from a diagnostic branch earlier today.

In production, on a host where the vision mixer renders below real time, a border configured while the mixer is behind shows up late, after the take that should reveal it.

A border colour change, or a border starting to hold, restarts its underlay source, and the restart stamped the new frame with the clock's running time. A mixer that renders slower than real time falls further behind the clock every second (the GL mixer on the runner manages about 20 fps of a 30 fps flow). The frame then lies in the mixer's future and is not shown until the mixer gets there.

Change

gst::underlay::frame_time stamps the restarted frame at the compositor's output position (query_position on the aggregator the source feeds) plus 50 ms. The margin keeps it after the held frame, which a held pad would otherwise drop as from the past. The stamp is never later than the clock's running time, which is the old stamp and is where a mixer that keeps up already is. A held pad (repeat-after-eos) keeps a frame stamped in its past, so the frame is shown on the next output frame.

Evidence

  • New guard borders_keep_up_with_a_mixer_behind_the_clock_gpu: the same flow with the PGM mixer held 60 ms per output frame (test-only BUFFER probe), so it falls behind the clock as on the runner. With the old stamp it fails with the CI signature, the configured border is missing from the cut frame: (0, 0, 255), and did so 2 of 2 times before the fix. With the fix it passes, and the colour change shows after 2 PGM frames (122 ms).
  • The existing GPU and CPU variants pass unchanged.

Tests

Ran (macOS, GStreamer 1.28.6, GL): STROM_REQUIRE_GL=1 cargo test --test vision_mixer_underlay_upload_test (3 passed), cargo test --lib underlay (2), vision_mixer_cpu_test, vision_mixer_overlay_upload_test, vision_mixer_source_resize_test, pipeline_lifecycle_test: all passed. cargo clippy --all-targets -D warnings clean.
Not run: Linux and Windows (CI). This PR carries ci:macos.

For the reviewer

  • The new test adds about 8 s to vision_mixer_underlay_upload_test.

🤖 Generated with Claude Code

…t output

A border colour change restarts its underlay source, which stamped the
frame with the clock's running time. A mixer rendering below real time
falls further behind the clock every second, so the frame lay in its
future: a border configured while it was behind was missing from the cut
frame that revealed it (GPU underlay test on the macOS runner: 'the
configured border is missing from the cut frame: (0, 0, 255)').

Stamp it at the compositor's output position plus one frame of margin,
never later than the clock's running time.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@srperens srperens added the ci:macos Run Build (macOS) on this pull request label Oct 7, 2026
…d mixer

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@srperens
srperens merged commit 9161b34 into main Oct 7, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:macos Run Build (macOS) on this pull request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant