Latest Video Last N Frames

Latest Video Last N Frames is the "give me a bit more context" version of its sibling. Where Latest Video Final Frame hands you the single last frame of the newest video in a folder, this one grabs the trailing N frames as a batch - default 6, up to 1000. Same folder-watching premise, but the batch output opens up better loop seeds and a nicer way to eyeball a render's ending.

The use case that sells it: you're iterating on video and you want to see how the last chunk came out, or you need a small tail of frames to seed the next generation rather than trusting a single frame that might have caught a glitch frame. Six frames costs you nothing to look at and tells you instantly whether the render ended clean or went to noise.

Inputs

• directory_path - where to look for videos.
• num_frames - how many frames to take from the end. Default 6.
• recursive_search - subdirectory scanning, off by default.
• video_extensions - the extension list, default mp4,avi,mov,mkv,webm,flv,wmv.

Outputs

• frames - the tail frames as an IMAGE batch, in order.
• video_filename - which file it read.
• frames_extracted - how many it actually got. This one's honest: if the video has fewer frames than requested, it returns everything it can and reports the real count, so you can branch on it instead of assuming you got a full batch.

How it works

Same honest mechanism as the family: glob the extensions, pick the newest by modification time, open with OpenCV, seek to total_frames - N, and read forward. Frames come out in temporal order, so the last frame of the batch is the actual last frame of the clip - the ordering is intuitive and it means you can just take frames[-1]-style logic for the final frame without reversing anything.

Install

Part of TrentNodes:

cd ComfyUI/custom_nodes
git clone https://github.com/TrentHunter82/TrentNodes.git
cd TrentNodes
pip install -r requirements.txt

Restart and it's under Trent/Video. OpenCV is the only real dependency.

Gotchas

The same "newest by mtime" caveat as its sibling applies: a file you touched gets promoted to the front of the line. And there's a real trap hiding in the frames_extracted output - if you request 6 frames from a 4-frame video, you get 4 frames and a count of 4, not an error and not 6 padded frames. If your downstream assumes a fixed batch size (a sampler expecting 6), that's a silent shape mismatch. Branch on frames_extracted or keep num_frames smaller than your shortest clip. Also worth knowing: it reads the literal end of the file - any end padding your renderer adds will be in that batch, which is exactly why grabbing a few frames instead of one is often the safer loop seed.