FL Video Caption Saver

FL_VideoCaptionSaver is the video sibling of FL_ImageCaptionSaver, and it solves the same problem one step up in dimensionality: you've got a sequence of frames sitting in your ComfyUI graph, and you need it saved as an actual video file, sitting next to a matching caption .txt, in the file layout a video LoRA or fine-tuning trainer expects - clip.mp4 + clip.txt.

What it does. Feed it images - your frame sequence as a batch - and it encodes them into a real video file via OpenCV, at fps (1–60, default 24) and your chosen format (mp4 or avi, default mp4). folder_name (default output_videos) and video_name (default video) control where it lands and what it's called; quality (1–10, default 8) maps to the encoder's quality setting; overwrite (default on) decides whether it replaces an existing file at that path. Alongside the video, caption_text (default "Your caption here") gets written to a matching .txt file - same pairing convention as the image version, and same caveat: it's one caption for the whole clip, not per-frame.

The single STRING output (this is an output node, so it prints on the node) confirms what got saved.

One thing the node handles for you under the hood: OpenCV's native color order is BGR, not RGB, and this node does the RGB-to-BGR conversion internally as it writes frames out, so you don't need to think about it - your images go in as normal RGB and come out as a correctly-colored video file.

Installing it is the standard Fill-Nodes routine: search "Fill-Nodes" in ComfyUI Manager, or clone directly -

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

• then restart ComfyUI. It relies on OpenCV, already a core dependency across this pack's image and video nodes, so nothing extra to install beyond the pack itself.

Where people get burned. Format choice is the first real decision: mp4 is the broadly compatible default and the safer bet for feeding into most training pipelines; avi is there if a specific downstream tool wants it, but don't reach for it by default. If your saved video comes out with visibly wrong colors - blues and oranges swapped, skin tones looking off - that's the textbook symptom of an RGB/BGR mixup somewhere in an OpenCV pipeline. This node claims to handle that conversion correctly, so if you're still seeing it, the more likely culprit is an upstream node feeding frames in with an unexpected channel order before they ever reach this one - worth checking earlier in the graph rather than assuming this node is the problem. And keep fps consistent with whatever assumption your training or captioning workflow downstream is making about frame count and clip duration; a mismatch there won't error, it'll just quietly make your saved clip longer or shorter than you expected relative to the source frame count.