# world.execute(me) dsh PV: a music video rendered entirely from code

> This repository is the full source of an unofficial fan PV for Mili's world.execute(me), built so that every frame is a pure function of song time. The chat window is real HTML screenshotted with Playwright, the right side is a TUI engine drawn with PIL, and the song itself is not included because of copyright.

**MisakaZentai/world-execute-me-dsh-pv** — Code-rendered TUI fan PV for Mili world.execute(me); with a DeepSeek Harness-style chat window. MIT code; CC BY-NC-SA 4.0 artwork.

- Repository: https://github.com/MisakaZentai/world-execute-me-dsh-pv
- Website: https://www.bilibili.com/video/BV1xCai6aE9g/
- Stars: 644 · Forks: 60
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/misakazentai-world-execute-me-dsh-pv

## Every frame is a pure function of song time

The design principle behind this project is stated in the English summary at the top of the README, and it is the whole architecture in one sentence: every frame is a pure function of song time. The consequence is that the video is not a sequence of recorded clips but a program that is evaluated against the audio clock, so the same song and the same code always produce the same frames. That is what makes a rebuild possible, and it is what separates this from a video project that can only be re-edited by hand. The content is split across two halves. On the left is a DeepSeek Harness chat window, the conversation between the character and the viewer, and on the right is the world she is running in, which the README describes as the model's visualisation. The left half is real: the pages are per-frame HTML built from the dsh project's own CSS and screenshotted with Playwright, so the chat interface is the actual interface rather than a drawing of one. The right half is a TUI model-visualisation engine drawn with PIL, so the terminal aesthetic is rendered rather than emulated by a video game capture. The whole thing is an unofficial fan work, and the README says so explicitly and repeatedly.

## One command renders the film, and the outputs are explicit

The build is driven by a single Python entry point, build.py, with the front end pieces pulled in by npm and Playwright's browser installed first.

```bash
npm install
npx playwright install chromium
```

The Python side needs a few packages, and the file that lists them also documents the version floor.

```bash
pillow>=10
numpy>=1.26
```

The prerequisites are spelled out as Python 3.12 or newer, Node 20 or newer, ffmpeg on the PATH, and Windows fonts, with a document at docs/FONTS.md explaining how to substitute fonts on other systems. The font requirement is a real constraint rather than an inconvenience, since the intended look depends on the metrics of specific Windows typefaces, and Consolas and Microsoft YaHei cannot be redistributed, so the renderer reads the ones installed on the machine. The build command runs the whole chain, described in the README as check, lyrics, placeholder dancer, page screenshots and render, and there is a separate all --4k variant that produces a 3840 by 2160 version. The outputs are named distinctly, with out/film.mp4 as the 1280 by 720 finished video, out/film_master.mp4 as a lossless master, and out/film_4k.mp4 when the 4K option is used. Every step can also be run on its own with build.py followed by check, lyrics, dancer, pages or render, which is how you iterate on one stage without paying for the whole render.

## What is deliberately missing, and what to do instead

The README includes a table of what is not in the repository and why, with a substitute for each row, and it is the most useful part of the documentation for anyone thinking of running this. The song audio is absent because of Mili's copyright, so you bring your own copy, place it at input/song.mp3, and the check step verifies the version with a sha256 comparison. The lyrics text is absent for the same reason, so the lyrics step downloads them to your machine from LRCLIB and combines them with the per-word timings that ship in the repository, which contain timing but no text. The original film's dancer footage is absent because it involves a third party MMD model and motion whose terms of use do not permit this, and because the permissions for AI reference and derived footage distribution are not confirmed, so the build generates a placeholder dancer instead, and your render differs from the original in that respect. The Windows fonts are absent because they cannot be redistributed, and the substitute is to use your own copies. The practical implication is that this repository is a rendering engine plus a set of timings, not a complete production package, and the pieces you supply are the pieces with rights attached to them.

## The rebuild is not frame-identical, and the README says by how much

The section comparing the rebuilt output to the finished video is unusually honest, and it is the section to read before assuming a rebuild is equivalent. The dancer differs, because the placeholder substitutes for the original. The checkpoint numbering between 12.5 and 29 seconds differs, because the finished video used a window capture from before the last change to the numbering formula. Three frames around 123.5 seconds differ in the send button colour of the input box, for the same reason. For post-processing, the comparison found a local brightness difference between 114.75 and 114.83 seconds and a difference of about ten levels in the leftmost two columns between 159 and 161 seconds, with the cause unverified, possibly a different CPU and GPU post-implementation, and no controlled experiment carried out. The scope of verification is stated too. An existing Windows build record from 2026-09-30 contains 4968 window screenshots and a numeric comparison of the full master, with eight moments inspected by hand, and the master difference filter was pixels differing by more than 8 levels exceeding 0.2 percent of the frame, which the README notes does not mean every pixel is within 8 levels and is not the same as a frame by frame visual or audio sync acceptance. The testing also borrowed an existing Playwright environment, so a fresh install on another system has not been shown to reproduce the same layout.

## Optional 60 fps export without redoing the screenshots

There is an optional post-processing path that exists because re-rendering everything is expensive. After generating the lossless 720p master, FFmpeg can do motion compensated frame interpolation to export a 1080p 60 fps or 2560 by 1440 60 fps playback version, without regenerating the web page screenshots and the character caches. The details, the measured file sizes, and the difference between file size and runtime memory are in a document at docs/60FPS_EXPORT.md, which provides reproducible commands for bash, zsh and Windows PowerShell. The reason this is worth doing is the structure of the pipeline. The expensive stages are the browser screenshots and the PIL drawing, and both are tied to a fixed timeline, so if the frame rate changes, those stages would have to be redone. Interpolating afterwards keeps the expensive work identical and only changes the presentation. The optional torch dependency in the requirements file exists for the same reason from the other end, since a GPU path is available for the render step and a CUDA build of torch would be much faster, with the README noting a CPU render of the full film takes roughly ten to thirty minutes depending on core count.

