Element Video Clip

Element Load and Edit Video only builds a map of your cuts; this is the node that turns the map into footage. Element Video Clip takes the info bundle from the editor node, decodes the frames and audio for whichever timeline segment(s) you ask for, and hands you actual IMAGE, AUDIO, frame counts, and timings. If the editor is the front door, this is where the living room is.

Why you'd reach for it

In a reference-video or video-to-video workflow (this pack lives in the MiniMax H3 world, but the trio works wherever you feed frames into a video model), you rarely want the whole source in one shot. You want this segment - the one you highlighted on the timeline - at this resolution and this fps. That's the whole job: pick a segment, scale it, get clean per-segment audio that doesn't bleed from neighboring clips, and keep a full-quality first/last frame around for V2V reference.

The inputs that matter

• info - connect it to Element Load and Edit Video's info output. Nothing else feeds it.
• clip_select - the mode dropdown: select clip outputs whichever segment is selected on the editor's timeline, segnum picks by number, first clip/last clip grab the ends, and all concatenates every segment in timeline order. Default is select clip, which is the interactive way to work.
• SegNum - the 1-based segment index, only used when clip_select = segnum.
• target_long_edge - scale so the long edge equals this value, aspect kept. 0 = keep source resolution. The default 1366 is roughly 768p on a 16:9 clip - plenty for feeding a video model's reference input, and it saves you from shipping 4K frames into a latent that can't use them. Set it larger than the source and it will happily upscale, so don't.
• scale_first_last - off by default, and this is a deliberate choice: first_image/last_image stay at source resolution so you always have a full-quality reference frame even after downscaling the main images output. Flip it on only if you want the first/last frames to match the scaled size.

What comes out

Seven outputs. images is the decoded frame sequence (a float32 tensor, sized by target_long_edge). audio is an AUDIO bundle - waveform plus sample rate - decoded per segment so you never hear the tail of the clip before it. frame_count and seconds follow your force_rate/subsampling settings from the editor. first_image and last_image are the end caps for V2V reference, and info is a fresh bundle describing what was actually output - real fps, the size after scaling, the exact source ranges - which feeds Element Video Info.

Wiring it forward: images into a VAE-encode (or wherever your video model wants an image batch), audio into anything that consumes ComfyUI's AUDIO type (H3's audio decode, a save node), and the info into Element Video Info for the numbers.

The memory trap (this is the real gotcha)

images is materialized all at once as float32, so memory ≈ frames × width × height × 12 bytes. A 300-frame clip at the default 1366-wide scale lands around 3.5–4 GB before you've touched a model. For long videos:

• Run one segment at a time (select clip or segnum) instead of one giant all.
• Use target_long_edge to keep resolution honest - a reference-video input doesn't need 4K.
• Cut frame rate with subsampling or force_rate (24 fps is usually enough).
• If the output tensor sticks around after a run, ComfyUI's --cache-lru flag keeps post-run caches from piling up.

What bites people

• If you see "No usable video source in info", the source file the editor referenced is gone - Element Video Clip decodes from that path, and it isn't packaged into shared workflows. Re-import in the editor node and re-run.
• First/last frames bigger than your images isn't a bug - that's scale_first_last sitting at its default. Leave it unless you need matching sizes.
• Sharing the workflow JSON shares the cuts, not the footage. Anyone you send it to re-imports their own video.