🧩 MiniMax Video Patch Reassembler (视频回填缝合器)

You just re-rendered chunk #7. Now it has to go back into the timeline it came from, at the right frame offset, without a visible pop at either end, with the audio still in sync. Doing that by hand is the tedious part of long-video work - and it's the part nobody wants to do thirty times.

MiniMax Video Patch Reassembler (视频回填缝合器) is the back half of this pack's long-video pipeline. It takes your edited frames, replaces the matching window in the master timeline, softens the seams, tracks how much is done, and hands you either the whole assembled video or just the patch.

Why you'd reach for it

Editing a long clip in H3-sized pieces is a bookkeeping problem: which frames does this chunk cover, what's left, where does the final MP4 come from. This node holds all of it, and the frame window comes out of the slice_context the chunk slicer gave you, so you never type offsets.

It also closes the continuity loop. Once a chunk is patched, the master timeline is the edited version for that range - which is what the slicer's prev_last_frame and prev_ref_frames read on your next chunk. Patch first, then slice the next one, and your references are your finished work, not the untouched source.

Same caveat as the rest of the pack: H3's open weights are licensed out of the US, EU, UK and Korea, so this assumes you're somewhere it's licensed to run.

How it works

edited_images arrives with slice_context describing where it belongs. The node writes it into the master frame array at that window, resizing bilinearly if your chunk resolution doesn't match the master. The master base frames are rebuilt lazily from the original video on the first patch, so it never needs the whole film decoded to start.

Then the seam work, which is the interesting bit. Over the first seam_blend_frames frames it blends the original into your patch on a raised-cosine curve (0.5 − 0.5·cos(t)), and mirrors that on the tail (0.5 + 0.5·cos(t)). Raised cosine beats a linear ramp here because it starts and ends flat, so there's no velocity change at the join. Head blending is skipped when the patch starts at frame 0, tail blending when it ends at the last frame, and the blend width is capped at half the patch length so a short chunk can't eat itself.

Audio is spliced sample-exactly at frame / fps × sample_rate, mono duplicated to stereo. Chunk status flips to completed, coverage and gaps get recomputed, and state persists to output/minimax_h3_bins/<project>/ - so a project survives a restart.

Inputs and outputs

Four things you actually set:

• slice_context - mandatory, and it has to come from the slicer that produced these frames. Mismatched context is the number one way to drop a chunk in the wrong place.
• seam_blend_frames - default 2. Go to 4–6 if the join shows on motion; 0 gives a hard cut. It's a local blend, not a morph, so it won't rescue a genuinely mismatched patch.
• output_mode - Full Assembled Video passes the whole timeline downstream as one IMAGE batch; Current Patch Only passes just your chunk. The second is what you want most of the time.
• save_to_session - default True. Off makes the node a pass-through that records nothing, handy for previewing without committing.

edited_audio is optional: feed the chunk's audio through if your chain regenerated sound. Leave it unconnected and the original audio for that window stays untouched, usually the sane default.

Outputs: output_images (whole timeline or just the patch), output_audio (44.1kHz, length-matched to the frames), is_all_completed - gate a final save or export branch on it to stop the loop - and timeline_summary, the coverage percentage plus the first unedited chunks, as text.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/knoic/ComfyUI-MiniMaxH3-PrefixStream.git
cd ComfyUI-MiniMaxH3-PrefixStream
pip install -r requirements.txt

Or search ComfyUI-MiniMaxH3-PrefixStream in ComfyUI Manager. Restart, then Ctrl+F5 - the on-canvas timeline and export button are frontend code and won't appear on a stale cache. Like its sibling, this one needs a system FFmpeg/ffprobe on PATH despite the short requirements list, because the master is rebuilt with FFmpeg.

Where people get burned

Full Assembled Video is a memory decision, not a display preference. Frames are float32 in RAM: at 24fps and 1280x720 that's ~11MB per frame, so a two-minute master is around 4,000 frames - call it 44GB before an encoder sees a byte. The on-disk uint8 copy is a quarter of that. Past a couple of chunks, use Current Patch Only plus the node's 🎬 导出全片 MP4 button (it encodes the assembled master from disk to H.264 in your output folder) or the pack's disk-streaming node, instead of pushing a giant batch through VHS.

A short patch doesn't error - it pads. If your frames don't match the window length the node trims the excess or repeats the last frame. That repeated frame is a freeze you'll spot in the final video, so if a segment looks stuck at the end, this is why.

Resolution mismatches get resized, quietly. Bilinear-upscaling a 768p patch into a 1080p master looks soft and only the log tells you. Keep the slicer's target_width and target_height consistent, and don't run two ComfyUI processes on the same project - writes are guarded inside one process, not across them.