## A directory layout kept as working names, with relative imports

The repository structure section carries an instruction that is easy to miss and expensive to ignore: the directory names keep the working names used during production, the code finds each other by relative position, and you should not rename them. The tree itself explains the pipeline. build.py is the one-command render. tools/ holds the lyric synthesis and the placeholder dancer scripts. data/ holds the per-word timings without text, the song fingerprint and the manifest of dancer frames. film/ is the bulk of the work, with a directory for the dsh window holding the per-group page scripts, the screenshot script seg_shot.mjs, and the composition and patch scripts, and a directory for the TUI engine holding tuikit.py with the first version of shots in full/ and the second version of continuity and transitions in continuity_full_v2/. A third directory holds the dancer's timing table, and another holds the third party reference art under CC BY-NC-SA 4.0. The vendor directory contains the dsh web frontend and the Cordis component package, both MIT and credited to DeepSeek, and they are the CSS and JavaScript the per-frame pages are built from. The docs directory holds the production principles, the font guide and the 60 fps export notes. The dependency of the whole approach on relative paths is a fair criticism of the layout, and it is a direct consequence of the film being assembled by scripts that grew organically.

## Licensing is split four ways, and the sharing guidance is restrictive

The permissions here are not uniform, and anyone who renders and publishes a video needs all four lines. The code is MIT. The artwork, meaning the character illustration, the expressions and their adaptations, is shared under CC BY-NC-SA 4.0, so you keep the attribution chain and licence links, note the changes, do not use it commercially, and share adaptations under the same terms. The dsh frontend files are MIT, copyright DeepSeek, and the fonts are SIL OFL 1.1. The music and lyrics rights are reserved, and the MIT licence on the code does not extend to them, and Mili's official copyright guidelines allow personal non-commercial derivative works while requiring AI fan content to be labelled as such. The README also states that the project uses AI-generated character art, and that the original film additionally contains AI video, so a published version should say plainly that it contains AI-generated content rather than claiming every frame is code-rendered. Sharing is expected to be non-commercial by default with full attribution and licence links, and commercial use, paid viewing or revenue programmes need separate confirmation. The NOTICE.md file and docs/ASSET_SOURCES.md hold the third party list and the provenance of the assets.

## The build was written mostly by AI models, and the author kept the direction

The project documents its own AI use, which is unusual and useful information for anyone assessing the codebase. Most of the code was written by AI, with Claude Code using Claude Opus as the main tool for the picture engine, the dsh interface pages, the segmented implementation and the render script, and Codex with GPT-6 Astra used for per-word lyric time alignment and whole-film direction review. The overall approach, the aesthetic decisions and the review of each batch were the author's work. The AI use table records the quantities roughly, with the Claude Code work inside a Claude Pro subscription with no overage billing and no API pay-as-you-go and no token totals recorded, and the Codex work similarly inside a Pro subscription with no API use. The final dancer video came from MiniMax-H3 running locally in ComfyUI, about 31 generations and roughly 1.7 GPU hours on an RTX 3090 at no cost, with Grok Imagine and Seedance 2.0 Fast tried and not used in the final cut. Audio analysis was local only, for alignment rather than generation, using Demucs to separate the vocal, MMS_FA for CTC alignment, and Whisper medium.en with stable-ts as an independent check. The repository also notes the inspiration behind the project and the organisational pattern borrowed from another open source video repository.

## Conclusion

Adopt this repository if you want to study how a music video can be regenerated deterministically from a song, or if you want to render your own take with the same engine and the same per-frame page pipeline. Skip it if you expect a finished artefact, since the song, the lyrics and the original dancer footage are deliberately absent and you must supply your own audio. Verify first that Python 3.12, Node 20 and ffmpeg are present, that you read the licensing split in the README before publishing anything you render, and that the character art you use carries the attribution the project requires.

## FAQ

### What do I need to render this PV myself?

Python 3.12 or newer with pip install -r requirements.txt, Node 20 or newer, ffmpeg on the PATH, and Windows fonts, with a document at docs/FONTS.md covering substitutions on other systems. You also supply your own copy of the song at input/song.mp3, since the audio and the lyrics are not in the repository for copyright reasons.

### How do I render the video?

Run npm install and npx playwright install chromium, then run build.py all for the standard 1280x720 output, or build.py all --4k for a 3840x2160 version. Individual stages can be run separately with build.py followed by check, lyrics, dancer, pages or render.

### Can I publish a video I render with this code?

Yes, non-commercially, with attribution. The code is MIT, the artwork is CC BY-NC-SA 4.0 requiring attribution, no commercial use and share-alike adaptations, and the song and lyrics rights are reserved, so you must supply your own audio and label any AI-generated content as the original project's guidelines require.

## Sources

- [Issues](https://github.com/MisakaZentai/world-execute-me-dsh-pv/issues)
- [License: MIT](https://github.com/MisakaZentai/world-execute-me-dsh-pv/blob/main/LICENSE)
- [MisakaZentai/world-execute-me-dsh-pv on GitHub](https://github.com/MisakaZentai/world-execute-me-dsh-pv)
- [Project website](https://www.bilibili.com/video/BV1xCai6aE9g/)
- [README](https://github.com/MisakaZentai/world-execute-me-dsh-pv/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/misakazentai-world-execute-me-dsh-pv