--add_mask default differs between inference scripts, and infer_video.py silently truncates input #1

Thanks for releasing the code and weights — we've had it running end to end on a
single RTX 3090 and the still-image results are genuinely impressive.

Three things we hit while doing that. The first two are small consistency bugs;
the third is a request.

1. --add_mask defaults differently in infer_long_video.py

The exposure masks are conditioning the model, so turning them off changes the
result substantially — but whether they're on depends on which script you run:

So the obvious first command for a long clip —

python infer_long_video.py --input_path frames/ --output_dir out/

— runs without exposure masks, while the equivalent single-image and short-video
commands run with them. Nothing warns you, and the output is plausible enough
that it isn't obviously wrong.

The docstring at L17 does show --add_mask in its usage example, so I think the
intent is for it to be on and the default is just an oversight.

Suggested fix: default=True at L333 to match infer_video.py, or document
it as intentionally different.

2. infer_video.py silently truncates a video to --num_frames

load_frames() at L120:

n = min(len(vd), num_frames)
return [vd[i] for i in range(n)]

With --num_frames defaulting to 33 (L223) and no windowing loop in this script,
pointing it at any video longer than 33 frames processes only the first 33 and
exits normally. We fed it a 97-frame clip and got 33 frames back with no error
and no warning — it looked like a successful run.

infer_long_video.py is clearly the right entry point for longer input, but
nothing in infer_video.py says so at runtime.

Suggested fix: warn when len(vd) > num_frames, e.g.

if len(vd) > num_frames:
    print(f"[warn] input has {len(vd)} frames; processing the first {num_frames}. "
          f"Use infer_long_video.py for longer clips.")

3. Request: expose num_persistent_param_in_dit on the inference scripts

enable_vram_management() is called with only vae_dtype:

• infer_image.py:232, infer_video.py:297, infer_long_video.py:431, infer_hdri.py:161

With all 14B DiT parameters resident, none of the scripts fit a 24 GB card — a
single 1280×720 image OOMs at ~23.4 GB during attention. Passing
num_persistent_param_in_dit=0 to stream the weights makes single images and
HDRIs work fine on a 3090 (peak ~22.4 GB, ~40 min for 50 steps at 1280×720).

Exposing it as a CLI argument would let consumer-GPU users run the image and
HDRI paths without patching. We're doing this locally as:

_npp = os.environ.get("NUM_PERSISTENT_PARAM_IN_DIT")
pipe.enable_vram_management(
    vae_dtype=torch.float32,
    num_persistent_param_in_dit=(None if _npp in (None, "", "none") else int(_npp)),
)

Happy to open a PR for any of these if useful.

Environment

• RTX 3090 24 GB, driver / CUDA via PyTorch 2.x, Python 3.10
• Wan-AI/Wan2.1-VACE-14B + DiffHDR.safetensors
• 50 steps, cfg_scale default, --add_mask --srgb_to_lg

Note on video at 24 GB, in case it's useful to others

For anyone else trying this on a consumer card: video doesn't fit even with
weight streaming. --window_size 33 OOMs after the first window, and reducing
either the window or the resolution to make it fit costs most of the
reconstruction — on identical frames we measured 17–25× less dynamic range at
--window_size 17, and 22–35× less at 848×480 with the window left at 33. The
trained configuration appears to be load-bearing in both dimensions. Stills and
HDRIs are fine.