NipaPlay-Reload combines a Rust playback core with a danmaku layer

What it is actually built on: Flutter plus a Rust core over FFI

The primary language is Dart and the shell is Flutter, but playback is not Flutter's own video pipeline. The repository carries rust/, rust_builder/, cpp_native/, flutter_rust_bridge.yaml and packages/, and the README describes the architecture as a Rust and Dart hybrid where the core modules do the heavy computation and the Dart layer coordinates with it. Native modules are listed as Rust through FFI and Dart FFI, and state is managed with Provider while storage is SQLite plus SharedPreferences.

That bridge configuration is the part worth reading before you adopt this. flutter_rust_bridge.yaml at the top level is the contract file, and it means building from source requires a working Rust toolchain and a bridge generation step, not just a Flutter SDK. There are per platform pubspec override files as well: pubspec_overrides.linux.yaml, pubspec_overrides.tvos.yaml and pubspec_overrides.ohos.yaml, which is how the same Dart tree is retargeted for Linux, tvOS and OpenHarmony.

The iOS and tvOS SDKs are pinned separately through .flutter-version-linux and .flutter-version-tvos, so the Flutter version is a per platform decision rather than a single number.

Four playback kernels, and you do not choose which one

The README lists four engines: Erika, its own Rust core, plus FVP on libmdk, Media Kit on libmpv and the Flutter Video Player. Erika selects Metal on Apple platforms, D3D11 on Windows, and WGPU or Vulkan elsewhere. That is an unusual amount of platform branching in a single application, and it is where capability silently varies.

Anime4K upscaling and CRT shader effects, for instance, are kernel dependent features. A user on one platform and a user on another run the same app and can get different results from the same menu item. The README does not publish a feature matrix per kernel, it defers to Documentation/player-kernels.md and Documentation/platform-matrix.md.

Frame interpolation is on the roadmap and still unchecked, listed as SVP or other. So is cross platform HDR and Dolby Vision on Windows, Linux and Android, while macOS HDR is marked done through the Erika kernel's native EDR path and Media Kit. Read those roadmap boxes as the current boundary, not as a promise.

Installing on macOS and Arch without touching the releases page

GitHub releases are labelled the recommended path, and there are store listings for the App Store, the Microsoft Store and the Spark Store on Linux. Package managers are documented too. On macOS the tap adds the project's own cask:

brew tap AimesSoft/nipaplay-reload
brew install --cask nipaplay-reload

On Arch, two AUR packages exist, a binary package and a source build. The README shows the binary one as:

yay -S nipaplay-reload-bin

and the source package as a separate command. Note the security warning in the README: a different package, `misuzu-music-bin` in the AUR, was taken over by a malicious actor and must not be installed. It is a reminder that the AUR is not a trusted namespace, and this project happens to name the incident rather than leave you guessing.

Gentoo users are pointed at an ebuild file inside the repository, `gentoo/media-video/nipaplay-bin/nipaplay-bin-1.8.11.ebuild`, merged with ebuild. That version number trails the current v1.11.9 release, so the Gentoo path is the one most likely to hand you an older build.

Danmaku, subtitles and the anti spoiler overlay

The feature that distinguishes this player is the danmaku layer. Comments scroll, pin to top or bottom, remember trajectory between episodes to avoid covering the same region, and can be loaded from local xml or json files as well as matched online through the dandanplay API. That trajectory memory is the part that separates it from a plain overlay: the app remembers where it placed comments earlier and avoids stacking new ones in the same spot.

Subtitles handle ASS and SRT with multiple track switching and custom styling, and can also be mounted from local files.

The AI anti spoiler feature detects content likely to spoil later events and masks it. That is a network dependent, model dependent behaviour, and the README gives no description of what it sends off the device, no accuracy figure, and no toggle. If privacy matters to you, that gap is worth resolving before you leave it on.

Bangumi integration covers progress sync, scoring and comments, and the release schedule view updates daily with a weekly grouping. The app also ships a torrent downloader and remote control over a built in server, with a server/ directory at the top level.

Where it is the wrong tool

It is a desktop and mobile application, not a component. There is no published Dart package for playback or a headless binary, and the README positions it as a personal media centre. If your requirement is a library embedded in your own app, or a server side transcode pipeline, none of this applies.

It is also not a media server. Emby, Jellyfin, SMB and WebDAV are mount sources. The README does not describe how the app handles server-side transcode URLs. Do not assume seamless playback of everything in your library.

Finally, the four kernel strategy means bug reports are hard to generalise. If playback misbehaves, the useful question for the issue tracker is which kernel and which platform, not which version. The project asks for logs exported from the in app developer options, which is a good sign that this distinction is expected to matter.

Against VLC, mpv and Jellyfin Media Player

NipaPlay-Reload deliberately steps outside that, mounting Emby and Jellyfin alongside SMB and WebDAV and local files, and adding the anime specific layer on top.

The self written Rust core is the honest difference and the honest risk. Owning the decode path is what makes per platform rendering choices and the macOS EDR HDR path possible. It also means format compatibility is whatever Erika implements, and the README does not publish that list.

Release cadence, licence and the split project layout

The repository is not archived and the last push was on 2026-10-16, with releases v1.11.9 on 2026-10-02, v1.11.8 on 2026-09-25 and v1.11.7 on 2026-09-15. That is three releases in under a month, and the alpha of a new minor appears ahead of the stable line, which is a project shipping quickly. For an application you install rather than a library you pin, the cost is that a regression can arrive a week after you liked a build. There is no changelog format documented and no LTS channel mentioned.

The licence is MIT, which permits modification and redistribution including in commercial builds, with attribution preserved. That is a licensing note rather than advice.

The tree splits documentation across Documentation/, docs/ and CONTRIBUTING_GUIDE/, with a separate Apple TV guide at docs/TVOS_DEVELOPMENT.md that describes a standalone tvOS Flutter SDK and its current capability limits. Contributors are pointed at CONTRIBUTING_GUIDE/00-Introduction.md. There are also harmonyos_test/ and tvos/ directories, which confirms both platforms are being worked on rather than only stubbed.

Editorial conclusion

NipaPlay-Reload fits someone who watches anime or Chinese local media and wants danmaku, multiple subtitle tracks and Bangumi progress sync in one app across desktop and mobile, and it is a poor fit as an embeddable library or a server side transcoder because the playback layer is a desktop and mobile application rather than a published Dart or Rust package. Verify first which playback kernel Documentation/player-kernels.md assigns to your platform, because the features you get, including Anime4K upscaling and HDR, follow that choice rather than the app name. Check Documentation/platform-matrix.md before trusting Windows ARM64, tvOS or HarmonyOS, since the README calls their build availability out as unconfirmed.

Frequently asked questions

Official sources

1. AimesSoft/NipaPlay-Reload on GitHub
2. License: MIT
3. Project website
4. README
5. Releases