MagicTime: a time-lapse video simulator whose repository stops at inference

What MagicTime simulates: metamorphic change across a prompt

MagicTime is not a general text-to-video model. Its repository description reads [TPAMI 2025] MagicTime: Time-lapse Video Generation Models as Metamorphic Simulators, the paper behind it is arXiv 2404.05014, and the news block records TPAMI acceptance on 2025.03.28 followed by an updated technical report on 2025.04.08. The word that carries the weight is metamorphic. A time-lapse prompt describes a transformation rather than a place, so the model has to render change itself: a structure going up, weather moving through, a surface wearing away.

That target is narrower than it sounds, and narrowness is the point. A general video model renders a scene; MagicTime renders a scene plus its trajectory, a harder constraint to satisfy and an easier one to test. The README calls the repository the official implementation of a metamorphic video generation pipeline based on the given prompts, with the stated goal of enhancing the capacity of video generation models to accurately depict the real world. The project page is https://pku-yuangroup.github.io/MagicTime/, and the paper is stored under DOI 10.5281/zenodo.10960665.

For a team choosing a video backbone, the honest first question is whether your clips need explicit temporal change at all. If they do not, every hour spent on a time-lapse simulator is spent badly.

Three inference launchers, and no trainer among twelve entries

Twelve entries sit at the top level of the repository, and every one of them points the same way:

LICENSE
README.md
__assets__/
app.py
ckpts/
data_preprocess/
inference.sh
inference_cli.sh
inference_magictime.py
requirements.txt
sample_configs/
utils/

Three of those entries are inference launchers: inference.sh, inference_cli.sh and inference_magictime.py. A news line dated 2024.07.29 records batch inference being added to inference_magictime.py for easier use, which is the only logged change to how the model is driven. Beside them, app.py sits next to the gradio==3.50.2 pin, the single trace of a browser interface in the tree, though the README does not explain how to start it. ckpts/ is where weights are expected, sample_configs/ holds per-run settings, data_preprocess/ prepares inputs, and utils/ collects helpers.

Read that list for what is absent rather than what is there. There is no trainer, no optimiser configuration, and no training entry point among the twelve names.

torch 2.2.2 and diffusers 0.11.1 freeze the environment exactly

The dependency file is the most exact thing in the repository. Twenty-one names, thirteen of them pinned with an exact version, and two policies living side by side. First half:

torch==2.2.2
torchvision==0.17.2
torchaudio==2.2.2
xformers==0.0.25.post1
imageio==2.27.0
imageio[ffmpeg]
imageio[pyav]
peft==0.9.0
numpy==1.26.4
ms-swift==2.0.0
accelerate==0.28.0

Second half:

diffusers==0.11.1
transformers==4.38.2
huggingface_hub==0.25.2
gradio==3.50.2
gdown
triton
einops
omegaconf
safetensors
spaces

Two details reward a close reading. The file is strict where a library's shape matters and silent where reproducibility matters, because gdown, triton, einops, omegaconf, safetensors and spaces carry no version at all, so two installs of the same commit can land on different code. And ms-swift==2.0.0, a training framework, sits inside a tree that holds no trainer, which is the clearest leftover trace of the missing training path. Every inference library is frozen with an equality sign, so reproducing the authors' environment means taking those exact versions or accepting whatever a resolver picks instead. The README does not document a container image, a wheel index or an upgrade path, and there is no stated route for moving forward.

First run through the space, Replicate, or the Colab notebook

The README prints no installation command and no inference invocation, so the documented routes into MagicTime are hosted surfaces rather than a local checkout: a Hugging Face space at BestWishYsh/MagicTime, a Replicate demo and cloud API at camenduru/magictime, and a Colab notebook at camenduru/MagicTime-jupyter. The paper is also on Hugging Face as 2404.05014.

Start in the space, since that removes the checkpoint question entirely. Write a prompt that states a transformation over time rather than a static scene, submit it, then judge the clip on three points: does the change proceed in one direction, does the scene keep its identity while it changes, and does the motion stop where the prompt stops. Those checks are what the metamorphic framing asks for, and what ChronoMagic-Bench was built to score.

If the hosted surface does not settle your prompt set, the local route begins with the pin list above and with no documented checkpoint source at all, and that gap is where most of the friction lives.

Two undated news lines leave the training path open

