[hiroki-abe-58]

EdenLive AR keeps every decoded chunk on the GPU until the end of a request, then concatenates the chunks there, so GPU memory grows with the video length. On a 32 GB card at 1280×704, a 30 s clip fit in my runs. A 45 s clip ran out of memory at the end of the request, while the MP4 was being saved.

This PR adds an opt-in ar_config key, "decode_to_cpu": true, which copies each decoded chunk to host memory as soon as it is decoded. With it, GPU memory no longer depends on the clip length. The default is unchanged. With the option on, chunk callbacks receive CPU tensors. The README (EN/ZH) documents the key next to T5_CPU_OFFLOAD.

Measurements

Setup:

• RTX 5090 (32 GB), Windows 11, torch 2.14.1+cu130, process capped at 95% of the card.
• Wan2.2 5B AR, 1280×704, 24 FPS, 4 steps, INT8 ConvRot DiT and proxy encoder, SageAttention2, Triton LayerNorm/modulate, synchronous LightTAE streaming decode, T5 on the CPU.
• These are the 5090 preset's settings with the kernels that have no Windows build replaced.
• Input: the cryo-crossing sample. "45 s" is that clip followed by its frames in reverse (1077 frames).

clip	decode_to_cpu	result	peak allocated / reserved GiB	generation FPS	MP4 save s	peak process private GiB
30 s (717 frames)	off	ok	25.40 / 29.27	17.74	5.3	46.3
30 s (717 frames)	on	ok	20.57 / 21.35	17.20	8.0	54.6
45 s (1077 frames)	off	OOM in save_to_video after all 90 chunks (tried to allocate 5.42 GiB)	25.98 / 27.94	-	-	44.9
45 s (1077 frames)	on	ok	20.60 / 21.49	17.31	11.1	63.0

Output is unchanged:

• 30 s: the two MP4 files are byte-identical (717 of 717 frames).
• 5 s: the frames captured as float tensors after wan_vae_to_comfy (the --return_result_tensor path) are torch.equal with and without the option.

Cost:

• About 3% generation FPS, from the per-chunk device-to-host copy in the synchronous decode path.
• The final conversion and MP4 save run on the CPU.
• Host memory grows by the size of the decoded video.

Async decode ("async_vae_decode": true, where the copy runs on the decode worker thread): I checked it on the 5 s clip only.

• It is identical with and without decode_to_cpu, and identical to the synchronous decode: the MP4s are byte-identical.
• Peak memory was 21.07 / 22.44 GiB without the option and 20.52 / 21.78 GiB with it.

🤖 Generated with Claude Code