@greggyq159 For restarting from a later chunk in the current V3.2.4 workflow:

1. Set:

Run Storage = Save + Auto Resume

Run Name = blank, unless you want to use a manual name

Regenerate From = Chunk 2

2. Queue the same workflow again.

The automatic Run Storage ID is generated from the sampler configuration when Run Name is blank. You do not normally need to create or enter an ID manually.

With Regenerate From set to Chunk 2, the saved chunks before Chunk 2 are reused, and Chunk 2 and later chunks are generated again.

Keep the model, reference inputs, resolution, continuity, and other contract-related settings compatible with the saved run. Changing those settings may create a different Revision and prevent reuse.

Run Storage must be set to Save + Auto Resume; Regenerate From does not work as a reuse operation when storage is disabled.

You do not need to redefine the subjects three separate times.

For Ref2VA, define the reference relationships once:

- Subject definitions

- Summary

- Retention analysis

- Detailed description

- Overall soundscape

- Non-diegetic music

The reference images and optional reference audio remain available throughout the generation.

For H3 Continuum, however, the visual timeline should be divided into one section per 5-second chunk. For a 30-second video, use six timeline sections rather than one unstructured 30-second paragraph.

For example:

[0-5s]

The woman stands in the opening composition and begins walking slowly toward the camera.

---

[5-10s]

She continues walking along the same street while the camera tracks backward.

---

[10-15s]

The camera moves slightly to her side as she looks toward the storefronts.

---

[15-20s]

She slows down and turns naturally toward the camera.

---

[20-25s]

The camera makes a gradual push-in while she continues the same action.

---

[25-30s]

She reaches the end of the movement and holds the final pose.

The complete Ref2VA reference definitions are written once. Only the action, camera movement, and scene progression change from chunk to chunk.

In practice:

- Standard Ref2VA: one short video generation with persistent references.

- H3 Continuum: multiple 5-second generation chunks with persistent references and separate timeline instructions.

Use --- separators or explicit time ranges so Continuum can detect the individual chunk prompts. Avoid repeating the entire subject description six times, and avoid using one long unstructured paragraph for a multi-chunk generation.

Clarify that:

1. In Ref2VA, subject definitions, summary, retention analysis, and other reference relationships are written once.

2. Reference Images and Reference Audio remain persistent across Continuum chunks.

3. For Continuum, the visual timeline should be divided into one prompt section per 5-second chunk.

4. Do not repeat the complete subject definitions for every chunk.

5. Do not rely on one unstructured 30-second paragraph. Use six clearly separated 5-second sections, with --- separators or explicit time ranges such as [0-5s], [5-10s], and so on.

6. Each chunk should describe the action, camera movement, and scene progression for that interval.

7. The prompt must match the number of requested chunks.

8. Make clear that this is for long-form Continuum generation, not ordinary single-pass Ref2VA.

Include a short six-chunk example using:

- one woman as the main subject,

- two reference images,

- one optional reference audio,

- six 5-second chunks,

- consistent identity and clothing,

- gradual camera and action progression.

Do not claim guaranteed frame-perfect continuity or exact audio copying.

@nekotxt Almost, but the 5-second rule applies to Continuum chunks, not individual shots.

You can use the standard Ref2VA prompt structure. Only the timeline needs one prompt section for each generated chunk. With the current recommended setup, each chunk is 5 seconds:

[0-5s]

[5-10s]

[10-15s]

A 5-second chunk may contain one continuous shot or several shorter shots. They do not all have to be exactly five seconds long.

For better continuity, however, it is usually safer to keep one main action or gradual camera progression within each chunk.

If you are not using Continuum's chunk-based long-form processing, I recommend using the standard ComfyUI H3 Reference-to-Video workflow instead.

Timeline Video is mainly useful when you want to process a longer sequence in separate Continuum chunks while using a video as motion and composition guidance.

