Cat Movie: an open-source video player that stopped being one

The README announces the project went closed source

The first thing on the page is a warning block, and it is the most consequential line in the repository: the project states that after version 2.5.9 it moved to closed source. That notice sits above everything else, before the platform badges and before the download table, which tells you the author considers it part of the primary message rather than a footnote.

What that means in practice is concrete. There is no application source code to read here. The repository tree contains a README, a `JS/` directory, a `docs/` directory, a logo image and the usual dotfiles, and that is the whole thing. You cannot fork the player, patch the UI, or read how the decoder is wired. The commit history is not a substitute, because the commits after the switch are not the player itself.

And yet commits continue. The last recorded push to the default `dev` branch is 2026-03-27, roughly six months after the newest tagged release, release-v2.6.1, which shipped on 2025-11-07. Both facts stand at once: the source is closed, and the repository is still receiving commits. Those commits are consistent with documentation and release-asset maintenance rather than with a live application codebase, and that distinction matters if you were planning to file a bug against the source.

The README also says feedback and suggestions are still welcome through the issue tracker, and points at a separate guide site at xmpro.netlify.app for the author's other material. That repository is the distribution channel now, not a development home.

Five platforms, six builds, three mirror links each

The download table is the most substantial thing in the repository and it is genuinely useful. The README claims support for Android, Windows, macOS, iOS and Linux, with badges for each. The table then breaks that into specific builds, because a single binary per platform does not cover the fragmentation:

- macOS as a `.zip` in universal architecture. - Android as `.apk` in three flavours: a common arm64-v8a build, a legacy armeabi-v7a build for older phones, and a universal build. - Windows as a `.zip`, with no architecture column filled in. - Linux as a `.zip`, whose filename says x86_64.

The three-way Android split is the detail worth remembering. Handing an arm64 apk to a 32-bit device is the failure mode people hit, so shipping a legacy and a universal build alongside the primary one is a thoughtful touch rather than a marketing one.

iOS is the odd one out. The prose says iOS is supported, and a commented-out table row in the source of the README lists a `.ipa` alongside the macOS entry, but the active download table has no iOS row at all. Treat iOS as claimed rather than as currently downloadable from this page, and check the release page itself if it matters to you.

Every row offers the same choice of four links: a global proxy, a Hong Kong proxy, a third accelerator, and the original GitHub URL. That pattern is a deliberate acknowledgement of network conditions, and the direct link is always one of the four:

https://github.com/waifu-project/movie/releases/latest/download/catmovie-mac.zip

The release notes for v2.6.1 add a domestic mirror hosted on Lanzou Cloud with the password 666, which is a small extra step for users who cannot reach GitHub at all.

Why a JavaScript extension source is the interesting part

The repository description is in Chinese and says, in effect, that this is a full-platform video player supporting VOD and JS extension sources. That second capability is the one that separates this from a plain media player, and the presence of a `JS/` directory at the repository root is the physical evidence for it.

A VOD source in this context means a single video URL that the player can fetch and play. A JavaScript extension source means something more flexible: a piece of code the player evaluates to decide what to play, which in practice covers the collection-based interfaces common to Chinese streaming aggregators, where one entry is not one URL but a page of links with a parsing rule attached.

This design is why the app is distributed as a closed binary rather than as a library. The player is not trying to be a general media framework; it is a shell whose value is that it can be pointed at an arbitrary source description. That also explains the documentation directory, which links a guide on creating a source and a separate page on keyboard shortcuts. Creating a source is the skill the project teaches, and the keyboard reference covers the control surface of the player itself.

Neither document is reproduced in the repository, so if you are evaluating this on the strength of the extension mechanism, the guide site linked from the README is where the actual format is specified.

Two descriptions of what the project is, side by side

The repository metadata and the file tree disagree about the technology, and it is worth writing both out rather than picking one.

The language field reports TypeScript. The topic tags report `flutter` and `getx`, and GetX is a state management and routing package for Flutter, which is written in Dart, not TypeScript. Those three facts cannot all describe the same application stack. Meanwhile the repository itself, after the closed-source switch, contains no TypeScript and no Dart at all: it has a README, `JS/`, `docs/`, `logo.png`, `.gitattributes` and `.gitignore`.

The most likely reading is that the language field and the topic tags describe the application as it was when the code was public, and the tree describes the repository as it is now, after the build stopped living here. That is a coherent story, but it is an inference, and the practical advice does not change either way: the topics describe a Flutter client with GetX, and neither that code nor any TypeScript is available to you.

One smaller contradiction sits alongside it. The README's License section is absent, and no license file appears in the tree or in the repository metadata. For a project that was open source until 2.5.9, the disappearance of the license text is worth noting if you were planning to reuse anything.

The screenshots are hosted on an external image host rather than stored in the repository, which is consistent with keeping binary assets out of a distribution-only repository.

Editorial conclusion

Cat Movie is easiest to judge as a binary distribution rather than a codebase. There is no application source here to read: the tree is a README, a `JS/` directory, `docs/` and a logo, and the downloads are prebuilt zips, apks and an archive rather than a package you can install from an index. If you want a player that plays a `VOD` or JavaScript source you wrote yourself, this is the fastest route on five desktop and mobile platforms. If you want to build on the player itself, the closed-source notice means you cannot, and the last commit recorded here is 2026-03-27 with the newest tagged build at release-v2.6.1. Start with the `catmovie.apk` for arm64 devices, or the macOS zip if you are on a Mac, and read `docs/create_source.md` before assuming your source format will work.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. waifu-project/movie on GitHub