InfiniteTalkEmbedsSlice

InfiniteTalk conditions its video generation on audio, but not on the waveform itself - on embeddings, specifically the Wav2Vec2 features Kijai's WanVideoWrapper produces via the MultiTalkWav2VecEmbeds node. Those features run at a fixed 25 frames per second. The moment your video is longer than one generation window - which is the entire point of an "infinite" talking-head model - you need to feed the sampler only the slice of embeddings that corresponds to the chunk of frames you're currently rendering. That's this node's entire job.

InfiniteTalkEmbedsSlice takes a MULTITALK_EMBEDS object and cuts it to match a video-frame interval. Because the audio features are a fixed 25 fps, the conversion is pure arithmetic: an audio frame equals one video frame at 25 fps, so at any other fps the node scales the interval (start_audio_frame = start_video_frame × 25 / fps, same for length). It's a small node, but it's the difference between "generate each segment with its own tiny slice of audio" and "try to jam the whole audio conditioning into one render." The workflow uses it inside the per-segment for-loop: each iteration advances the window, slices the embeds, and hands them to WanVideoImageToVideoMultiTalk. That's how the pack keeps VRAM flat no matter how long the video gets.

Inputs, and they're all straightforward: multitalk_embeds (the embed object straight out of MultiTalkWav2VecEmbeds), start_video_frame (where in the video this chunk begins), video_frame_length (how many video frames this chunk covers), and fps (your video frame rate, default 25). The output is a single sliced_multitalk_embeds in the same MULTITALK_EMBEDS format, so it plugs straight back into the same Kijai nodes. It also carries through the ancillary fields - audio_scale, audio_cfg_scale, and ref_target_masks - so you don't lose your conditioning settings at the slice boundary.

One behavior worth knowing: if the slice starts past the end of the audio features, the node returns an empty embedding rather than an error. That's deliberate and it means a mis-configured chunk boundary degrades into a blank segment instead of a crash - check your loop arithmetic before you blame the model. If the audio ends mid-chunk, it clamps to the available frames, which is the expected behavior for the final segment of a video.

The category field says WanVideoWrapper, which is the honest hint: this node only makes sense sitting between Kijai's MultiTalk nodes. It ships in the same ComfyUI-InfiniteTalk-MultiImage pack as the rest of the orchestration, so installation is identical - ComfyUI Manager search ComfyUI-InfiniteTalk-MultiImage, or clone into custom_nodes and restart:

cd ComfyUI/custom_nodes
git clone https://github.com/xuhongming251/ComfyUI-InfiniteTalk-MultiImage

No Python dependencies come with it (the pack's requirements.txt is empty), but the workflow around it needs ComfyUI-WanVideoWrapper, the InfiniteTalk fp8 weights from HuggingFace (MeiGen-AI/InfiniteTalk), a Wan 2.1 I2V model and VAE, Wav2Vec2, and MelBand RoFormer. Load the bundled workflow JSON and let Manager fill in the blanks.

The one setting you'll realistically change: keep fps identical to your sampler's frame rate, or your slices drift out of sync with the audio and lips start lagging. With the default 25 everywhere, it just works.