PDoomVideo: How the Claude Opus 5.5 Music Video Is Rendered

PDoomVideo's Specific Role in Claude Animation

JohnHeibel/PDoomVideo is not a general video editor or a reusable Claude integration. The repository is the source for one finished creative artifact: the Claude Opus 5.5 music video for I'm Upping My P(doom). Its intended audience is therefore narrow. Developers, artists, and animation researchers can use it to examine how a model-generated sequence became executable browser artwork and a rendered MP4. The music is already included at `assets/pdoom.mp3`, so the repository represents a complete production example rather than an empty framework.

The README says every part of the repository was generated by the model, including the scene concepts. The initial direction was limited to the Clawd character design, interesting visuals for each lyric, and transitions between scenes. That constraint gives the project documentary value, but it also limits its status as a foundation. There is no evidence here of a general scene schema, stable public API, or supported set of reusable commands. For a new animation pipeline, the repository is primarily source code to read and adapt.

From Lyrics to Nine p5.js Chapters

The repository separates the video into nine chapter files under `src/ch/`. Shared material lives under `src/`, including Clawd, guest characters, props, lyrics, and the timeline. This layout makes the timing model visible as a project concern. A chapter can contribute visuals for its part of the song while shared code supplies recurring characters and assets.

All drawing is consolidated in `studio.html`, which uses p5.js and p5.brush. The dependency versions declared in `package.json` are `p5` `^2.3.3` and `p5.brush` `^2.2.3`. The chapter structure therefore feeds a browser-based animation stage rather than producing video frames through a conventional offline renderer. `STORYBOARD.md` records the shot-by-shot plan, while `ANIMATION_GUIDE.md` documents the style and coding directions given to subagents. Those planning files are as important to understanding the project as the executable source.

The first generation is preserved separately under `legacy/`. The README states that it was produced with Claude Opus 5.5 at Medium effort, while everything outside that directory came from a second generation. Keeping the earlier version makes the regeneration process inspectable, but it also creates two code paths to understand. Anyone modifying the project must determine whether a change belongs in the current chapters or the retained first attempt.

Rendering PDoomVideo with Node.js, Chrome, and ffmpeg

The README identifies Node.js, Google Chrome, and ffmpeg as the rendering prerequisites. Install the declared dependencies from the repository root with:

npm install

This also installs `puppeteer-core`, but the project still requires a separate Chrome installation because it does not declare a bundled browser dependency.

Render the frame range from 0 through 156.6 into `out/frames` with four workers:

node render.mjs --frames=0:156.6 --workers=4   # paint every frame into out/frames (resumable)

The README describes this operation as resumable. The `--workers` value controls parallel work for rendering frames. The source does not document a portable way to tune worker count for every machine, so four workers should be treated as the documented command rather than a universal recommendation.

After frames have been painted, encode them with the included song:

node render.mjs --encode --out=out/pdoom.mp4   # join the frames and the song into an MP4

The expected result is `out/pdoom.mp4`. If Chrome is not installed at the default Windows path, the documented option supplies its location:

node render.mjs --chrome=<path to chrome>

The README does not explain how the full range is selected automatically, how resumed state is validated, or how to render only a short preview. Users should expect to inspect `render.mjs` when they need behavior beyond the documented commands.

Headless Chrome and ffmpeg Boundaries

The rendering path has two clear tool boundaries. `render.mjs` paints frames in headless Chrome and invokes the browser-side scene defined by `studio.html`. The ffmpeg stage joins the rendered images with `assets/pdoom.mp3` and produces an MP4. Splitting these stages makes the operation resumable at the frame-rendering boundary and lets encoding run separately after the image sequence exists.

That design also creates operational dependencies. A successful npm installation is insufficient if Chrome is unavailable at the location expected by the script. The same applies to ffmpeg, which is an external executable rather than a dependency listed in `package.json`. The repository does not document automated installation, version checks, or platform-specific setup beyond the Windows Chrome path note. Linux and macOS users would need to supply suitable Chrome and ffmpeg installations, but the README does not state how `render.mjs` detects their paths.

