marioslideshow - Extract Frames

The MSCH slideshow nodes hand you a native ComfyUI VIDEO, which is great for previewing and for video-to-video tools. It's useless for the stuff you actually want to do to a promo you like: upscale the frames, run a light img2img pass on one shot, save individual stills. Those all want an IMAGE batch. MarioSlideshowFrames ("marioslideshow - Extract Frames") is the bridge - it pulls a bounded slice out of the slideshow's MP4 and hands it to you as frames plus the source FPS.

If the pack already has VIDEO handling built in, why another node? Because loading a whole video as a giant image batch is how you blow up RAM, and this node is deliberately stingy about it. That's the whole personality of this thing.

How it works

The slideshow engine writes a real MP4 to disk, so "extract frames" is just decoding that file with PyAV (av is in the pack's requirements) and stopping early. It decodes frames in order, skips anything before start_frame, copies up to max_frames into a pre-allocated torch batch of [count, height, width, 3] floats, then breaks out. Nothing loads until you ask for it.

The guard that will actually bite you is memory_limit_gb. Before touching the file, the node estimates the batch size - frames × width × height × 3 × 4 bytes - and refuses to run if it exceeds your limit. Do the math on the defaults and you'll see the trap: 120 frames at 1280×720 floats out to about 1.24 GB, which is more than the default 1.0 GB memory_limit_gb. So a fresh 720p render at max_frames = 120 will error until you bump the limit to ~1.5 or dial the frame count down. Not a bug - a polite way of stopping you from eating your whole machine.

The one constraint that trips everyone

Read the error message if you get one, because it's honest: "Connect the original marioslideshow VIDEO output. Use Get Video Components for other video types." This node refuses any VIDEO that isn't this pack's own output - including trimmed versions of it (the check verifies the active trim window is untouched). If you need frames from some other node's video, the error is pointing you at VideoHelperSuite's "Get Video Components" instead. This is a purposeful narrowness, not a missing feature.

The inputs that matter

• video - the original slideshow VIDEO output. Nothing else.
• start_frame - where to start, 0-based.
• max_frames - how many frames to pull (up to 10,000, but RAM).
• memory_limit_gb - the ceiling that makes the node refuse a greedy request. Raise it when the estimate error appears.

Outputs are frames (IMAGE batch, wire it into any image processor, upscaler or img2img chain) and fps (FLOAT, hang onto it if you plan to put the edited frames back into a video context).

Installing it

The whole pack installs at once:

cd ComfyUI/custom_nodes
git clone https://github.com/mariobilly/msch-slideshow.git
cd msch-slideshow
python -m pip install -r requirements.txt

Restart ComfyUI and hard-refresh the browser. Windows portable users run the pip line with .\python_embeded\python.exe instead of python. ComfyUI Manager may not list this pack yet (its Registry entry is still pending verification), so the git route is the reliable one.

One gotcha before you start: the README's top banner says msch-slideshow is superseded by the unified MSCH Nodes collection. The standalone repo still works and still gets the updates this pack ships with, but don't install both - you'll register duplicate nodes and ComfyUI will throw "node already exists" noise.

When it errors

• "The requested frame range is outside the video" - your start_frame is past the end, or you've asked for more than exists. Trim the range.
• "This range needs X GB. Reduce max_frames or increase memory_limit_gb" - see above; raise the limit or cut frames.
• "The video ended before the requested frame range" - decode stopped early; you asked for frames that aren't there.

That's it. For a promo you like, this is the node that turns the finished MP4 into material you can keep polishing.