TTPlanet_FramePack

You've got a photo, you want it to move toward a second photo, and suddenly you're assembling a seven-node image-to-video graph. TTPlanet_FramePack is the opposite: a single output node - feed it a start image, an optional end image, and a prompt, and it hands you back a finished video. No chains, no conditioning stack, no second model to wire up. It's a ComfyUI front end for lllyasviel's FramePack, which builds on Hunyuan Video and trades some polish for the ability to generate minute-scale clips on consumer hardware instead of the minutes-per-clip grind of Wan or the rougher, faster drafts of LTX.

The "SE" in the pack name is the whole story: start-and-end. The original FramePack was famously criticized for the "frozen background" problem - the camera parks and the subject jitters in place. This fork injects an end_image so your clip can land on a specific frame, and the author tweaked the pipeline to smooth the transition. If you want a shot that starts in one room and ends in another, this is the niche the node exists for.

How it works

Under the hood this thing is a small movie studio. On load it pulls four weight sets straight from your models/ folder: the HunyuanVideo text encoders and VAE, a SigLIP image encoder (the one Flux Redux uses), and the FramePackI2V_HY transformer - a modified Hunyuan transformer fine-tuned for image-to-video. Your start image gets VAE-encoded into a latent, and if you connected end_image, its features get blended into the start conditioning based on end_condition_strength.

Generation runs in "latent sections": the model generates a sliding window of frames, carries the history forward, and stitches each new section onto the old one with a soft blend across overlap_frames (33 by default; pick linear, cosine, or sigmoid for the blend curve). Because sections get reassembled rather than decoded once, you can stretch to 120 seconds without one giant OOM wall. When it's done, the node writes an mp4 to your output folder (randomly named - sorry) and returns frames, a standard IMAGE batch, plus fps.

The inputs that matter

• ref_image and prompt - the required pair. The prompt matters more than you'd think; this stack punishes vague text.
• end_image (optional) - the whole point of this fork. Leave it unplugged and you've got regular start-only FramePack.
• total_second_length - 5 by default, up to 120. Every extra second costs real GPU time.
• resolution - 360p to 720p, default 480p. Long clips on modest VRAM start here.
• steps, seed, use_teacache - TeaCache skips redundant steps and is on by default; flip it off if motion gets weird.

The rest are tuning dials. padding_mode is "still experimental - use optimized" per the README, so leave it. On the end-frame controls the author says treat end_condition_strength and enable_feature_fusion as mutually exclusive - pick one; lower strength means more freedom but weaker end similarity. history_weight / history_decay / history_weight_min control how much the model leans on what it already drew - crank the decay for more variation. And gpu_memory_preservation is your OOM valve: higher reserves more VRAM but slows you down.

Install: easy, then the models

Install is the easy half:

cd ComfyUI/custom_nodes
git clone https://github.com/TTPlanetPig/TTP_Comfyui_FramePack_SE
# restart ComfyUI (or install via ComfyUI Manager - search "TTP_Comfyui_FramePack_SE")

The pack depends on diffusers, transformers, accelerate, scipy, torchsde, einops, and safetensors - ComfyUI Manager pulls them for you. The real work is the weights. The node expects three diffusers-format folders sitting directly inside models/ (not in checkpoints or vae), downloaded as folders from Hugging Face:

models/
├── HunyuanVideo/        # hunyuanvideo-community/HunyuanVideo
├── flux_redux_bfl/      # lllyasviel/flux_redux_bfl  (SigLIP encoder)
└── FramePackI2V_HY/     # lllyasviel/FramePackI2V_HY  (the I2V transformer)

That's a serious download - the transformer alone ships as three safetensors shards, plus the full Hunyuan text encoders and VAE; budget for tens of GB on disk.

Where people get burned

• Start and end too different. The README is blunt about it: when the two frames diverge too much, the model "struggles and often produces slideshow-style cuts." Keep the composition and lighting close, and lower end_condition_strength when you need more freedom.
• VRAM. This is a 13B Hunyuan transformer; the node offloads aggressively (its own swap-in-swap-out scheme) but 480p × 10+ seconds on an 8GB card will crawl. Drop to 360p or shorten the clip before you blame the node.
• First run is brutal. It loads and warms every model in __init__, so the very first run feels hung. Let it cook.
• It's a niche, and it knows it. FramePack's popularity peaked in mid-2025 and has thinned out since - Wan became the local-video default and LTX took the speed tier. Hunyuan also inherits Tencent's community license, whose territory clause excludes the EU, UK, and South Korea. If you want start-and-end controlled long clips on the Hunyuan stack, this is one of the few one-box ways to get them; if you just want any good I2V, the ecosystem has moved on.

Honestly? For its specific job - two pinned frames, one smooth video, zero graph-building - it's the fastest path in ComfyUI that exists today.