FL_ScanAnalysisCollect

The smallest node in this pack, and a neat solution to a real graph-design problem. If you're running per-shot analysis on a multi-shot video, you end up with a list of FL_SCAN_ANALYSIS objects - one per shot - that all need to arrive at FL Interactive Scan FX in chronological order. Individually wiring five of them means five cables into an autogrow input, and a graph that's a nightmare to keep in order.

FL Scan Analysis Collect takes that list and folds it into one object. Output is still a single FL_SCAN_ANALYSIS, just with the shots nested inside in the order they arrived. One cable into the effect node instead of however many shots you have.

That's the whole node. One input - analysis - and one output of the same type. No parameters, no settings, nothing to tune, which is exactly right for a packaging step.

How it works under the hood

It's a list-input node: the framework hands it every value that arrived on that socket, in execution order, and it wraps the lot into a shots key. Downstream, the effect node opens the object, sees a shots list, and extends its working set with those in order. A bare single-shot analysis still works - the effect node checks for the shots key and falls back to treating the object as one shot - which is why the same downstream node accepts either shape.

The upshot is that the ordering isn't cosmetic. The Scan FX node concatenates the shots' frame counts and compares the total against the actual video length, with a genuinely good error if they disagree: it prints how many frames the video has, how many the analysis covers, and each shot's length. If your collection is out of order, you get a mismatch rather than a subtly wrong render, which is the failure mode you want.

Install

Standard:

cd ComfyUI/custom_nodes
git clone https://github.com/filliptm/ComfyUI_Fill-Nodes

Restart ComfyUI. No models, no extra dependencies. The pack's install is long overall - it pulls in OpenGL, audio, PDF and API libraries - but none of that is load-bearing here.

Where people get burned

Ordering. The one real trap. The node preserves the order values arrive in, and for a per-shot pipeline that means the order your upstream shot-splitting nodes execute. If you build sections by hand rather than from a schedule, keep the sockets in chronological order and don't assume the numbers in the socket names are doing anything.

Length mismatches. If your analysis covers fewer frames than the video - usually because the last section got truncated, or a shot was analysed twice and one copy was dropped - you'll get the frame-count error from the effect node. That's your cue to look at the shot splitting, not at the collect node.

Not needing it at all. For a single-shot video, skip it. One Scan Analysis node straight into the effect node is fine, and a wrapper around one item just adds a node to your graph for nothing.

It's a two-socket utility node, and the reason it deserves a page is that it's the difference between a graph you can read and a graph where six near-identical cables converge on one input in an order you have to remember.