perf(video): thread the scaling step in the Video Format block

[wagenet]

The Video Format block builds videoscale -> videoconvert -> capsfilter. configure_video_convert() raises n-threads on the videoconvert, but videoscale has the same property with the same default of 1 and nothing set it, so a resize to or from 4K ran on one core. The block now passes videoscale through the same helper.

Like the existing conversion threading, this is macOS-only: elsewhere the helper is a no-op and the block is unchanged.

Measurements

M4 Max (12 performance cores), gst-launch-1.0 with n-threads pinned to 4, 150 frames, 6 order-alternated pairs, videoscale ! videoconvert n-threads=4 against videoscale n-threads=4 ! videoconvert n-threads=4. Wall time includes the test source.

Shape	Before	After	Total CPU
RGBA 1080p → I420 720p	0.74 s	0.36 s	within 1%
UYVY 4K → I420 1080p	2.23 s	1.36 s	+4%
I420 720p → UYVY 4K	1.49 s	0.53 s	within 2%

6/6 pairs in every shape. On this machine the block itself uses video_convert_threads() = 12. Each resizing block adds that many threads; the CPU cost of many such blocks competing on a Mac with fewer cores was not measured.

For progressive video the output is byte-identical to the unthreaded chain. That covers the shapes above, I420 1080p → RGBA 720p, and every resolution in the block's dropdown from 1080p, 720p, 576p and 480p sources in I420, UYVY and NV12. The exception is SD upscaled to 4K, where chroma moves by 1–2 levels. 10-bit packed v210 output differs byte-wise; whether that reaches pixel values was not checked. Interlaced input can differ on the rows where one thread's stripe meets the next.

A single videoconvertscale doing both steps was also measured. It is ~5% faster than this on the first shape, but 1.1–2x slower on the other two. Single-threaded, as on Linux, it costs up to 2.5x the CPU of the two-element chain. It also changes output at sharp chroma edges.

Tests

scale_and_convert_are_threaded (macOS) builds the block and checks that every element with n-threads got video_convert_threads(). It fails with configure_video_convert did not reach 'vf0:videoscale' when the new call is removed.

The test is macOS-only, because the thread count is only raised there. The macOS CI job does not run on PRs without the ci:macos label, so it was run on the fork at this head, where the test passed: https://github.com/wagenet/strom/actions/runs/36247628073.

Ran locally on macOS at this head: the 11 videoformat and gpu lib tests, cargo fmt --all --check, and cargo clippy --workspace --all-targets -D warnings. The full suite runs in the Linux CI job, where the change compiles to nothing. Windows was not built.

Also corrects a doc comment in thumbnail.rs that names elements the module no longer uses.

🤖 Generated with Claude Code

[wagenet]

Code looks reasonable.

[srperens]

Noted as a draft, so I am holding off on a full review until it is marked ready for
review. If you want one before then, say so here or request me as a reviewer.

[wagenet]

@srperens it could be reviewed now, but it can't be merged until the PR it is stacked upon is merged.

[srperens]

Verified locally on macOS: scale_and_convert_are_threaded passes at this head and fails with configure_video_convert did not reach 'vf0:videoscale' when the new call is removed. Change is macOS-only and a no-op elsewhere. Thanks!