MiniMax H3 Aicg 视频段落

AICG3D_H3SequenceSegment - MiniMax H3 Aicg 视频段落 - is the node you'll place the most of. One per shot. Prompt, seconds, seed, optional reference media, and a wire to the previous segment. That's the whole interface, and stacking them is how the pack does "infinite length": there's no segment count limit, you just keep adding nodes.

The closest comparison from other models is last-frame chaining, except the handoff here is a latent tail rather than a decoded frame, and every segment shares one sampled config. Less drift per join - but the same rule applies: chaining accumulates. Ten segments of a mediocre first segment is ten segments of a mediocre film.

The mechanism

The first segment receives the global config via sequence_config and samples from scratch. Every later segment receives only previous_segment - the config rides along inside it. When a segment samples, its plan goes roughly: build conditioning from its own prompt and media, attach the previous segment's tail (latent or RGB, per the global handoff_mode, handoff_frames frames of it), carry the audio tail too so speech doesn't restart, sample, then do the VRAM cleanup the global config asked for before handing off.

Reference media resolve through tags in the prompt: <Picture 1>, <Video 2>, <Audio 1>. You rarely type those - the node's inline resource library inserts them when you click a thumbnail, and the pack rewrites global ordinals to the compact local numbering H3 expects. If a segment has no media of its own it inherits the previous segment's set, which is the behaviour that makes a character-consistent film practical: set the reference images once at segment 1, and segments 2–10 all see them.

Inputs and outputs

Required:

• prompt - this shot's description. Multiline, dynamic prompts enabled.
• seconds - 0.2 to 30 per segment. This is real time; the node does the frame-grid math.
• seed - this segment's own noise seed. The tooltip says it plainly: 0 means random every run. Everything else is fixed, so if you want reproducible rerolls, set an explicit number (or let 分段提示词解析's "sequential seeds" fill them in).

Optional:

• sequence_config - the global config. First segment only.
• previous_segment - every segment after the first.
• media - the external resource-library bundle, if you're using one; the media_1…media_45 slots and inline_media_state are internal plumbing for the inline library, not something you wire.
• inline_media_state - records what the inline library is holding, so the workflow reloads with your media intact.

Output: segment (MINIMAX_H3_SEQUENCE_SEGMENT), into the next segment, or into 最终合成视频 at the end of the chain.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/JGRFW/comfyui-AICG3D

Restart, hard-refresh with Ctrl+F5 - the node's inline library is frontend JavaScript and will look broken on a stale cache, which is why the pack versions its UI script. Node menu category is AICG3D; search Aicg if the Chinese labels make you scroll.

Using it without going mad

Two canvas conveniences do most of the work: 添加下一段 appends the next segment node and wires previous_segment for you, and 删除这一段 removes one and re-stitches the chain. Use them. Hand-wiring a ten-segment chain and then deleting segment four from the middle is exactly as fun as it sounds.

And 分段提示词解析 will fill the prompt, seconds and seed of every 视频段落 on the canvas from one script in a single button press. That's the intended workflow for anything over about three shots.

What goes wrong

"请把全局设置的 sequence_config 接到第 1 段的这个节点." You started the chain with a node that has neither a config nor a previous segment. Something has to be first.

Segments look like different films. Usually one segment has its own media in the inline library, so it stopped inheriting and started rendering from a different reference set. That's by design - the moment you open the library and change the media, that segment becomes independent and starts propagating its own set downstream.

The seam pops. Look at handoff_frames and exposure_lock in the global config before you blame the prompt. 5 frames is cheaper and looser; 22 is steadier and slower. A hard cut is supposed to pop, though - if you're cutting between shots, that's not a defect.

It's slow and the GPU is idling between segments. vram_policy is set to 卸载模型, so every segment reloads the weights. Switch to 释放缓存 unless you're genuinely out of memory.

One opinion to save you a morning: don't try to write a coherent 60-second story in ten prompts on the first attempt. Generate two segments, look at the join, then commit to the rest. Segments are cheap to add and expensive to debug.