There is no published release history to consult for migration notes. `package.json` identifies the package as version `1.0.0`, but that does not establish a release series with compatibility guarantees. For an unusual dependency or browser change, inspecting `package-lock.json` and `render.mjs` is more informative than assuming the package version describes the rendered artifact.

Limits of the Claude-Generated Production Code

The strongest limitation is stated by the project itself. `package.json` defines a `test` script that prints `Error: no test specified` and exits with status 1. There is no documented automated test that checks scene timing, browser rendering, generated files, or the encoded MP4. A modification can therefore paint or encode without any repository-provided validation.

The documentation is also centered on this video. It does not define command-line options for changing video dimensions, frame rate, audio, scene selection, or output codec. It does not explain how the lyric-to-scene mapping is validated, how dropped frames are detected, or how a failed worker is retried. The resumable frame command is useful, but the mechanics and recovery instructions are not documented in the README.

Licensing requires equal care. `package.json` declares `"license": "ISC"`, but the repository has no `LICENSE` file among its top-level entries. The README does not explain how that declaration relates to the song, linked visual references, or all repository content. This is not legal advice; users should resolve the discrepancy before redistribution. The README also links `ClaudeAnimationBase` as a more reliable and general base, which indicates that PDoomVideo is not positioned as durable animation infrastructure.

PDoomVideo Compared with ClaudeAnimationBase

The clearest alternative named by the project is JohnHeibel/ClaudeAnimationBase. The README calls it a more reliable and general base for creating Claude animations with Claude Opus 5.5. That is a direct architectural distinction, not merely a difference in branding. PDoomVideo is organized around nine video chapters, one song, shared story assets, and a fixed `studio.html` rendering page. The alternative is presented as the starting point when animation work should extend beyond this particular composition.

For learning, PDoomVideo has the advantage of a finished, inspectable outcome. Its chapters, timeline, storyboard, animation guide, frame renderer, and encoding step let a reader trace the full production path. The README does not document ClaudeAnimationBase's commands, architecture, or compatibility, so the comparison must stop at its stated purpose. The practical distinction is bounded: use PDoomVideo to study this video, but investigate ClaudeAnimationBase when the requirement is general animation generation.

Neither source should be confused with a conventional manual scene editor. The documented process uses creative direction, model-generated planning, code, browser rendering, and external encoding. If a project needs hand-authored timelines, deterministic reusable APIs, or automated output validation, the PDoomVideo repository does not establish that it supplies those capabilities.

Maintenance Signals and Upgrade Cost in PDoomVideo

The repository is not archived, and its last push was on 2026-09-25. That is a current maintenance signal, but it is not the same as a published support commitment. The repository has no GitHub releases, so there is no documented release cadence, upgrade guide, or compatibility policy for previous versions. The package version of `1.0.0` does not by itself establish that a formal release was published.

Upgrades are most likely to involve the JavaScript rendering stack. `p5`, `p5.brush`, and `puppeteer-core` are declared with caret ranges in `package.json`, while `package-lock.json` records a resolved dependency state. The README gives no instructions for upgrading packages, updating Chrome, changing ffmpeg versions, or comparing renders after dependency changes. Browser rendering can therefore make environment maintenance part of the cost, especially when a frame-by-frame output is the deliverable.

The division between `legacy/` and the current source adds manual review cost. The repository preserves two generations rather than exposing one documented migration path. An engineer adapting the project would need to compare those files, inspect the model-written animation guide, and identify the rendering assumptions in `render.mjs`. The linked `ClaudeAnimationBase` may offer a different base for future work, but migrating between the two repositories is not documented here.

Editorial conclusion

Adopt PDoomVideo if you want to inspect or modify a specific Claude Opus 5.5 animation and can operate Node.js, Chrome, and ffmpeg. Do not treat it as a reusable engine without first reviewing `ANIMATION_GUIDE.md`, `STORYBOARD.md`, and the linked `ClaudeAnimationBase` project. Verify the render command, frame output, and unresolved license status before incorporating its code into a production workflow.

Frequently asked questions

Official sources

1. Issues
2. JohnHeibel/PDoomVideo on GitHub
3. README