The news block runs backwards through six dated entries: 2026.03.08 introduces Helios, 2025.04.08 points at the updated technical report, 2025.03.28 announces TPAMI acceptance, 2024.07.29 adds batch inference to inference_magictime.py, 2024.06.27 introduces ChronoMagic-Bench, and 2024.05.27 covers Open-Sora Plan v1.1.0. Above all of those sit two lines carrying no date and an hourglass marker: training a stronger model with the support of Open-Sora Plan, and the training code of MagicTime.

Set those two lines against the tree and the contradiction is plain. The repository describes itself as the official implementation, yet it holds no trainer, no training configuration and no optimisation pipeline; data_preprocess/ prepares frames, it does not assemble optimisation examples. The last push was on 2026-04-14 and the repository is not archived, so this is the state of the code rather than an artefact of an old clone. Anyone planning to fine-tune, retrain, or reproduce a training curve here finds forward passes only, and has to read the paper for the method and the Open-Sora Plan repository for the training stack.

No prompt flag, no checkpoint file, no GPU figure anywhere

What the repository lacks matters as much as what it holds. The three launchers are listed, and not one of their arguments is documented: no prompt flag, no checkpoint path, no frame count, no resolution, no seed. sample_configs/ exists and no example file is reproduced anywhere in the README, so the config schema has to be inferred from code. ckpts/ exists, and no checkpoint file name, format or download location is given, even though requirements.txt carries huggingface_hub==0.25.2 and gdown, which are download tools rather than inference libraries.

Hardware is silent too. No GPU model, no memory figure, no expected clip length and no runtime for MagicTime appears anywhere in the README. That silence costs more here than it would in a repository with a model card, because a diffusion video model is defined as much by resolution and frame count as by weights, and not one of those three numbers is pinned in the visible tree. The single hardware number in the group's own text belongs to a different model: Helios is reported at 19.5 FPS on a single H100 GPU on 2026.03.08, without conventional long video anti-drifting strategies or standard video acceleration techniques. That figure does not transfer to MagicTime.

Open-Sora Plan and Helios cover different axes entirely

Three alternatives from the same organisation cover ground MagicTime does not, and choosing between them is simpler than it looks. Open-Sora Plan is the group's general open-source large video generation model, and its v1.1.0 arrived on 2024.05.27 with a claim of better quality and longer videos; it is the default choice when a prompt describes a scene rather than a transformation. Helios, introduced 2026.03.08, attacks minute-scale long video and reports 19.5 FPS on a single H100 GPU. ConsisID and OpenS2V-Nexus target identity preservation and subject-to-video instead.

The more useful alternative is evaluation, not generation. ChronoMagic-Bench, announced 2024.06.27 and fully open source under arXiv 2406.18522, scores text-to-time-lapse output rather than producing it, so a team that only needs to measure whether time-lapse clips hold together can adopt the benchmark and run no generator at all. A team chasing identity across frames or longer clips should look at ConsisID, OpenS2V-Nexus or Helios instead. And since an undated news line puts MagicTime's own stronger training inside Open-Sora Plan, the two projects are converging rather than competing.

ChronoMagic data, the benchmark, and one absent baseline table

Two artefacts live outside the code. BestWishYsh/ChronoMagic is the time-lapse dataset on Hugging Face, linked from the README alongside the model space, and ChronoMagic-Bench is the evaluation harness built on it. The paper is stored under DOI 10.5281/zenodo.10960665 and the arXiv entry is 2404.05014, refreshed on 2025.04.08 after TPAMI acceptance on 2025.03.28. On licence terms, the code sits under Apache-2.0, so a redistributed or modified copy still has to carry the notice and state what changed.

What the README does not give is any baseline table for the benchmark, so the repository cannot tell you how MagicTime compares with general video models on the metamorphic axis, only how to produce samples. For a team that pushes the evaluation effort outside the repo: generate clips with a script whose flags are undocumented, then score them with a separate harness. Check the dataset terms against your intended use first, since the README links BestWishYsh/ChronoMagic but names no terms for it.

Editorial conclusion

MagicTime suits a researcher who needs a time-lapse specific text-to-video model and is willing to reverse engineer undocumented scripts. It does not suit anyone who needs training code, a documented command line, or a reproducible checkpoint download, since none of those exist in the tree. Check three things before committing: whether inference_magictime.py runs at all against diffusers==0.11.1 on your machine, what ckpts/ expects to receive, and whether ChronoMagic-Bench scores your case better than a general model.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. PKU-YuanGroup/MagicTime on GitHub
4. Project website
5. README