marioslideshow - Renderer

The "marioslideshow - Renderer" is the export stage of this pack's modular workflow. The idea is you never render to video until the plan is locked: Load Images feeds your photos in, the Director companion node plans the shot order, scenes and timing, and optionally the Subject Framer decides where the camera should point. The Renderer takes that finished MARIO_PLAN, plus the same photos, and streams the whole thing to an MP4 on disk. It's the one node in the chain that actually makes the video, and it's marked as an output node for good reason.

What you actually set

The required inputs are the output settings you'd expect from any video render, so don't let the long list scare you:

• plan (MARIO_PLAN) - the shot plan from the Director. You don't hand-type this; you wire it.
• width / height / fps - your output canvas, 1280×720@30 by default.
• framing - how a photo fills the scene when its aspect ratio differs from the canvas. The tooltip says it best: Smart fit preserves the photo when the ratio differs strongly. Fill crops to cover, Contain letterboxes.
• quality - Preview, High, Master. This maps straight to the x264 encode: Preview is CRF 25 at veryfast, High is CRF 18 at medium, Master is CRF 14. Preview for iteration, High for sharing, Master only if you're actually publishing - Master will make you wait.

Everything else is flavor you can tune later: transition_seconds (0.28 default), intensity of the camera moves, motion_blur (Off / 3-sample standard / 5-sample fine), grain, the accent color used by the graphic overlays, seed, and filename_prefix. For audio you have two mutually exclusive options: an audio_file path or the AUDIO socket - connect one, not both.

How it renders

Underneath, the Renderer is a forked version of the pack's single-node engine, so it shares all the machinery: each frame is composited with Pillow - scene layouts, headlines, transitions at plan boundaries, an accent-colored progress bar if you leave show_progress on - then motion blur averages 3 or 5 sampled frames and grain adds a touch of noise. Frames stream raw to ffmpeg as they're made; the pack finds ffmpeg via imageio-ffmpeg, so you don't need a separate system ffmpeg install.

The outputs are the payoff: video (native ComfyUI VIDEO), mp4_path (a plain STRING path if you want to hand it to a shell or other tool), poster (a grab at ~0.6s), plus fps and frame_count. Files land in ComfyUI/output/marioslideshow/ - MP4, a poster JPG, and a JSON manifest of your settings and shot plan.

Installing it

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: run the pip line with .\python_embeded\python.exe. ComfyUI Manager listing is still pending, so clone-and-pip is the reliable path. And read the README's top banner: this standalone repo is superseded by the unified MSCH Nodes pack - fine to keep using, just don't install both or nodes get registered twice.

Where people get burned

The Renderer inherits the one-source rule from the main engine: "Supply exactly one image source: photos, images, or image_folder." Connect photos from Load Images or an IMAGE batch or fill image_folder - never two at once, and leave image_folder empty when photos is connected (that's what its tooltip is telling you).

The subtler trap is ordering. Everything in this workflow is positional: the Director plans shots against the photos in a specific order, and the Subject Framer's focus items are indexed to the same order. If you regenerate or reorder the photo collection between planning and rendering, the focus boxes and headlines silently point at the wrong images. Feed the Renderer the same photo source, same order, as the Director and Framer runs.

Also: native VIDEO output and the in-browser preview need a reasonably current ComfyUI - the README flags that native video requires a compatible version. If the video socket or preview misbehaves, update ComfyUI before blaming the node. And remember rendering here is CPU-side Pillow compositing plus x264 encode, so Master quality on a long, large-format promo is a "go make tea" operation, not a "wait five seconds" one.