KikoPlay: a danmaku player that grew into a download and library manager

The tagline says the project is more than what it is named

The repository title reads KikoPlay, and the README's first heading is the project's own correction of that: NOT ONLY A Full-Featured Danmu Player, followed by the same statement in Chinese. That bilingual doubling is a fair signal about the codebase too. The danmaku player is the part users discover it for, and the downloader, media library, LAN server and extension system are the parts they keep it for.

The scale is modest but the polish is not. It has 2,236 stars, 121 forks and only 9 open issues, is GPL-3.0 licensed, written in C++, and has a homepage at kikoplay.fun. The last push was 2026-09-19, and the newest release is 2.1.0 from 2026-07-18.

The topic list is short and accurate: aria2, danmaku, danmu, libmpv, player. There is no AI, no model, nothing fashionable. What the repository actually contains is visible in the tree, where the directories are `Common/`, `Download/`, `Extension/`, `LANServer/`, `MediaLibrary/`, `Play/`, `Service/`, `UI/`, `lib/` and `web/`, plus a top-level `globalobjects.cpp` that wires them together.

That directory layout is the clearest statement of scope in the entire repository, and it is worth reading before the feature list, because it tells you the player is one of nine subsystems rather than the product itself.

Qt, libmpv and seven other dependencies

The build requirements are listed precisely, which makes dependency conflicts easier to reason about than most projects of this size allow. KikoPlay 2.1 is built on Qt 6.6.3, libmpv, aria2, ElaWidgetTools, zlib 1.2.11, QtWebApp, Lua 5.3 and qwebdavlib.

Two of those are load bearing in an architectural sense. libmpv is the playback core, and the README is explicit that it retains mpv's flexible parameter passing, which is the reason to choose this player over one with a hand-rolled engine. Lua 5.3 is the extension runtime, and the README notes extension apps arrived in version 1.0.

The rest is application surface: Qt for the interface, QtWebApp for the LAN web interface, qwebdavlib for the WebDAV collection support, aria2 for downloading, ElaWidgetTools for widgets, zlib for compression.

Build instructions cover Windows with MSVC 2022, and other platforms using their recommended package manager or Xcode. On Windows you open `build.pro` in Qt Creator; on Linux and macOS you can do the same with dependencies satisfied, or run `qmake` and `make` in the directory by hand.

Two facts about platform support that are easy to miss. Only 64-bit builds have been provided since version 0.2.3, and 32-bit is not recommended. And a CMake path exists via `CMakeLists.txt` and `vcpkg.json`, but the README states the CMake instructions were contributed by a community member and may stop working as versions move, leaving the user to adjust them. qmake remains the supported build.

Danmaku is the feature everything else is arranged around

Danmaku rendering is OpenGL-based, which is what allows both normal scrolling mode and live mode display, where comments appear at the moment they are sent rather than at their timestamp.

Comment acquisition covers the mainstream video sites, and the management layer is where this goes beyond a player. There are flexible danmaku blocking rules, automatic merging of similar comments, and analysis that annotates comment events. The point of these three features is the same: a long video with a dense comment track is unreadable, so the player reduces the track to something you can follow.

Version 2.1.0 extended this further. The 2.1.0 release notes list danmaku sources gaining tag information, a new danmaku timeline trimming feature, and support for importing subtitles as danmaku, plus batch folder scanning in the library and a rebuilt LAN access page with proxy settings and Android QR-code connection.

Timeline handling exists because of a concrete mismatch: video durations differ between local files and the sites the comments come from. Being able to trim and adjust the timeline is what makes a comment track usable when the local file is a different cut.

The 2.0 subtitle feature sits alongside this and uses a different mechanism entirely, which is the other place where Whisper enters the project.

Whisper subtitles need an API key for translation

Version 2.0 introduced subtitle recognition based on whisper.cpp, with fast recognition and translation of subtitles. The README adds a parenthetical that is easy to skim past: translation requires setting an LLM API key. Recognition is local; translation is not.

That distinction matters for how you deploy this. If you run KikoPlay on a machine you do not want to give a cloud credential, transcription still works and translation does not.

The 2.1.0 release notes mention an optimisation of the VAD processing flow to improve recognition results. VAD is voice activity detection, and it is the component that decides which spans of audio contain speech, so an improvement there is a quality improvement rather than a speed one.

Subtitles can also be imported as danmaku, which means the subtitle and comment systems are connected in both directions: recognised speech can become a comment track, and an existing subtitle file can become one too.

Taken together, this is the part of KikoPlay that is genuinely unusual for a player. Audio transcription, translation, and a bullet comment overlay are three separate features that only make sense together in an anime-oriented client.

Extensions split across three repositories you have to keep in sync

The extension story is spread over several repositories, and the 2.1.0 release notes are where the practical detail lives: on Linux and macOS, scripts go in `~/.config/kikoplay/extension/script` and extensions in `~/.config/kikoplay/extension/app`, and both repositories must be cloned into those locations manually.

There are separate repositories for the script collection, for the extension apps, for the Android LAN client, and a distinct one for the Android LAN client improvements. Plus `web/` in this repository for the LAN web interface itself.

Lua scripts have been supported since version 1.0, for adding features including bangumi synchronisation, web video downloading and m3u8 live streams. Extension apps arrived in the same version, framed as a way to add custom functionality. There is also a Web API documented in `web/README.md` for building something outside the app entirely.

The other network features are more conventional. DLNA support covers casting to other devices and acting as a media server. The LAN server lets you watch from a browser on another device, with the Android client as an alternative. WebDAV collections can be added to the playlist.

Version 1.0.3 added a script updater as a built-in extension, and improved startup performance, which is the kind of release note that tells you where the project's own attention has been going.

Editorial conclusion

KikoPlay is not a video player with a danmaku overlay, it is a management tool that happens to play video, and the naming understates that. The architecture is one mpv process per item with OpenGL drawing for the overlay, wrapped in a Qt interface with a library, a download queue and a Web API. The practical limits are clear: three related extension repositories to keep in sync, GPL-3.0 if you want to build on it, and a qmake primary build with CMake kept as a community contribution that the README warns may break.

Frequently asked questions

Official sources

1. KikoPlayProject/KikoPlay on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases