I'm not sure if what I'm about to tell you is correct, but I'll share what I've learned from my experience.

First, things like Sage Attention affect the processing speed of the video generation process, not directly affect the quality of the video.

Incidentally, I'm a Windows user, but I can install Sage Attention, so the idea that it's only usable on Linux is outdated information.

Video quality varies greatly depending on the type of model, the custom nodes used, prompts, LORA, etc., so it's impossible to generalize, but at least bypassing Sage Attention only increases the time it takes to complete the generation; it doesn't significantly affect the quality. In fact, these techniques can be said to sacrifice quality for speed.

Therefore, the creation of videos that seem completely unintended, as you mentioned, is due to other factors. However, there are so many possibilities that it's extremely difficult to pinpoint one here.

When asking someone a question, be polite.

Well, even if you ask me politely, I still don't know what kind of error it is.

@e7lew It seems the generated data isn't fitting into the RAM. My understanding is that the RTX 3090's 24GB of VRAM and 32GB of RAM should be sufficient, but with the 30 series, there might be issues with data offloading or other factors.

Depending on the video length and resolution, replacing "VAE Decode" with "VAE Decode (Tiled)" might allow for splitting and avoid the "Killed" message.

Try going into the subgraphs of each section and replacing "VAE Decode" with "VAE Decode (Tiled)".

@e7lew This workflow uses the "~st video" node, which corresponds to the last number of sections being generated, and enables it in the fast bypass node. All other Video nodes are disabled. This should output everything in mp4 format.

If it doesn't, modify all Video sections to H264/mp4.

This could be a troublesome error.

It might be related to version inconsistencies in PyTorch or other components.

A DLL is a high-speed processing file used by Python, and it seems to be saying that it couldn't find a component called "_fused".

However, ComfyUI installs a large number of programs, so it's difficult to pinpoint exactly where the incompatibility is occurring.

Ideally, you should put the log file of the entire generation where the ComfyUI error occurred into Gemini or chatGPT and ask for solutions, but in my experience, this only solves the problem about half the time.

If similar errors occur in other workflows, a complete clean install of ComfyUI, including PyTorch, might be necessary.

However, I'm sorry, but this error is too difficult for me to understand, so I might be saying something incorrect.

Lately, I've been using the "Wai Realism IL" model from Illustrious. I've posted some examples in the "Image" section of my profile.

Like you, I prefer the Painter I2V version. However, it is possible to combine videos in a workflow similar to the SVI version. In fact, I've tried generating it three times. But even with the current two-times method, the transitions between videos are problematic; doing it three times results in a video that's frankly incomprehensible.

In short, to create long videos, the SVI version is currently the only option. The great thing about SVI is that it seamlessly and naturally connects video segments while maintaining character consistency. However, as you've also noticed, the motion is very poor.

Therefore, many people who use the generator combine the cut videos using other video editing software. However, in this case, you need to ensure that the same character images are used throughout.

In other words, achieving excellent motion in a long, single-shot video is currently difficult.

Ultimately, it's a choice between length or motion.

If no changes are made, I think it will go into ComfyUI/output/video.

@Mr_mr1 It seems the "save_output" setting in the "Video Combine" node isn't set to "true". Check the "~video" subgraph for each number and make sure the "save_output" setting in the "Video Combine" node is set to "true". If it's "false", the video won't be saved at all.

@Mr_mr1 Something unusual is happening to you. However, in most cases, it's because your settings are fundamentally wrong.

Please try various things, including other workflows.

If the problem persists, please provide more specific details, including the situation.

You don't need to waste time here. Do what you want to do, the way you want to do it.

This is what's known as OOM (Out of Memory). The OS is forcibly "Killing" (terminating) the process without displaying an error log because it doesn't have enough system memory (RAM).

The simplest solution is to replace the "VAE Decode" node with "VAE Decode (Tiled)".

Go into the subgraphs of each section and try replacing the nodes. "VAE Decode (Tiled)" splits the VAE processing, making it less likely to terminate prematurely. Please try it.

That's true.

The main models and LORA are listed on this page and in the annotations of my videos, right?

@Greedy_Pineapple9399 I don't really understand what you're saying, and I don't understand the situation, so I can't help you.

Replacing Lightx2v LORA is possible, but finding the appropriate strength will be extremely difficult.

I think the only LORA that works well with a strength of "1" is probably the one I'm using.

There are countless suggested methods for configuring Lightx2v LORA. A typical example is the 3-Sampler setup, which also includes methods that bypass Lightx2v LORA and use a separate Sampler.

Therefore, I think there are LORAs that are incompatible with my 2-Sampler method. So, I think it will be a difficult process.

I don't know much about SVI LORA.

@Nothingtosatisfy I think various base models should work. For fp16, you should be able to fix it by changing the text encoder.

The noise that looks like sea surface is probably from Lightx2v Lora.

I haven't specifically measured the generation time with or without sage attention, and it also varies depending on the resolution and video length, so I can't give you a definitive answer. However, it's unlikely that sage attention is ineffective in this particular workflow.

In fact, it seems that sage attention isn't functioning, but I don't know why.

I'm sorry, but I don't even know much about pagefile.sys, so I have absolutely no idea.

You may run out of memory.

Please implement general memory shortage countermeasures. For example, you could add a node to refresh VRAM after the VAE Decode node, or replace the VAE Decode node with a (Tiled) version. There are other methods, but you'll have to figure them out yourself. I won't teach you how.

I think the problem lies in the timing of the video transitions, so the best approach is to generate it multiple times until you get it right.

I almost never get it to work on the first try.

