Feature Bank Attention Processor

Feature Bank Attention Processor is the most academically serious node in the Livepeer Stream Pack, and the one that needs the most honest framing. It's a direct ComfyUI port of the feature-bank attention mechanism from the StreamV2V paper (Liang et al., "Looking Backward: Streaming Video-to-Video Translation with Feature Banks") - the technique that makes streaming video-to-video stop flickering. If you've run a V2V pipeline and watched the background texture shimmer between frames, that flicker is the problem this node attacks: each frame is generated independently, so nothing forces it to remember what the last frame drew. The feature bank is that memory.

It's a model patch, not a standalone generator. You hang it between your model loader and your sampler: give it a MODEL, it hands back a patched clone with attention hooks installed, and you feed that to the KSampler. The category path in the pack (StreamPack/model_patches/unet) tells you where it belongs in the graph.

How it works

Read the source and the mechanism is genuinely elegant. It registers forward hooks on the UNet's attention modules, and from then on every attention pass consults a small rolling cache - the keys, values, and outputs of the last feature_bank_max_frames frames (stored every feature_cache_interval frames, self-attention only). For the current frame it runs a cosine-similarity search: each query's features get matched against the cached ones, and if the nearest cached feature clears the feature_similarity_threshold, the model borrows it instead of hallucinating the frame from scratch. feature_injection_strength then controls how much of that borrowed past leaks into the present. Net effect: frame N+1 is drawn with an explicit memory of frame N, so it keeps drawing the same thing instead of re-inventing it.

The inputs that matter

• model - the MODEL to patch. Wire from your checkpoint/UNET loader.
• feature_injection_strength (default 0.8) - how hard the cached features pull on the current frame. Too high and frames get stuck/stale; too low and the flicker comes back. 0.8 is a reasonable starting point.
• feature_similarity_threshold (default 0.98) - how similar a cached feature must be before it gets substituted. Near 1.0 means "only borrow when it's a great match," which is the safe direction.
• feature_cache_interval (default 4) - cache a frame every N frames. Higher = less memory traffic, weaker temporal memory.
• feature_bank_max_frames (default 4) - how many frames of history the bank keeps. This is the size of the memory; 4–8 is the sensible band.
• use_feature_injection (default on) - master switch for the injection half of the mechanism.

Output: a single MODEL - the patched clone - which you feed into your sampler exactly where the original model would have gone.

Set your expectations, because the community did

The honest community verdict on this approach, from someone who actually ran StreamV2V-style methods: feature caching and temporal attention "still is pretty slow and doesn't compile very well the last time i tried" (r/StableDiffusion, Feb 2025). That's the note to hold. The idea is sound and this port is faithful, but you're on the bleeding edge - expect the patched model to run slower than a plain pipeline, expect torch.compile to be grumpy with the custom attention path, and treat it as a real-time-consistency experiment rather than a free lunch. It's also a streaming node: the frame counter and bank are instance state, so it assumes one continuous video-to-video run, not isolated single-image calls.

Installing

Ships in livepeer/ComfyUI-Stream-Pack - install the pack once via ComfyUI Manager (search "ComfyUI-Stream-Pack") or:

cd ComfyUI/custom_nodes
git clone https://github.com/livepeer/ComfyUI-Stream-Pack
# restart ComfyUI

The pack's requirements.txt pins torch and diffusers, which this node leans on (the attention code is written against diffusers' attention-module internals), alongside numpy, scipy, faster_whisper, mediapipe, opencv-contrib-python and requests. Nothing extra to download for this node itself - the cost is compute, not weights.

Where people get burned

• It patches a clone, but state lives on the node. Re-running the same node keeps its frame counter and bank; if your "new video" starts mid-flicker, reset/restart the workflow to clear the memory.
• The flicker fix trades speed for consistency. If your stream is already at the edge of your frame budget, this node can push it over. Measure before you ship it.
• It's built for the streaming V2V case. On a one-shot image it adds overhead and does nothing visible. Reach for it only inside a real-time video-to-video graph.