Yanhuo 视频文件加载 (成片→VIDEO)

Here's the shape of a long-form video job: you spend forty minutes and however many gigabytes of VRAM rendering a chain, Final Decode writes chain_00001_.mp4 to disk, and now you want to do something with it. Upscale it. Interpolate it to 30fps. Transcode it. Hand it to a tool that takes a file path and nothing else. The video is right there in your output folder and there's no wire into your graph.

This node is that wire. Point it at the file, get a VIDEO you can plug into the downstream half of your workflow.

How it works

Two things happen here.

First, path resolution. You give it a string; it tries the path as-is, then - if your string doesn't already end in .mp4, .mkv or .webm - it also tries output/<your string>.mp4 and output/<your string>.mkv, and finally output/<your string>. First hit wins, and the node hands back the absolute path as a second output. That's why yanhuo/chain_00001_.mp4 works as well as D:/comfy/ComfyUI/output/yanhuo/chain_00001_.mp4, and why you can drop the extension if you're lazy.

Second, it wraps the result in the Extender's path-backed VIDEO object. It does not decode to a tensor batch and re-encode - no copy of your 1080p frames sitting in RAM. The wrapper stays lazy and downstream nodes that need pixels will ask for them. That matters more than it sounds: a 20-second 24fps clip is ~480 frames, and a naive "load to IMAGE" round trip is exactly how you turn a working workflow into an out-of-memory error.

The ports that matter

• video_path (STRING, required, defaults to empty) - absolute, or relative to the ComfyUI output directory. Usually the mp4/mkv your Final Decode wrote.
• 视频 (VIDEO) - the thing you wire onward: a video upscaler, an interpolator, a transcode, a SaveVideo.
• 文件路径 (STRING) - the resolved absolute path. Quietly the more useful output half the time, because plenty of nodes want a filename as a string rather than a VIDEO.

The node also validates itself before the queue runs. Empty string or a path that doesn't exist gets you a plain error at queue time instead of a half-finished render, which is the correct place for that failure and rarer than it should be in custom nodes.

Installing it

It's a companion node in the SelfLift pack, so you install the whole pack. No pip dependencies of its own, but the pack registers nothing useful without its two sibling packs in custom_nodes/:

cd ComfyUI/custom_nodes
git clone https://github.com/yanhuoxunxianren/yanhuo_H3_Motion-Context_SelfLift.git
# plus the two siblings it imports, under exactly these folder names:
#   ComfyUI_MiniMax_H3_Extender/   and   comfyui-SelfLift/

Restart, or grab it through ComfyUI Manager by searching the pack title. Worth knowing what you're installing: comfyui-SelfLift ships no license, the H3 weights themselves are a big separate download, and the MiniMax H3 Community License doesn't license local-weights use in the US, EU, UK or Korea. The pack's own code is MIT.

And yes, the folder names are load-bearing: the pack resolves its siblings by directory name under custom_nodes/.

Traps worth knowing

The file has to exist when you queue, not when you render. Which is fine until you do the natural thing - run the chain and the loader in one queue. Have Final Decode write the file first, run it, then load. Or point video_path at a file you already have; it doesn't care where it came from, it just has to be a real file on disk.

It leans on the sibling Extender at run time. The path→VIDEO wrapper the loader calls into lives in the Extender's disk module. If that module is missing, this node still shows up in the menu but errors when it runs, and the README's claim that only the Final Decode bridge depends on it is optimistic. Nothing breaks that you can't fix by installing the Extender properly, but don't be surprised by a node that appears and then refuses.

Extension inference cuts both ways. Giving it myclip and getting myclip.mp4 is convenient right up until you have myclip.mkv and myclip.mp4 sitting next to each other.

Why you'd bother

Because the chain output is the start of the pipeline, not the end. Video upscaling is its own two-model argument - FlashVSR when the source is already decent and you want speed, SeedVR2 when you're restoring genuinely low-resolution footage - and both want a video in and a video out, with RIFE interpolation as the usual companion rather than a substitute. Per-frame image upscalers are the trap here: run a good image model over 480 frames and fine repeating texture starts crawling, because nothing in it knows frame 2 comes after frame 1. Whatever you chain after this loader needs temporal awareness.

Worth saying plainly: this pack has almost no community footprint yet - a few launch-week H3 threads, nothing about chaining it in ComfyUI. The README and the pack's own test suite are your documentation.