DiT-Extrapolation: RIFLEx and UltraViCo for long video generation

What length extrapolation means for a video model

The repository provides the official implementation of three related works: RIFLEx, published at ICML 2025, UltraViCo, published at ICLR 2026, and UltraImage, each of which achieve diffusion transformer extrapolation for long video generation and high resolution image generation in a plug-and-play way.

The problem being solved is specific to diffusion transformers. A video diffusion transformer is trained on clips of a fixed length, and the positional encoding it uses, RoPE, has an intrinsic frequency structure that is tuned to that length. Generate beyond it and the model produces artefacts, usually repetition or drift, because the position encoding is being asked to cover a range it was never trained on.

The plug-and-play part is the headline. The README states that RIFLEx only adds a single line of code on the original 1D RoPE, and that is literally what the code section shows: a modified copy of the rotary position embedding function with one assignment changed.

So this is not a new model, and it is not a fine-tuning recipe. It is a targeted intervention in the positional encoding at inference time, which is why it can be applied to a model someone else trained and released, and why the repository ships fine-tuned checkpoints alongside the code for the cases where a better base model was needed.

The authors are Min Zhao, Guande He, Yixiao Chen, Hongzhou Zhu, Chongxuan Li and Jun Zhu at Tsinghua University. The project page is at riflex-video.github.io, the licence is Apache-2.0, the primary language is Python, and the last push to the repository was on 2026-06-06 with no GitHub releases, so you track the branches rather than a tag.

RIFLEx changes one assignment in the RoPE function

The code section of the README is the whole method in one block, and it is worth reading line by line.