By the way, I don't know what base model you're using, but consistency varies depending on the model. I won't mention it here, but there are some models that change frequently, so I wanted to let you know.

The prompts should be adjusted precisely depending on the reference image.

I previously watched a video from someone who reported that it wasn't working for them, but the composition of their reference image was quite different from mine. It's no wonder it didn't work with the same prompts as mine. However, SVIs are inherently difficult to implement. I've only posted the ones that worked after many failures, so repeated attempts are probably important.

I forgot to mention, LORA is also important. Some versions work well with SVI, while others don't. Try different ones.

I'm not sure which video you're referring to, but try setting all six prompts to different values, specifying different LORA values, and specifying different timestamps. This should allow for more flexible and complex movements.

@tuskoki this one.

https://civitai.com/models/2031069/wan-22-i2v-pov-body-cumshot-and-pullout?modelVersionId=2298673

@qqianyu

 https://civitai.red/models/1913617/wan22-breast-play-i2v?modelVersionId=2448070

Didn't you notice that I specifically displayed LORA in the video? You should look at things more carefully. I'm not exactly beginner-friendly, because I learned through trial and error, drawing on the many helpful resources from more experienced users. You should put in more effort. Don't expect me to answer beginner questions like this again.

Please enable this only for the sections where the video will be played.

There are multiple options so that they can be easily bypassed.

I apologize, but I'm not familiar with the details of your point.

However, as far as I understand, ComfyUI currently processes data in roughly the same amount of time whether using VRAM or DRAM.

@tedbiv I have only tried it with sage attention set to "auto" and patch torch setting set to "true".

I suspect the settings (weights, high/low) of your LightX2V Lora model are incorrect. Or perhaps you're adding another LightX2V Lora model to a base model that already has one merged into it.

What do you think?

@homuragremory594 I've shortened and changed the name of LORA. DR34ML4Y is the V2 of the most popular one.

By the way, that pinkish noise is almost always caused by inconsistencies in the model settings. It often happens to me when I first try a new workflow. A quick check reveals a setting error, which is easily fixed.

For example, the wrong type of SVI LORA, incorrect weight values, or wrong SD3 shift values.

@solder912219 That's great! Have fun, by kenpechi. lol

Please translate this into English.

@edward18881973 Look inside all the "~video" subgraphs. For some reason, the "format" of the "video combine" node is set to "ffmpeg-gif". Please change this to the more common "h264-mp4".

@edward18881973 Have you checked all the video combine nodes? There are many of them in this workflow.

If that's still not the problem, then I don't think the error is related to this workflow, since I don't have ffmpeg installed. I can't think of any other possible causes besides the ones mentioned above.

In this workflow, the length is specified in seconds, not frames.

Enter "5" seconds in the "Second" field in the "Input" area. The number of frames is automatically calculated by multiplying this number of seconds by the "fps" value.

@TheSemenDemon That's right, it's the most popular "(WAN 2.2 experimental) WAN General NSFW model".

It's not zero, but I'm not particularly interested at the moment.

Have you implemented Sage Attention? While it's highly likely the error is related to the Sage Attention node, I can't say for sure. Have you tried disabling it?

I don't use FaceLORA. However, I don't publicly share my face generation method. I think it's best to experiment and find what works for you.

Of course, it's possible.

@GentlePudding I wouldn't post here specifically for that purpose, but for example, my painterI2V workflow also has a node for extracting the final image, so you just connect that after the VAE Decode node and then connect it to the Save Image node.

Many other experienced users have incorporated the same technique into their workflows, so I highly recommend trying to build one yourself.

Unlike A1111, ComfyUI is tolerant of Python versions and works fine with versions 3.10 to 3.13. Incidentally, I'm using 3.12.10. The LORA key error occurs because you're using Lightx2V Lora for WAN2.1, but this is normal. Don't worry about it.

In short, the cause of your problem is something else, but it's too vague to explain. Please describe the situation in more detail.

The error with ComfyUI could be caused by using an outdated version of a custom node.

All I can say is to update all custom nodes to the latest version. I don't know anything else.

I understand that this workflow is prone to the kind of problems you've pointed out.

However, I re-checked for the problems you mentioned, but I couldn't find any factors causing problems with the 6th and 8th steps.

@MarcanOlsson The node connection of the workflow may have changed from its default state. Does the same problem occur if you download this workflow again?

@MarcanOlsson Thank you! I figured out the problem! The 8th prompt wasn't being reflected, and it was loading the 6th prompt instead. I'll post the corrected version right away.

I don't use any special workflows. I use very common workflows.

However, I create images using two workflows. The images posted on my profile are generated using one of these workflows.

After that, I generate them again using another workflow. In other words, it's image to image generation. However, I don't disclose how I do that.

There are two main reasons. First, the image generation process is a unique part of my videos, so disclosing it wouldn't be interesting. Second, disclosing it would require explaining the process, which is quite troublesome. It's not difficult, but it's a tedious process.

I disclose over 90% of my generation process, but wouldn't it be more appealing if there was a little bit of mystery?

In the case of I2V, because it starts from a reference image, it's almost always impossible to start from a moving state; it has to start from a stationary state. Even if you use a 5-frame overlap with SVI, if it takes more than 5 frames to start from a stationary state, it will appear as if it's stopped.

I think this is a fundamental mechanism of wan2.2 I2V, so it's difficult to solve.

In short, if the action starting from the reference image is kept within 5 frames, it shouldn't be noticeable.

In my generated videos, the blow job exceeds 5 frames, so there's a brief pause where the penis is removed from the mouth, but the sex scene is kept within 5 frames, so it's not very noticeable.

I think it's necessary to compose video scenes taking these realities into account.