<Extend> feature limited to whatever the Video Frames are set to in the UI?

[obfuscate27]

Trying to understand if this is an issue I’m having or just how it works but I’m trying to use the extend:81 feature using wan2.2 but it seems no matter what I do the video will not extend the time past whatever I set in the UI settings for Video Frames.

So if I set the video frames in the UI to be 33 for example, without extending it in the prompt field, I’ll get a video that lasts 2 seconds. Makes sense.

However if I keep the same video frames set in the UI but then add extend:81 to the prompt field with further prompts for it to generate after the initial 33 frames I don’t end up with a 7 second video (initial 33 frames + the extra 81 frames = 7 seconds worth of video) but a 4 second video instead, double the UI set video frames.

What’s frustrating is I can see it generating the full extended frames in the preview window but it doesn’t want to save it and instead seems to ignore how many frames it should extend by in the prompt field and gets limited to just double whatever the UI video frames are.

I know the extend setting is working because if I set the UI video frames to 81 and then add extend:33 to the prompt field I’ll get a 7 second video because the extend frames are less than double the UI video frames. But I can’t seem to get to let me do it the other way and give me 81 extra frames at the end of the video when the UI video frames are set to 33.

Is this normal and a quirk of the extend feature or am I doing something wrong?

[willhsmit]

In the extend workflow in WorkflowGeneratorSteps, I see code:

string cutNode = g.CreateNode("ImageFromBatch", new JObject()
{
["image"] = g.FinalImageOut,
["batch_index"] = frameExtendOverlap,
["length"] = frameCount
});

that appears to be cutting the extend block down to 'frameCount' instead of 'frames'. I'm not sure if the intent of this node is just to cut out the initial overlapping frames and the capping at the end is unintentional, or if it's there for another reason.

If it's unintentional, fixing it to use 'frames' would be a bit tricky, since frames is nullable and has a different default for every model. It'd probably either need another SwarmCountFrames+SwarmIntAdd. (or hackily, provide length = max_int and rely on the clamping in ImageFromBatch).

[mcmonkey4eva]

Oh, yeah, right issue location, wrong analysis. I pushed a commit to just grab the frames var there. That was in fact just a simple case of wrong var in use, frames is non-null and has a reliable exact value in this context.