For the experimental Timeline Video node, the reference video is processed at approximately 0.4 MP by default. Using Match Output can increase processing time and memory usage significantly, so the lower reference resolution is intentional. It is used as a lightweight visual reference, not as a direct video replacement.

The purpose is not to reproduce the source person or video frame by frame. The generated subject may be different. The Timeline Video provides guidance for motion, camera movement, and scene composition, while Reference Images can be used separately for identity, appearance, and clothing.

In short:

- Standard Ref2VA: use this for ordinary image/audio reference generation.

- Timeline Video + Continuum: use this for chunked long-form generation with motion and camera guidance.

- Timeline Video does not provide exact video-to-video replacement or guaranteed identity preservation.

The Timeline Video workflow is still experimental and is being tested locally for VRAM usage, quality, and long-sequence stability.

Could you please share the complete ComfyUI error traceback, starting from

“!!! Exception during processing !!!” through the final exception line?

The Preview Text status is not enough to identify the compatibility issue.

@RusMaltsev Thank you for finding this.

Setting strict_compatibility to false disables the strict checkpoint compatibility gate. This can allow experimental combinations such as FL2VA with Reference conditioning to run instead of stopping with a compatibility error.

Please note that this is not a general fix for every error. It only relaxes the compatibility validation. For standard Ref2VA workflows, keeping strict_compatibility=true is safer. With it disabled, the node may proceed with an unverified model configuration, so reference fidelity is not guaranteed.

If the error is:

PackedLayout no longer accepts 'frame_count'

that is a separate ComfyUI Core API compatibility issue and requires a runtime update or a compatible ComfyUI revision. The strict compatibility setting should not affect that error.

Please share the complete traceback if that specific error still occurs.

@Complement_Cascade This error is caused by a ComfyUI Core API change, not by the strict compatibility setting.

Recent Core revisions changed the PackedLayout constructor and removed the frame_count argument. Please either update H3 Continuum to a version that supports your current ComfyUI revision, or temporarily use the ComfyUI revision that was compatible with the workflow.

Setting strict_compatibility to false only bypasses the model compatibility check. It does not fix the PackedLayout API mismatch.

@Complement_Cascade You are correct, and there is no need to take any blame.

I checked the current ComfyUI Core implementation. PackedLayout now accepts:

text_len, latent_t, latent_h, latent_w, audio_t, keyframes, and refs

The old frame_count constructor argument has been removed. Therefore, with the latest published H3 Continuum version at the time, rolling ComfyUI back was indeed the practical workaround.

This is unrelated to strict_compatibility. That setting only controls the model/checkpoint compatibility gate.

Sorry that my previous reply made it sound as though a compatible Continuum release was already available. The compatibility adaptation has now been implemented and tested in the current development build. Until that build is released, rollback remains a valid temporary workaround.

Thank you for identifying and clearly explaining the actual cause.

Yes. MiniMax provides an official H3 prompt-writing skill here:

https://github.com/MiniMax-AI/MiniMax-H3/tree/main/skills/h3-prompt-writing

It supports T2VA, I2VA, FL2VA, L2VA, and Ref2VA, and includes the required prompt structures and reference-label rules.

If your local Qwen setup supports agent skills, install or point it to the complete h3-prompt-writing folder.

Otherwise, provide these files to the model as persistent system context:

- SKILL.md

- references/base-en.txt

- references/ref-en.txt

The whole folder should be used, not only SKILL.md, because the detailed formats and examples are stored in the reference files.

For H3 Continuum, use the standard H3 structure generated by this skill, but divide the visual timeline into one section per Continuum chunk. In the currently tested workflow, that means one 5-second section per chunk.

@Complement_Cascade Thanks, I checked it. MinimaxH3 Auto Prompter V6.1 is a useful optional front end for generating H3 prompts.

For Continuum, I recommend changing “three shots of 5 seconds” to “three consecutive 5-second timeline sections,” because the word “shots” may encourage separate scenes or cuts.

A safer instruction is:

