ANDRO Video QC

Everything else in the comfyui-vae-float32 pack asks what did our decode do. ANDRO Video QC is the odd one out and the most generally useful of the ten: it asks what did the file someone sent us actually contain - the ingest check a pipeline runs before a plate is accepted. Point it at a clip out of Runway, Seedance or Kling and it reports effective bit depth and which quantisation grid the values sit on, the share outside [0,1] and any NaN, black frames, flashes, flicker, duplicate and held frames, resolution / frame count / fps against what was ordered - and, with source_path set, codec, pixel format and the container's colour tags via ffprobe.

Because half of what it flags is a judgement call, it doesn't just hand you a verdict. It gives you a contact sheet of the flagged frames, each labelled with its number and reason, plus one of PASS / WARN / FAIL and a pass:BOOLEAN you can gate a downstream branch on without reading text.

What it catches that you'd otherwise miss

Two findings from the real clips it was built against, both 24 fps h264, are worth internalising:

WARN: untagged colour (space, transfer, primaries): readers will assume BT.601 / unknown transfer
WARN: 81 held frame(s) = 22.4% of the clip

Untagged colour is the normal state of AI-generated video, and it's the most expensive item on the list - the grade starts from the wrong primaries and nothing errors. And that period-4 held pattern means roughly one frame in four barely moves, so a 24 fps file is carrying about 6 fps of motion: it conforms, it plays, and it judders on the first pan. Both are invisible to a spot-check and obvious once measured.

Inputs that matter

• images - the clip, straight off the loader. Read-only; wire the source on past this node.
• source_path - the file the batch came from. Only with it can ffprobe report what the container claims, which is the half of ingest QC no pixel statistic reaches. Leave empty and everything else still runs.
• expected_fps / expected_frames / expected_width / expected_height - what the shot list says; 0 means don't check. A generator that returns 96 frames for a 4 s 24 fps order has silently changed the edit.
• held_ratio (0.2), flash_jump (0.25), black_level (0.03) - the sensitivity dials. Held is deliberately relative: a frame counts as held when it moves less than a fifth as much as the clip's own median - an absolute threshold would call a locked-off shot a stall and a whip pan clean.
• write_json - also write the report to disk as JSON so batches of clips leave a diffable trail.

Outputs: report (Markdown, readable on canvas and pasteable into a delivery note), json (same data, complete frame lists), sheet (the contact sheet), and pass (true only on PASS - WARN and FAIL are both false, so you can branch on it without parsing text).

One caveat the node prints for itself: a yuv420p file reaches an IMAGE batch through a YUV→RGB matrix, which lands 8-bit values on a much finer grid - both test clips measured ~50–60k levels per channel. When the container states a depth, the container wins; the level count is describing the decode path.

Install

ANDRO Video QC ships in the comfyui-vae-float32 pack. ComfyUI-Manager → search comfyui-vae-float32 → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/AndreiOrehov/comfyui-vae-float32

Restart, find it under ANDRO. Requires ffprobe on your PATH for the container half. If you generate clips for fun and never deliver them to anyone, most of this is overkill - but if you've ever accepted 96 frames of a 4-second order, or graded footage that turned out to be untagged colour, you're the target audience. It's the one node in this VAE-obsessed pack you'll reach for on clips that never touched a VAE at all.