Load Frame Pair From Dataset

The optical-flow nodes need two things: the frame you're on and the frame before it. You could load those with two separate LoadFrameFromDataset nodes and subtract one from the other with an OffsetNumber, and plenty of older workflows do exactly that. This node saves you the wiring - it loads the current frame and the previous frame from the same dataset in one call, returns both, and throws in the frame number as a bonus.

That convenience isn't trivial, because the pair is the backbone of every flow-based step: ExtractOpticalFlow and ExtractFlowAndMixConsistencyMaps both take current_frame + previous_frame, and both expect them to be the same resolution. LoadFramePairFromDataset quietly enforces that for you by resizing both frames to the same fit_into box during load, so you can't accidentally hand the flow extractor a mismatched pair.

Inputs

• frame_dataset - from MakeFrameDataset.
• seed - the current frame number (the "current" of the pair).
• total_frames - clip length, used for clamping.
• fit_into (default 1280) - both frames are resized so their longest side fits within this box, keeping aspect ratio and snapping to multiples of 8. This is your pipeline resolution control; 1280 is a sensible default for SDXL-class models.

Outputs are Current frame, Previous Frame, and Frame number. The first two go to your flow extraction or directly into the warp/blend chain; the frame number keeps SaveFrame/RenderVideo in sync. Note the previous frame is loaded as seed - 1, so at frame 0 it tries frame −1 and the clamp hands back frame 0 again - meaning the very first pair is the same image twice, which produces zero flow. That's harmless (the flow extractor zeroes out static scenes) but worth knowing if you're debugging why frame 1's flow looks empty.

Why you'd reach for it

Honestly, this is the loader I default to in any ComfyWarp graph that touches flow. It collapses three nodes into one, guarantees matching resolutions, and its outputs line up exactly with what the flow and mix nodes want. The only time to avoid it is when you specifically need different resolutions for current vs. previous, which basically never happens. Pair it with MakeFrameDataset upstream, a counter from FixedQueue, and the whole frame-feeding side of your workflow is done.