JR MiniMax H3 Sequential Video Output

If you've ever spliced AI video clips with a separate audio track, you know the pain: re-encoding each piece adds generation loss, audio drifts out of sync, and the seams click. JR_H3_SequentialVideoOutput is the last node in the JR MiniMax H3 sequential chain, and it's built to dodge all three. It commits each decoded chunk to disk as a validated H.264 segment, then - only when every chunk is in - stream-concats the segments and muxes your original continuous audio exactly once. It replaces the normal Video Combine node on this branch, and it's the reason the whole multi-prompt workflow can claim it never re-encodes audio per chunk.

What happens on each run

Feed it the decoded images for the current chunk plus the chunk_context, and it runs a strict pipeline:

1. Keeps only the chunk's real frame count (the final chunk's decoded video is trimmed to the actual remaining audio).
2. Encodes a silent H.264/MP4 segment at your chosen quality (0–51, default 20) and bit depth (8- or 10-bit).
3. Validates the segment with ffprobe before trusting it.
4. Saves the last frame as a PNG - that's the frame the Continuation Guide reads for the next chunk.
5. Atomically advances the job manifest.
6. If auto_queue_next is on, queues exactly one more prompt for the next chunk.

The first usable encoder gets recorded in the manifest, and every later segment must use the same encoder or the node fails closed - because concatenating streams from different encoders produces garbage or corrupt playback, and this node refuses to find that out for you. After the last chunk it writes an ffconcat list, concatenates with -c:v copy (no re-encode of the video), and muxes the original full continuous PCM to AAC once. The final output never loads all chunks back into one image batch, which is the memory payoff of the whole branch.

Inputs worth touching

• quality - CRF-style quality for H.264 (default 20; lower is better quality, bigger file).
• audio_bitrate - the final AAC mux bitrate, 96k–320k (default 192k). This only affects the final mux, since each segment is silent.
• auto_queue_next - default on. This is where the browser caveat lives: the next prompt is queued through the frontend, so an active browser is required for hands-off runs. Close it and the workflow pauses safely after the current chunk commits; reopen and queue once to resume from disk.
• aggressive_memory_cleanup - default on; collects references and asks ComfyUI for a soft cache cleanup after each commit.

Outputs are filename (the final MP4 path once complete, empty while chunks remain) and a status string. The node is an output node (OUTPUT_NODE = True), so it's the execution root of each chunk prompt - which is exactly why it can gate the sequence.

Installing it

Same pack, same install as the rest of the JR MiniMax H3 suite:

cd ComfyUI/custom_nodes
git clone https://github.com/Goldlionren/ComfyUI_JR_MiniMaxH3Node.git
<ComfyUI-Python> -m pip install -r .\ComfyUI_JR_MiniMaxH3Node\requirements.txt

Use the Python that runs your ComfyUI, not your system Python. The pack's one real dependency is imageio-ffmpeg>=0.5, which also guarantees an FFmpeg binary when your PATH doesn't have one - and this node needs FFmpeg, full stop. ComfyUI Manager (search "JR MiniMax H3") works too. Restart after installing.

Troubleshooting

The "Chunk was already committed" status is not an error - it's the node being idempotent when you re-run an already-committed chunk, and it returns the final filename. "Previously selected segment encoder is no longer available" happens when FFmpeg's encoder list changed between chunks; the job fails closed rather than mixing encoders, so restart with the same environment or start a fresh run. And if auto-queue silently stops, it's almost always the browser: the frontend queues the next prompt, so a closed or reloaded browser pauses the run after the current chunk - that's the designed failure mode, and re-queuing once resumes cleanly from disk.