fix(flow): mark cefsrc DSK inputs as premultiplied alpha

[wagenet]

Written by Claude (AI). Not yet reviewed by a human.

Depends on Eyevinn/strom#809. Do not merge before it lands.

Summary

cefsrc paints premultiplied alpha. Both vision mixer backends blend straight alpha, so every HTML graphic on a DSK input composites too dark wherever it is partly transparent: 50% white over grey 64 reads 96 instead of 160. Eyevinn/strom#809 adds a per-DSK block property, dsk_N_alpha_mode (straight by default, or premultiplied), read when the flow is built. Set it to premultiplied for every DSK input fed by a graphic assignment; leave DSK inputs with no graphic unset.

Changes

• src/lib/flow-generator.ts: the graphic-assignment loop records each DSK index it wires a cefsrc into. The block that sets num_dsk_inputs then sets dsk_N_alpha_mode for those indexes. An assignment whose graphic doc no longer exists builds no cefsrc, so its input is left unset (it still counts toward num_dsk_inputs).
• The builtin.videoformat block in front of each DSK input stays. It resizes the graphic to program resolution before the mixer converts it; without it the CPU mixer puts a dark edge on graphics when program is not 1080p (Vision mixer: dark edges on resized premultiplied DSK inputs (CPU mixer) strom#822).
• cefsrc's unpremultiply (cefsrc: Add unpremultiply property centricular/gstcefsrc#113) is not set. With the mixer also set to premultiplied, the graphic would be converted twice and composite too bright.
• docs/strom-block-config.md: documents the property.

Paths that wire cefsrc into the mixer

Path	Needs the property?
Graphic assignments in flow-generator.ts	Yes, covered. This is the only path that feeds a DSK pad in a generated flow.
Template-stripping pass in flow-generator.ts	No. It removes any template cefsrc or Video Format block wired to dsk_in_N before graphic assignments are built, so no template DSK graphic reaches Strom.
src/lib/default-flow.ts	No. The template has no cefsrc and no DSK links.
src/db/optional-overlays.ts	No. OPTIONAL_OVERLAYS is not imported anywhere, so no flow is built from it. If it is ever wired in, its two DSK entries need the property too.
HTML sources (streamType: 'html') in flow-generator.ts	Not covered. These wire cefsrc → cefdemux into video_in_N, not a DSK pad, and #809 only adds the property for DSK inputs.

Compatibility with Strom without #809

Checked on Eyevinn/strom main at 9b7bc1f. An undefined block property is stored and ignored at flow creation, not rejected: harmless on an older Strom, and no effect there. No gating is needed; until #809 is deployed, graphics stay too dark.

Code citations

• types/src/block.rs:268: BlockInstance.properties is a HashMap<String, PropertyValue>, and PropertyValue is an untagged enum that accepts any string (types/src/element.rs:146-153).
• backend/src/api/flows.rs:305-468 (prepare_flow, called from create_flow at :489): trims endpoint ids, migrates WHEP mode, computes pads and resolves links. It does not check property names.
• backend/src/state.rs:398-414 (strip_transient_properties, run on create and update): removes only properties the definition marks persist: false. Unknown keys are kept and persisted with the flow.
• backend/src/gst/block_expansion.rs:105-121: the builder receives the full property map. The vision mixer builder reads properties by name through vision_mixer/properties.rs, so it never looks at dsk_N_alpha_mode.
• The only place that rejects an unknown name is the live PATCH /api/flows/{id}/blocks/{bid}/properties (backend/src/state.rs:1774-1781, "unknown exposed property"). Open Live sets this property only in the create body and never PATCHes the vision mixer's block properties (the updateBlockProperties calls in src/ws/controller.ts all target the audio mixer).

Test plan

• src/__tests__/flow-generator.test.ts: new tests check that the property is set for each assigned DSK input, absent for an input with no graphic, absent for an assignment whose graphic doc is missing, and absent when there are no graphics. With the property assignment removed, three of the four new tests fail.
• pnpm exec vitest run: 69 files, 752 tests pass
• pnpm typecheck passes
• pnpm build passes
• Not verified on air. No flow was run against a Strom with #809. #809's own on-air checks cover the mixer side with a real cefsrc DSK graphic.

🤖 Generated with Claude Code

[birme]

Holding off on automated review/merge here: this is a draft, gated on upstream Eyevinn/strom#809 (the dsk_N_alpha_mode block property this PR sets does not exist until that lands), and the author has marked it "do not merge before it lands / not yet reviewed by a human." Not part of a multi-PR open-live stack — the dependency is upstream. Nothing further is needed from the author; this comment records the hold on the PR so later automated runs don't re-discover it from scratch.