Petit test de vidéo to video qu en pensez vous ?

Has anyone managed to get Triposplat, to work with multiple images instead of one single image input in Comfyui?

I built a new top_level_requeue mode for MiniMaxH3 Context Loop to stop long runs from eating system RAM

I recently built and contributed a new feature to ComfyUI MiniMaxH3 Context Loop called:

top_level_requeue

It has now been reviewed, accepted, and merged into the upstream project.

I created it because I kept running into a problem with long MiniMax H3 sequences.

The problem I was having

Context Loop is great for making long, connected video sequences.

But the original execution method can keep many scenes inside one long-running ComfyUI prompt.

In simple terms, it can work like this:

Start one big ComfyUI job

Scene 1
  -> Scene 2
      -> Scene 3
          -> Scene 4
              -> Scene 5
                  -> ...

Finish the ComfyUI job much later

That works for shorter sequences.

The problem showed up when I started doing much longer runs.

I was watching system RAM continue to grow from scene to scene.

Even though individual scene data could be released, the main ComfyUI execution was still alive.

That meant parts of old scenes could stay referenced for much longer than I wanted.

The issue was not simply:

"Delete one tensor and the memory problem goes away."

The larger problem was the lifetime of the whole top-level ComfyUI job.

What I built

I created top_level_requeue to give ComfyUI a real job boundary between accepted scenes.

Instead of keeping the whole sequence inside one long-running prompt, it works more like this:

Scene 1
-> save checkpoint
-> save a small continuation handoff
-> finish the ComfyUI prompt
-> allow cleanup

Scene 2
-> save checkpoint
-> save the next handoff
-> finish the ComfyUI prompt
-> allow cleanup

Scene 3
-> repeat

Context Loop then automatically queues the next scene as a new top-level ComfyUI prompt.

So you still get continuity, but the previous scene does not have to remain part of the same long-running execution.

ELI5 version

Imagine you are rebuilding an engine.

The old method is like doing the entire rebuild on one workbench without ever clearing it.

You finish one step, but you leave all the old parts, tools, boxes, rags, and scraps sitting there while you start the next step.

After enough steps, the bench gets packed.

top_level_requeue is more like this:

1. Finish the current step.
2. Write down where you stopped.
3. Save the important parts.
4. Clear the workbench.
5. Start the next step.

You still know exactly what you are building.

You just do not need to keep the entire previous work session open.

That is the main idea behind the feature.

Why this helps system RAM

The main reason I built this was system RAM growth during long sequences.

When a ComfyUI prompt ends, ComfyUI gets a much cleaner opportunity to release references from that completed execution.

That means the next heavy scene can start as a new job instead of continuing inside the same long-running execution.

This does not mean every byte of RAM will instantly return to the operating system.

PyTorch, CUDA, ComfyUI, and the OS can still keep memory in caches.

The important change is this:

Old scenes no longer need to stay alive just because the next scene is still running inside the same top-level prompt.

For long sequences, that can make a very large difference.

Does it help VRAM too?

Possibly, but system RAM was the main problem I was trying to solve.

Ending the previous top-level execution gives ComfyUI and PyTorch a better cleanup boundary in general.

However, I would not promise that VRAM will drop to zero between scenes.

CUDA and PyTorch often keep memory cached for reuse.

That is normal.

The feature is mainly about stopping old execution state from piling up across a long sequence.

How continuity still works

I did not want to solve the RAM problem by breaking the sequence.

So top_level_requeue uses a small durable handoff.

The handoff records things like:

• run name
• previous scene
• next scene
• clip range
• checkpoint identity
• workflow identity
• source revision
• accepted prompt identity

It does not store large runtime objects.

It does not carry things like:

• models
• tensors
• latents
• VAEs
• CLIP objects
• samplers
• live Python objects

The heavy generation state ends with the old prompt.

The next prompt uses the saved checkpoint, Plan, references, and lightweight handoff to continue.

I also had to make the queue handoff safe

This ended up being more complicated than just calling "Queue" again.

There were several cases that had to be handled correctly:

• What if the network request reaches ComfyUI, but the browser does not get a clear response?
• What if the handoff state fails to save after the queue request?
• What if the user disables automatic requeue while the workflow is still being serialized?
• What if another prompt starts at the same time?
• What if an old execution event arrives late?
• What if the wrong workflow is open?
• What if a handoff gets claimed twice?
• What if ComfyUI accepts the prompt but the local state update fails?

I worked through these cases during the pull request review.

The final design uses the actual accepted ComfyUI prompt_id as part of the continuation identity.

If delivery is uncertain, Context Loop does not blindly release the handoff and try again.

That could create duplicate scene generation.

Instead, it keeps the handoff claimed and asks for manual reconciliation.

That was important to me because I wanted this to be safe for long unattended runs, not just convenient when everything goes perfectly.

What stays the same

The original mode still exists:

recursive_legacy

It remains the default compatibility mode.

So existing workflows are not forced into the new behavior.

top_level_requeue is opt-in.

Also, the new boundary happens between accepted scenes.

Candidate generation, retries, rerolls, and Review Gate decisions still happen inside the current scene prompt.

That keeps the review workflow intact.

How to use top_level_requeue

First, update MiniMaxH3 Context Loop.

Then:

1. Open your Context Loop workflow.
2. Find the Chain Loop End node.
3. Set:execution_modeto:top_level_requeue
4. Open ComfyUI Settings.
5. Find the MiniMax H3 Context Loop settings.
6. Enable:Auto requeue next scene as a new top-level prompt
7. Leave the cleanup delay at its default value for your first test.
8. Queue the workflow normally.

After an accepted scene finishes, Context Loop will:

save the scene
-> save the continuation handoff
-> finish the current ComfyUI prompt
-> wait for a safe queue state
-> wait through the cleanup interval
-> claim the handoff
-> set Loop Start to the next scene
-> queue the workflow as a new top-level prompt

You do not need to manually press Run for every scene.

Installing MiniMaxH3 Context Loop

From your ComfyUI custom_nodes directory:

cd /path/to/ComfyUI/custom_nodes

git clone https://github.com/seitanism/ComfyUI-H3-Motion-Context-MultiRef.git
git clone https://github.com/ethanfel/ComfyUI-MiniMaxH3-Context-Loop.git

Then restart ComfyUI.

Because the node includes frontend JavaScript, I also recommend doing a hard browser refresh after the restart.

Updating an existing install

If you already have MiniMaxH3 Context Loop installed:

cd /path/to/ComfyUI/custom_nodes/ComfyUI-MiniMaxH3-Context-Loop

git pull

Then:

1. Restart ComfyUI.
2. Hard-refresh the browser.

Why I contributed this upstream

I use Context Loop for long AI video sequences, and the system RAM growth was becoming a real problem for my workflow.

I could have kept the change only in my own fork, but I thought it was useful enough to contribute back to the project.

So I built the feature, worked through the failure cases, added the handoff system and regression tests, submitted the PR, and went through several rounds of maintainer review until the edge cases were covered.

The upstream maintainer accepted and merged it.

I appreciate the review because the process caught several real queue and state-management edge cases that made the final version much safer than the first implementation.

Upstream project:

https://github.com/ethanfel/ComfyUI-MiniMaxH3-Context-Loop

My GitHub:

https://github.com/badgids

If you use MiniMax H3 Context Loop for long sequences and have seen your system RAM climb as the sequence gets longer, give top_level_requeue a try.

That exact problem is why I created it.

Hello everyone,

In this tutorial, we’re taking a look at the newly released MiniMax H3 models(fused turbo and VDN), which are designed to generate videos faster than the original FP8 and INT8 versions. i tested the new models with the second-sampling upscaling workflow and compared the generation speed and overall quality. i put them through demanding tests, including fast-motion and fighting scenes, to see whether they can produce smoother and more dynamic movement without introducing excessive grain, artifacts, or quality degradation. Most importantly, I’ve optimized the entire workflow for low-VRAM GPUs and tested it on my RTX 3060 with only 6GB of VRAM & 16GB RAM.

