H3 Video File (path -> VHS filenames)
The adapter that lets Image Saver tag a LongTake mp4
- filenames
- width
- height
What it is
The most boring node in the pack, and the one that unblocks a whole branch of your graph. H3 Video File takes one string - the path of a video that already exists - and returns three things: filenames typed as VHS_FILENAMES, plus width and height as integers.
You need it because of how LongTake finishes. The pack doesn't save your video through Save Video; the Stitch concatenates the chunks on disk and writes the mp4 itself, then hands you its path as a plain string. Image Saver's Image Saver Video Metadata node, though, expects the VHS_FILENAMES type - the little "yes, something was saved, here's the path" tuple that VideoHelperSuite's Save Video emits. Nothing in a LongTake graph produces one. This node is the two-line bridge.
How it works
path is declared as a forceInput string, so it's a socket, not a text field - you wire the Stitch's path into it (a string primitive works fine if you're testing by hand). The node then:
- strips whitespace and bails out with an
ExecutionBlockeron an empty path; - refuses anything that isn't a
.mp4on disk, or that doesn't exist, withNo mp4 video to tag: '...'; - opens the file with PyAV and reads the first video stream's width and height;
- returns
(True, [path])as the filenames value, which is the exact shape Save Video uses.
Two details in there are the sort of thing that saves you an hour. The empty-path case is deliberate: if the Stitch is in dry_run (or muted), path is blank, and instead of throwing, the node blocks its three outputs so the metadata branch simply stops. Your queue completes, you get no file, nothing red. And the width/height are read from the encoded stream, not from the megapixel widget you typed into the Render - so the metadata describes the video you actually have, after the last pass, rather than the canvas you planned.
Wiring it
Stitch path → H3 Video File path; filenames → Image Saver's video metadata input; width and height → its resolution fields. That's it - there's nothing to tune and no output that goes back into the render.
Pair it with H3 LoRA Tags: that one supplies the <lora:...> resource tags and base model name from the graph, this one supplies the video and its resolution, and one Image Saver metadata node writes the Civitai-ready sidecar for the finished take.
The one dependency-ish caveat: VHS_FILENAMES is a custom type owned by VideoHelperSuite - the pack that Image Saver's metadata branch expects anyway. If you don't have Image Saver or VHS installed there's nothing to plug the output into, and the socket will refuse a connection to a plain STRING.
Install
Same pack, same install as the rest of LongTake. ComfyUI Manager → search H3 LongTake → Install, or:
cd ComfyUI/custom_nodes
git clone https://github.com/mark9009/ComfyUI-H3-LongTake
Restart ComfyUI. Nothing extra to pip install: the pack declares no Python dependencies, and the mp4 header is read with the av bindings ComfyUI already ships. Don't be thrown by the pack README's ffmpeg section either - that's about the Render decoding your source video and the Stitch concatenating chunks, not about this node.
Gotchas
A missing or non-mp4 path is a hard error. Retagging a file you moved or renamed raises rather than failing quietly, which is annoying once and then you'll be glad it did.
Point it at the final video, not a chunk. The Stitch's path is the assembled take; clip_000.mp4 inside the project folder is one 5-second chunk at the render canvas. Tag the thing you're actually uploading.
Filenames is a list, not a path. It carries [path] - VideoHelperSuite's convention, so a consumer knows to look at the first entry. If you need the path elsewhere as a string, take it from the Stitch's own path output instead of trying to unwrap this one.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| path | STRING | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| filenames | VHS_FILENAMES | — |
| width | INT | — |
| height | INT | — |