“Return exactly three consecutive timeline sections headed [0-5s], [5-10s], and [10-15s]. Keep them as one continuous sequence. Do not restart or repeat the subject, scene, or action at each section.”

The generated result should still be reviewed before running, because this Auto Prompter is based on the standard H3 guide and is not specifically tied to the Continuum parser.

@Complement_Cascade Glad it helped. Using the generated prompt as a starting point and then refining the timeline sections manually is currently the safest workflow for Continuum.

The important part is to keep the exact 5-second section structure and describe each section as a continuation of the same sequence, rather than as an independent shot.

Hello, thank you! I’m glad you found the workflow useful.

Use a stable speaker ID and place the exact dialogue inside an H3 dialogue tag in the timeline:

[0-5s]

<Subject 1> (S1) looks toward the camera and says in a calm young female voice:

<d>[English] The last train should be here soon.</d>

She finishes the sentence, closes her mouth, and remains silent. No other voices or background speech are heard.

Keep these points in mind:

- Put spoken words only inside <d>[Language] ...</d>.

- Assign the speaker once, such as <Subject 1> (S1), and reuse (S1) later.

- Keep each line short enough to finish inside its 5-second chunk.

- Do not repeat or paraphrase the dialogue in the summary or soundscape.

- Explicitly state that no other dialogue or background voices are present.

- Avoid splitting one sentence across two Continuum chunks.

Reference Audio can guide voice character, rhythm, or performance, but it does not guarantee an exact waveform or perfectly repeat the original speech.

MiniMax H3 generates the audio rather than playing a fixed dialogue track, so exact scripted wording is not guaranteed and it may occasionally improvise extra words. For production work requiring exact dialogue, use external TTS and a separate lip-sync or audio replacement stage.

Thank you. That is a valid distinction and a real limitation of the current node.

Timeline Video is implemented as a chunk-local motion and composition guide. It is not equivalent to MiniMax H3’s native Reference Video input, which can provide visual appearance and associated audio/voice from the same source clip.

A proper Reference Video implementation would need to preserve the native H3 video-reference semantics across all Continuum chunks, rather than slicing it like Timeline Video.

I agree that this is important for identity and voice consistency. I will investigate adding a separate persistent Reference Video input, but I cannot promise a release date until its compatibility, memory usage, and interaction with Continuation have been verified.

Thank you for clearly identifying the use case and for the kind feedback.

Yes, an interrupted run can be resumed when Run Storage is enabled and the generation contract remains unchanged.

Reopen the same workflow and keep the same Run Name, model, LoRAs, reference images/audio, resolution, seeds, prompts, and other sampling settings. Completed chunks should then be reused and only missing chunks generated.

However, changing the LoRAs, reference images, or reference audio creates a new revision by design. Those inputs are persistent across all Continuum chunks, so the current version cannot keep Chunks 1–2 from the old contract while applying different references or LoRAs starting from Chunk 3.

What you are describing is a “fork from Chunk N” feature: preserve the earlier chunks, inherit their continuation context, and start a new branch with a different conditioning contract. That is not currently implemented, but it is a valid feature request.

Closing ComfyUI itself should not prevent resume, provided Run Storage was enabled and the same stored run identity can be found.

@VI6_D_DARK_KING Glad you found the cause. Yes, Auto Resume requires the seed and the rest of the generation contract to remain unchanged.

I’ll consider “Fork from Chunk N” as a feature request: preserve completed chunks, inherit their continuation context, and continue under a new LoRA/reference/prompt contract.

Regarding the Director node, could you clarify which specific node or project you mean? MiniMax has T2V/I2V-01-Director API models, but those are separate from local MiniMax H3 and H3 Continuum. If you mean a scene-planning or timeline orchestration node, that could be a useful layer above Continuum.

@VI6_D_DARK_KING Thanks, that clarifies what you meant by a Director node. MiniMax H3 Director looks like a useful way to build and test the shot prompts before moving them into Continuum.