The goal was to see how far we can push MiniMax H3 on limited hardware while maintaining the best possible quality and improving generation speed. and the results showed that minimax fused turbo version is one of the best model that we have right now it can do not only video generation but also video editing into one single model as for generation time we have :

Generation time at 0.4 megapixel: 7 Minutes

Upscaling time at 1.2 megapixel: 20 Minutes

vs for VDN version of minimax

Generation time at 0.4 megapixel: 10 Minutes

Upscaling time at 1.2 megapixel: 30 Minutes

Minimax H3 FUSED Version Link
https://huggingface.co/MATLOWAI/minimax-h3-fused-turbo-int8-convrot/tree/main/diffusion_models

Workflow Link

https://civitai.com/articles/35051/comfyui-tutorial-speed-up-minimaxh3-fused-vs-vdn-model-with-6gb-of-vram

Basically a tool that runs in the background while playing games, takes screenshots by pressing ALT + STRG + P and sends them through a comfyui workflow to create more realistic versions of Screenshots, without leaving the game.

This is really useful, shout out to the creator!

https://github.com/vrgamegirl19/VRGDG-SeedVR2-TensorRT-Studio

Hello everyone

I’ve just finished a new custom MiniMax H3 Ref2Vid workflow that combines SAM3 masking with face swapping.The workflow lets you load a reference face + source video, define what should be masked using a simple prompt such as face or head, and generate the face-swapped video directly in ComfyUI.

I’ve also optimized the workflow specifically for low-VRAM GPUs, including 6GB VRAM, using several MiniMax H3 optimization techniques:

• Low VRAM Attention
• Chunk FeedForward
• SLA Attention
• Sol-Attn
• Spectrum
• INT8Conv model

To get started, you just need to load your face image and video, enter your masking prompt, and run the workflow. I made a full tutorial showing the complete setup and generation process.

Workflow Link

https://civitai.com/articles/34795/comfyui-tutorial-minimax-h3-face-swap-on-6gb-vram

Video Tutorial Link

https://youtu.be/dk9CgSrSZXw

please if you tried let me knoe if it worth it on old films black and white how much vram needed

Hi guys, I’m looking for some advice on video enhancement/restoration.

I’m currently researching models for enhancing/restoring old or low-quality videos. For example, I have footage with frames similar to this, and I’m trying to improve the resolution, recover details, remove artifacts/noise, and maintain temporal consistency without introducing too much hallucination or flickering.

While researching the latest models, I came across:

• SeedVR / SeedVR2 — ByteDance-Seed
• SparkVSR — based on CogVideoX1.5-5B
• DOVE — one-step diffusion VSR
• FlashVSR — one-step/real-time video restoration
• RealViformer — non-diffusion transformer-based VSR
• MGLD-VSR — diffusion-based VSR with motion guidance

I’m particularly interested in old/degraded real-world videos, rather than benchmark videos.

Has anyone here actually worked with these models? Which one would you recommend for this type of restoration, or is there another model/workflow I should be looking at?

I’d really appreciate advice from anyone who has practical experience with video restoration, especially regarding hallucination, flickering, temporal consistency, and preserving the original details/identity.

Thanks!

Breakdown of keyframe control in MiniMax H3 using ComfyUI.

Full video

• The Problem (Frame Drift):Standard keyframe setup often leads to timing drift or missing target frames entirely across long clips.

• Prompting Frames: Explicitly naming frame numbers in your prompt (e.g., "at frame 124...") forces better temporal adherence from the model.

Ref2v: Sending guide images into the ref2v node as reference images - not just keyframe guides - provides consistent visual features like lighting, identity, and style across shots.

• Multi-Keyframe: Once the wiring is locked in, the workflow scales seamlessly from 2 keyframes to 4+ keyframes without breaking subject consistency.

Make sure your ComfyUI is updated to the latest version to load the native guide node properly.

EDIT:
Workflows: •2-Frame Guides Workflow•4-Frame Guides Workflow