Based on the pipeline documentation and code of the ZView Space H3 worker, October 2026. This describes our own workflow, not an official MiniMax method.
MiniMax H3 generates up to 15 seconds per clip, according to the ComfyUI launch post. Anything longer has to be built from several clips, and the hard part is making them feel like one video instead of four unrelated ones. This is the approach we settled on after running it in production: take the last frame of one clip, feed it to the next clip as the actual first frame, and stitch the results.
Why not just ask for 60 seconds
Our notes on the first long-form profile say it plainly: a single 60-second render is not practical on our workers, so the 60-second profile is four 15-second renders. Shorter renders also fail more gracefully. If scene three comes out wrong you redo scene three, not the whole minute.
Reference conditioning vs a hard first frame
H3 accepts images in two quite different ways, and the difference decides whether chaining works.
- Reference-to-video treats an image as loose guidance. The model keeps the subject's look but is free to choose its own opening composition.
- First-frame (image-to-video) treats the image as the actual opening frame. In ComfyUI this is the `MiniMaxH3ImageToVideo` node and its `first_frame` input.
For chaining you want the second one. If the next scene only gets the previous frame as a loose reference, pose, framing and lighting can jump at the cut. So in our multi-scene profiles each scene after the first starts from the previous clip's decoded final frame, supplied through the first-frame input rather than as loose conditioning. For a normal single-image job we also use the uploaded image as a hard first-frame lock rather than reference-only conditioning.
The chain, step by step
Our 60-second story profile works like this:
1. One reference image starts scene 1. 2. After each scene finishes, the server extracts its final frame. 3. That frame becomes the first frame of the next scene's render. 4. When all four 15-second scenes are done, FFmpeg concatenates them into one 60-second file. 5. A final delivery pass normalises the result to 1080 x 1920 (9:16) or 1920 x 1080 (16:9), whatever size the model rendered at, using a Lanczos upscale, a centred crop and an H.264/AAC encode.
A second profile uses six 10-second scenes. It starts with a still image, has a vision model describe what is actually in the picture, and then has a text model write a six-scene screenplay grounded in that description, including the explicit state the last frame of each scene should end in. There is no fallback script: if the image analysis or the screenplay step fails, the job fails before any H3 render starts, because a generic fallback story would not match the image.
Keep the camera and the physics consistent
Chaining only hides the seam if the content on both sides agrees. Three rules did most of the work for us:
- Write the last-frame state into the prompt. Each scene's prompt says what pose, gaze, hand position and lighting the clip should end on, so the next scene has something coherent to start from.
- Fix the camera per workflow. A fixed-camera sequence should never get a handheld move at a boundary; each workflow keeps its own camera rule.
- Describe motion as cause and effect. We inject the same instruction into every H3 prompt: movement must follow physical causality, hands, feet and props must stay in contact with what they touch, and generic filler gestures are removed. Prompts with a concrete event (one subject, one object, one immediate problem, a short beat sequence) behave better than prompts that just ask for "natural movement".
For sequences that must feel like one continuous shot, we go a step further: the incoming clip's final 17 frames are passed to the next render as motion context, the first second of the new clip reproduces that motion without advancing the story, and all segments reuse one random seed per request so no unrelated noise pattern appears at each boundary. Our own documentation is careful to call this a model-guided contract, not a pixel lock: the model can still drift.
What still goes wrong
- Slow identity drift. Each hand-off is a re-render, so small changes in face or clothing can accumulate over four or six scenes. In principle, fewer and longer scenes give drift fewer chances to build up, though we have not measured that.
- Audio is generated per clip. H3 produces audio in the same pass as each clip, so expect an audio seam at every cut unless you re-mix. We handle music as a separate step.
- Cost adds up linearly. Chaining adds almost no overhead of its own; render time is the sum of the scenes (see our [measured H3 render times](/articles/minimax-h3-render-time-comfyui-worker/en)).
- A bad scene poisons the next one. The last frame of a failed scene is the first frame of the next, so check each scene before continuing if you can.
Checklist
1. Render each scene with the previous final frame as a true first frame, not a loose reference. 2. Write the end state of every scene into its prompt. 3. Keep camera, lens and lighting constant across the chain. 4. Concatenate with FFmpeg, then run one delivery encode for the whole file. 5. Plan the audio separately. 6. Budget the time: it is the sum of the scenes.
The technical details above come from our internal H3 documentation and worker code as of 19 October 2026. H3 itself is distributed under the MiniMax H3 Community License; MiniMax's local deployment guide describes regional conditions, so check the licence text before commercial use.