H3 Continuum already has a chunk_seconds setting, but it currently applies the same duration to every chunk. Most of my runtime validation has been done with 5-second chunks, so I do not want to claim that longer chunk durations are equally validated yet.

If you mean independently setting each chunk, for example 5s + 10s + 7s, that is not currently implemented. It affects more than the UI because the prompt ranges, H3 frame grid, continuation context, Run Storage contract, audio slicing, and final assembly all need to use exactly the same boundaries.

Voice-line alignment is a valid reason for supporting it. I am currently reviewing the audio path and chunk timing for the next version, so I will treat variable per-chunk duration as a feature request, but I cannot promise an implementation or timeline yet.

Thanks for sharing the Director workflow. Its compiled prompt output may also be useful for future interoperability with Continuum.

Thanks for asking. Your result is consistent with the current Timeline Video design.

Timeline Video is not a motion-only control, and it is not exactly the same as the standard MiniMax H3 Reference Video input.

In the current Continuum implementation, the connected video is divided according to the Continuum timeline:

- Chunk 1 receives the 0–5 second video slice

- Chunk 2 receives the 5–10 second slice

- Chunk 3 receives the 10–15 second slice

- and so on

Each slice is resized using Timeline Video Size, with Efficient — 0.4 MP as the recommended default, and is then supplied to H3 as a chunk-local video reference.

However, an H3 video reference contains much more than motion. It can condition:

- subject appearance

- clothing

- composition

- background

- lighting and colors

- camera movement

- body movement

Therefore, Timeline Video can dominate the Picture references and produce something very close to the source video. Picture references remain connected across all chunks, but the current implementation cannot enforce “use the pictures only for identity and the video only for motion.”

A standard H3 Reference Video supplies a reference-video block to a normal H3 generation. Continuum Timeline Video additionally divides a longer video into time-aligned slices and supplies the corresponding slice to each Continuum chunk.

To activate the current feature:

1. Connect the VIDEO output from Load Video to timeline_video.

2. Set Timeline Video Size to Efficient — 0.4 MP.

3. Keep the Picture references connected if required.

4. Describe the pictures as identity references and the video as action/camera guidance in the prompt.

There is no additional activation switch. Connecting timeline_video enables it automatically.

If you specifically need character replacement while preserving only the source motion, the current Timeline Video implementation cannot guarantee that result. Reproducing too much of the original video is a known limitation rather than a missing switch.

The video-conditioning direction is planned to be revised in a later version, after the current Driving Audio work. The planned design will distinguish source timing/motion guidance more clearly from identity replacement. The current Timeline Video should therefore still be considered an experimental video-reference mode rather than a dedicated motion-transfer system.

@byarloooarlooo279 Thanks for testing 3.4.

There isn't an extra switch that will make the Video Reference behave as motion-only guidance. Also, changing Prompt Format from Auto to Fixed will not reduce the Video Reference strength. If your prompt is normal continuous text, Auto already resolves it as Fixed internally.

For V3.4, I recommend trying:

Video Reference Size: Efficient — 0.4 MP

Keep your Picture references connected

Explicitly separate the roles in the prompt, for example:

Use <Picture 1> as the primary reference for identity, face, hair, body appearance and clothing. Use <Video 1> only as guidance for motion, pose progression, timing and camera movement. Do not copy the person, clothing, background, lighting or colors from <Video 1>.

You can also phrase the main action like:

The person from <Picture 1> performs the motion shown in <Video 1>.

However, this is still only prompting guidance. H3's Video Reference contains appearance, composition, background, lighting and motion information together, and Continuum currently has no separate Video Reference strength or true "motion only" control. So if the generated result still strongly reproduces the source video, that is a limitation of the current V3.4 reference-conditioning method rather than a missing setting.

Your feedback is useful because it confirms that this can still happen in 3.4. I am looking at ways to separate identity conditioning from video motion/timing guidance more clearly in a future revision.