def get_1d_rotary_pos_embed_riflex(
    dim: int,
    pos: Union[np.ndarray, int],
    theta: float = 10000.0,
    k: Optional[int] = None,
    L_test: Optional[int] = None,
):
    '''
        k: the index for the intrinsic frequency in RoPE
        L_test: the number of frames for inference
    '''
    
    assert dim % 2 == 0
    if isinstance(pos, int):
        pos = torch.arange(pos)
    if isinstance(pos, np.ndarray):
        pos = torch.from_numpy(pos)
    freqs = 1.0 / (theta ** (torch.arange(0, dim, 2, device=pos.device)[: (dim // 2)].float() / dim)) 

    # === RIFLEx modification start ===
    # Reduce intrinsic frequency to stay within a single period after extrapolation (Eq.(8)).
    # Empirical observations show that a few videos may exhibit repetition in the tail frames.
    # To be conservative, we multiply 0.9 to keep extrapolated length below 90% of a period. 
    freqs[k-1] = 0.9 * 2 * torch.pi / L_test
    # === RIFLEx modification end ===

    freqs = torch.outer(pos, freqs)  
    freqs_cos = freqs.cos().repeat_interleave(2, dim=1).float()  
    freqs_sin = freqs.sin().repeat_interleave(2, dim=1).float()  
    return freqs_cos, freqs_sin

Two parameters carry the method. k is the index for the intrinsic frequency in RoPE, and L_test is the number of frames for inference. The single modification overwrites one entry of the frequency vector, the one at index k-1, setting it to 0.9 times 2 pi divided by L_test.

The comment explains the reasoning: reducing the intrinsic frequency keeps the extrapolated positions within a single period of the rotary embedding, so the model never sees a position it was not trained to interpret. The paper reference is to equation 8.

The companion file riflex_utils.py shows how to identify the intrinsic frequency in a RoPE based pre-trained diffusion transformer in the first place, which is the step that makes the technique usable on a model you did not train, since the index k is a property of the specific checkpoint.

Everything else in the function is the stock 1D rotary embedding copied from diffusers, with the modification bracketed by comments so it can be diffed against the original.

The 0.9 factor buys length at the cost of tail repetition

The comment inside the modification is unusually honest, and it is the single most important thing to understand before using this code.

It says that empirical observations show that a few videos may exhibit repetition in the tail frames, and that to be conservative the implementation multiplies by 0.9 to keep the extrapolated length below 90 percent of a period.

So the trade-off is explicit. Reducing the intrinsic frequency buys you more frames, and the cost is paid in the tail of the generated clip, where the model can start looping. The 0.9 factor is a safety margin against that, not a free parameter. Push the extrapolated length further and the artefact gets worse.

The period is the unit of measure here, and it depends on the frequency you set, which in turn depends on L_test, the number of frames you asked for. That is a slightly unusual coupling: the target length is an input to the frequency, so asking for a longer video changes the encoding rather than just extending it.

For a user, the practical workflow is therefore two steps. You decide the frame count you want, and the method then rewrites the frequency so that those frames fall inside a period the model can handle. The RIFLEx inference command exposes this directly, with the k and N_k arguments alongside a num_frames argument, and the README shows a training-free invocation on HunyuanVideo using k of 4, N_k of 50 and 261 frames.

Whether 261 frames is longer than what the base model was trained on is the point of the exercise, and the supported models table in the README gives the headline results: HunyuanVideo goes from 5 seconds to 11 seconds, and CogVideoX-5B from 6 seconds to 12 seconds.

The word training-free in the README heading matters as well, since it distinguishes the two routes to the same result. One route changes only the positional encoding at inference, and the other uses a fine-tuned checkpoint, and the project releases both, with the fine-tuned models published on Hugging Face.

One repository, six branches, three different methods

The branching model in this repository is unusual and easy to get wrong, so it is worth mapping out.

The README states that the repository hosts RIFLEx and UltraViCo on separate branches. RIFLEx lives on main, which covers HunyuanVideo and CogVideoX with the diffusers implementations, and on a multi-gpu branch that adds multi-GPU inference for HunyuanVideo.

UltraViCo has its own two branches, ultra-wan for Wan2.1 and ultra-hunyuan for HunyuanVideo. UltraImage has two more, ultra-flux for Flux and ultra-qwenimage for Qwen-Image.

So the six branches are a matrix of method by base model, and picking the wrong one gives you a method that does not match your checkpoint. The base models named in the branches are among the open video and image models that people actually run: HunyuanVideo, CogVideoX, Wan2.1, Flux and Qwen-Image.

The root of the repository also carries the shared pieces. There are two entry scripts, hunyuanvideo.py and cogvideox.py, the riflex_utils.py helper for identifying the intrinsic frequency, a requirements.txt, and an assets directory holding the example prompts, including free_hunyuan.txt and finetune_hunyuan.txt, with the README noting that the prompts on the project page are found there.

The newer methods have their own arXiv entries listed in the README, UltraViCo as 2511.20123 and UltraImage as 2512.04504, and UltraViCo is described as achieving the same kind of extrapolation for UltraViCo supported models. The timeline in the news section gives a clear order: the RIFLEx paper, code and checkpoints in February 2025, CogVideoX code and fine-tuned weights in March 2025, integration into the official HunyuanVideo-I2V repository in March 2025, acceptance at ICML 2025 in May 2025, and UltraViCo accepted at ICLR 2026 in January 2026.

Getting a first clip on a single GPU

The quick start section is aimed at someone with a consumer GPU, and the install is a conda environment with a pinned requirements file.

conda create -n riflex python=3.10
pip install -r requirements.txt
pip install -U bitsandbytes

The requirements file is where the pinning lives, and the pins are exact for the core libraries.

diffusers==0.32.1
accelerate>=1.1.1
transformers==4.46.2
numpy==1.26.0
torch==2.5.1
torchvision>=0.20.0

The rest of the file adds sentencepiece, imageio, imageio-ffmpeg, openai, moviepy, scikit-video and pydantic.

Two things to notice. diffusers is pinned to an exact version, and the method depends on the exact rotary embedding implementation in that release, so a newer diffusers is not automatically better. And the torch pin is 2.5.1, which matters because the CUDA and ROCm builds of torch are chosen separately and the README does not tell you which to use.

The README is also candid about the single GPU path. For single GPU inference with HunyuanVideo, diffusers use DiffusersBitsAndBytesConfig to save memory, which may affect performance, and to produce the demo on the project page you are referred to the multi-GPU section. In other words, the single GPU path is the one to try first, and the numbers on the project page came from the multi-GPU path.

For the RIFLEx inference itself, the README gives a training-free invocation of hunyuanvideo.py with the k, N_k and num_frames arguments and a prompt. Prompts for every model are listed in assets/prompts, and the example prompt in the README is a tabby cat in a garden.

If you want multi-GPU, that is the multi-gpu branch, and it is where the project page results were produced.

Adoption beyond the paper, and the numbers to check

The news section is the best evidence about whether this technique survives contact with other people's codebases, and the entries are all integrations rather than claims.

RIFLEx was integrated into the official HunyuanVideo-I2V repository in March 2025, which means the technique was accepted upstream by the team that maintains the model. It is also supported in HunyuanVideoGP, where the README states that a 10.5 second video at 1280x720 can be generated on an RTX 4090, and in ComfyUI-HunyuanVideoWrapper by KiJai, which is the ComfyUI node wrapper many people use for this model family.

Those three integrations matter more than the paper acceptance, because each one required someone else to port the change. The HunyuanVideoGP entry is also the only concrete hardware statement in the document, and it is specific enough to be useful: a 4090, 10.5 seconds, 720p.

For a model named on the supported list, the table gives the extrapolation reached, and the two entries are HunyuanVideo from 5 seconds to 11 seconds and CogVideoX-5B from 6 seconds to 12 seconds, with example result animations in the assets directory.

What is missing is equally informative. The table is headed as the state of the art video diffusion transformers that RIFLEx has been applied to, it says the authors are continuously working to support more models, and it invites suggestions. There is no table of quality metrics, no FID or CLIP score comparison, and no ablation over the k parameter. The extension factor is stated as a fact per model, not as a quality curve.

So if you are evaluating this, the check list is: find the branch for your checkpoint, reproduce the example prompt on your own hardware, and look at the tail frames of the output, because that is exactly where the README says the artefact appears.

Editorial conclusion

DiT-Extrapolation suits a research group with a GPU and an existing open video diffusion transformer that stops at five or six seconds, since RIFLEx changes one line of the positional embedding code and requires no retraining, and the UltraViCo and UltraImage branches extend the same idea to Wan2.1, HunyuanVideo, Flux and Qwen-Image. It does not suit a team that wants a production video pipeline, because the repository is a paper implementation with pinned dependencies and no released versions, and it does not suit a project that needs guaranteed quality at the extrapolated length, since the README itself notes that a few videos may show repetition in the tail frames. Before you rely on it, check the branch for your model, since the six branches hold different methods, and pin the diffusers, torch and transformers versions from requirements.txt, because the method depends on the exact RoPE implementation in diffusers 0.32.1.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. thu-ml/DiT-Extrapolation on GitHub