perf(video): convert and scale in one pass in the Video Format block

[wagenet]

Stacked on #726 — this branch is cut from wagenet/macos-convert-mode, so the diff includes that commit. Only the second commit belongs to this PR.

The Video Format block built videoscale -> videoconvert -> capsfilter, so a flow changing both resolution and pixel format walked every frame twice with an intermediate buffer between. videoconvertscale does both in one walk.

autovideoconvert already covers both passes — it is Bin/Colorspace/Scale/Video/Converter and autoplugs a scaler when the caps ask for one (verified with gst-launch-1.0: 1080p RGBA in, 720p I420 negotiated out). So the collapse applies in both convert modes, not just software. The new VideoConvertMode::convert_scale_element_name() picks the element per mode; element_name() is untouched, so the convert-only sites (NDI, videoenc, devicesrc, CPU vision mixer) don't gain a scaler.

Measurements

M2, 4 performance cores, 1080p RGBA, 300 frames, within-pair order alternated. The noise floor here is ±11% on paired runs, and a fixed order has produced sign-flipping "wins" before.

Isolated stage, gst-launch-1.0, 20 pairs: 1.558 s → 0.589 s, +62%, 20/20 pairs, order-symmetric (+62.2% A-first, +62.0% B-first).

Full Strom flow ending in x264enc, fresh backend per measurement, 12 pairs: 2.104 s → 1.292 s, +38% (range 34–41%), 12/12 pairs, order-symmetric (+38.4%, +38.7%).

Format only, scaling passthrough (1080p RGBA → 1080p I420), 20 pairs: median −0.9%, 10/20 pairs. No measurable difference — a passthrough videoscale is free.

Most of that is not pass-merging. A third arm, videoscale n-threads=4 ! videoconvert n-threads=4, splits it: merging the passes is worth ~10% (median +10.5%, 17/20 pairs). The rest is that the scaling half is now threaded — videoscale has the same n-threads property and the same default of 1, but nothing ever set it, and the merged element goes through configure_video_convert().

Scaling method

Both elements share GstVideoScaleMethod and default to 1, "bilinear" (GStreamer 1.28.6), so scaled output is unchanged and no method pin is needed. scaling_method_default_matches_videoscale fails if upstream diverges.

External pads

Saved flows store links as block_id:external_pad_name and resolve them through the block definition at build time. VideoFormat doesn't override get_external_pads(), so it never persists computed_external_pads and nothing stale is baked into saved JSON. The risk is a definition naming an element the builder no longer creates, so the surviving element keeps the ID videoscale and external_pads is unchanged. That matches the convention already in the file: the ID names the role, not the factory, which is why the convert element was called videoconvert while being autovideoconvert.

Verified end to end — a flow linking vfmt:video_in and vfmt:video_out was created and started against the real backend, built videoconvertscale -> capsfilter, played, and reached EOS.

Other videoscale sites

None. videoformat.rs was the only place building one, and thumbnail_tap.rs already uses videoconvertscale. A stale doc comment in thumbnail.rs naming elements that module no longer references is corrected here.

Tests

• builds_one_conversion_element_not_two — two elements, one internal link, and the conversion element both converts and scales.
• one_element_both_scales_and_converts — 1080p RGBA into the block, 1280x720 I420 out.
• conversion_element_is_threaded (macOS) — n-threads reaches the merged element and is above the default of 1.
• external_pads_resolve_to_built_elements — every external pad resolves to an element the builder creates.
• scaling_method_default_matches_videoscale
• gpu::convert_scale_element_name_scales — the mode mapping, plus a guard that autovideoconvert still advertises Scale.

The first three were verified to fail against a temporary revert of build() to the old chain. The last three pass under that revert; they guard a future rename, future upstream drift, and a future mode-mapping mistake rather than this change.

All six use core and gst-plugins-base elements plus autovideoconvert from gst-plugins-bad, all installed in CI, so none skip.

Ran locally: full cargo test (552 lib tests plus all integration tests, including pipeline_lifecycle_test) green, with one pre-existing unrelated ignore (test_jitterbuffer_stalls_without_drop_on_latency); cargo build and cargo clippy --all-targets -- -D warnings clean.

Not run: Linux or Windows. macOS always resolves to Software, so the autovideoconvert branch of convert_scale_element_name() is never exercised here — it rests on the gst-launch check and the klass assertion, not a real GPU flow.

🤖 Generated with Claude Code

[wagenet]

Code looks reasonable.