# DownKyi Core: a cross-platform Bilibili downloader built on Avalonia and .NET 10 > DownKyi Core is a cross-platform rewrite of the DownKyi Windows downloader, using Avalonia 12, the Microsoft Generic Host, dependency injection and CommunityToolkit MVVM, with a downloader that plans file segments, fetches them over multiple connections and keeps a strictly validated resume state. The release packages ship .NET and FFmpeg, and the project's own disclaimer limits it to parsing content you have the right to use. **crazysmile-PhD/downkyicore** — 哔哩下载姬(跨平台版)downkyi，哔哩哔哩网站视频下载工具，支持批量下载，支持8K、HDR、杜比视界，提供工具箱（音视频提取、去水印等）。 - Repository: https://github.com/crazysmile-PhD/downkyicore - Stars: 544 · Forks: 164 - Language: C# - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/crazysmile-phd-downkyicore ## A Windows tool rebuilt as a cross-platform one DownKyi Core is described as a cross-platform Bilibili video download tool based on the Windows version of DownKyi and on Avalonia, and the stack is listed in one line:.NET 10, Avalonia 12, the Microsoft Generic Host, Microsoft DI and CommunityToolkit MVVM. That combination is the whole architecture story, so it is worth unpacking what each piece is doing. Avalonia is a cross-platform UI framework, and it is what makes a single codebase produce a native window on Windows, macOS and Linux rather than a web page in a wrapper. The Windows original is the reference implementation, and this project is a port of it rather than a rewrite from nothing, which is why the release artefacts keep the DownKyi name and the packaging conventions of the original. The Microsoft Generic Host and dependency injection are less visible but matter more for a tool like this. The host is the standard way to compose a long running desktop application in.NET, with configuration, logging and lifetime management in one place, and the dependency injection container means the downloader, the parser and the storage layer can be replaced with test doubles without touching the UI. CommunityToolkit MVVM supplies the observable property and command pattern that a desktop UI of this shape needs. The repository layout shows the same discipline. DownKyi.Core holds the core library, DownKyi holds the application, src and tests are separate trees, there is a benchmarks directory, a tools directory, a script directory and a docs directory. The build is centralised, with Directory.Build.props, Directory.Build.targets and Directory.Packages.props for central package management, plus a global.json pinning the SDK and a version.txt holding the version. The primary language is C#, the licence is GPL-3.0 with the terms in the LICENSE file and the third party attributions in THIRD-PARTY-NOTICES.md, and the default branch is main with the last push on 2026-10-22. ## What it parses and what it downloads The feature list in the README is specific about the entry points and the artefacts, and that specificity is what makes the tool evaluable. On the input side, it parses video, collections, bangumi series, courses, favourites, viewing history and the watch-later list. That is a broad set of Bilibili entry points, and covering them is mostly a matter of matching the request shapes and the identifiers that come back, which is the kind of work that breaks when the platform changes rather than when the code changes. On the output side, it downloads audio, video, covers, danmaku, which are the scrolling bullet comments, ordinary subtitles and AI subtitles. The AI subtitle support is worth noting, because it is the item that most depends on the platform rather than on the client, and the existence of two subtitle paths in the same release tells you the plain one is not always enough. Two behaviours in the list are about correctness rather than coverage. The first is that deleting a downloading task also stops the downloader and cleans up the media and temporary files already produced, which is the behaviour that separates a downloader people trust with a large disk from one they do not. The second is that the diagnostic export redacts cookies, tokens, email addresses, user identifiers and local user paths. That is a deliberate design decision about what a support log may contain, and it is the reason the export can be attached to a bug report. The disclaimer at the end of the README is short and worth reading as a scope statement rather than boilerplate. It says the software only provides video parsing and does not provide resource uploading or server storage, that it only parses content from Bilibili, that format repair, segment joining or hardware acceleration may involve transcoding and index rebuilding, that the copyright of parsed content belongs to the original authors and that content providers and uploaders should bear the corresponding responsibility, that all content is for learning and exchange and must not be used without authorisation, and that the author accepts no responsibility for copyright problems arising from use. ## The downloader: segment planning, parallel connections, validated resume The downloader description in the README is one sentence, but it contains three separate engineering problems. The first is planning. The built-in downloader plans the file segments in order before it starts, so the tool knows the shape of the file it is going to assemble before it fetches anything. That matters for the DASH style formats Bilibili uses, where a video is a set of separate video and audio streams, because the segments have to be ordered and matched to produce one playable file rather than a directory of fragments. The second is parallelism. Once planned, the download uses multiple connections in parallel, and the README's phrase is 多连接并行下载. For a media file this is the difference between a download that takes minutes and one that takes an hour on a domestic connection, and it is also where a naive implementation creates the most problems, because parallel ranges have to be stitched back together in the right order. The third is resume, and it is the one the README is most careful about: the downloader saves a strictly validated resume state. Strictly validated is doing real work in that sentence. A resume file that is trusted blindly can produce a file that is the right length and the wrong content, and the usual failure is a truncated or corrupted download that the tool believes is complete. Validating the state before trusting it means the tool can tell the difference between a download it can continue and one it has to start again, which is the difference between a resumable downloader and one that quietly produces broken files. Combined with the cleanup behaviour on cancellation, this is the part of the design that determines whether the tool is usable for large archives, and it is the part that has to be right rather than merely present. ## FFmpeg in the package, and the hardware encoder fallback The runtime story is unusual and deliberate. The release package already contains .NET and FFmpeg, so there is no separate runtime to install. The download archives are, in effect, self contained, and the tool does not depend on whatever FFmpeg happens to be on the machine. That choice has a cost, and the repository shows it in the release list. Among the recent tags are v1.6.1 from 2026-10-20, v1.6.0 from 2026-10-19, and a third release whose name is an FFmpeg autobuild, ffmpeg-btbn-autobuild-2026-10-18-13-01, published on 2026-10-19. So FFmpeg is built in continuous integration and published as its own artefact, which means the binary that ships inside the application is a specific, reproducible build rather than a dependency resolved at install time. The README also spells out the FFmpeg usage policy. FFmpeg prefers a lossless stream copy, so the normal path for a download is a remux without re-encoding, which is fast and does not degrade the file. Transcoding only happens when it must, and the description of what is listed in the disclaimer is consistent with that: format repair, segment joining and the hardware acceleration path may involve transcoding and index rebuilding. The hardware path has an explicit fallback. When a transcode is required, the tool probes for an available hardware encoder, and if that fails it records the reason and falls back to software encoding. Recording the reason matters, because a silent fallback produces a slow download with no explanation, while a recorded reason tells the user why the machine is taking minutes instead of seconds. For the Windows package there is one operational detail that causes a lot of support traffic. The ZIP has to be fully extracted to a new directory before it is run, and the ffmpeg subdirectory must be kept next to DownKyi.exe. If the program reports that files are incomplete, the README's instruction is to download the official release again and extract it fully, rather than dropping individual executables into place by hand. ## Data directories, portable mode and the redacted diagnostics export The application keeps its state in a platform specific location, and the README lists the defaults: ```text Media Logs Storage Config Cache ``` Those five subdirectories have fixed roles. Media is the default download directory, Logs holds the application and diagnostic logs, Storage holds the SQLite download database, Config holds settings and login information, and Cache holds images and runtime cache. The parent path follows the platform convention: %APPDATA%\DownKyi on Windows, ~/Library/Application Support/DownKyi on macOS, and $XDG_CONFIG_HOME/DownKyi on Linux, which is usually ~/.config/DownKyi when the variable is not set. Two environment variables change that. Setting DOWNKYI_DATA_DIR specifies a different data root, and setting DOWNKYI_PORTABLE=1, or placing a portable, a .portable or a DownKyi.portable file in the program directory, enables portable mode. The second mechanism is the interesting one, because it means a USB stick carries the whole application state, which is how the tool is used on a shared or lab machine where writing to the user profile is not wanted. The diagnostics section explains what the exported log is for. It can be used to look into network requests, downloader start and stop and resume, subtitle, danmaku and cover handling, audio and video merging, and cleanup at exit. The export filters out ordinary debug noise and masks sensitive information, which is the pair of properties that makes an exported log attachable to an issue. Login works the same way round. When the QR code scan is not possible, the README says you can paste the Cookie header from an already logged in Bilibili request, and the program will reuse the QR login save and validation flow, restoring the original credentials if validation fails, the network errors, or the operation is cancelled. The cookie is kept in the encoded form it is transmitted in, and the official Login file is managed by the program rather than edited by hand. ## Release packaging, verification files and the developer entry points The download section is where the release engineering shows. The packages are named by platform: DownKyi-*-win-x64.zip and DownKyi-*-win-x86.zip for Windows, DownKyi-*-osx-arm64.dmg and DownKyi-*-osx-x64.dmg for macOS, and AppImage, deb and rpm for Linux. There is also a verification route, and it is unusual enough to mention. Alongside the later formal versions, the project provides a DownKyi--verification.zip that collects the .sha256 files and the publish-manifest-*.json files that originally accompanied each package. To verify, you extract that ZIP into the directory where you downloaded the package and use the corresponding files to check the package hash and the individual file contents. That is a two level check, the archive as a whole and each file inside it, and publishing the manifests separately means the reference data is not simply whatever sits next to the installer you were handed. The developer entry points are described with the same care, and the rule is that each kind of question has one owner. AGENTS.md covers changing the protocol, the navigation order and the prohibited items. ARCHITECTURE.md covers the current topology, the boundaries, the invariants and the executable guard rails. docs/maintenance.md holds the maintenance cards organised by domain, docs/testing/README.md covers the test infrastructure and the classification of failures, and docs/operations/verification-and-rollback.md gives the formal verification and rollback commands. Work itself is tracked in a single GitHub project board with priority, status, ordering, and the states draft, pending verification, pending decision, in progress and done, with the background, scope, evidence, acceptance criteria and pull request links kept in the corresponding issue. Running it locally needs the .NET 10 SDK, and the command is: ```powershell dotnet run --project .\DownKyi\DownKyi.csproj ``` The repository also carries a .gitleaks.toml, which is a secret scanning configuration, and cliff.toml, which is the configuration for git-cliff and therefore for generating the changelog from commits. ## Conclusion Adopt DownKyi Core if you need to download and archive video you have the right to keep, and you want the tool to run on Windows, macOS and Linux from the same codebase with the runtime and FFmpeg already inside the package. Do not adopt it as a general purpose media grabber, since the README's own disclaimer says the content is for learning and exchange only and that the copyright of parsed content stays with the original authors. Verify first which platform package you want, because the Windows archive has to be fully extracted into a new directory with the ffmpeg subdirectory kept beside the executable, that you can accept that release packages bundle a .NET runtime and an FFmpeg build rather than using what is on the machine, and that the diagnostics export is safe to share, since the README says it masks cookies, tokens, email addresses, user identifiers and local user paths. ## FAQ ### What is DownKyi Core? It is a cross-platform Bilibili video download tool based on the Windows version of DownKyi and on Avalonia, using .NET 10, the Microsoft Generic Host, Microsoft DI and CommunityToolkit MVVM. It parses video, collections, bangumi, courses, favourites, history and watch-later entries, and downloads audio, video, covers, danmaku, subtitles and AI subtitles. ### What are the system requirements for DownKyi Core? There is no separate runtime to install, because the release packages already include .NET and FFmpeg. Windows packages are ZIP archives that must be fully extracted to a new directory with the ffmpeg subdirectory kept beside the executable, macOS packages are DMG files for arm64 and x64, and Linux packages come as AppImage, deb and rpm. ### Where does DownKyi Core store its data? By default the data root is %APPDATA%\DownKyi on Windows, ~/Library/Application Support/DownKyi on macOS and $XDG_CONFIG_HOME/DownKyi on Linux, with Media, Logs, Storage, Config and Cache subdirectories. Setting DOWNKYI_DATA_DIR changes the root, and DOWNKYI_PORTABLE=1 or a portable, .portable or DownKyi.portable file in the program directory enables portable mode. ### How does DownKyi Core download videos in parallel? The built-in downloader plans the file segments in order first, then downloads them over multiple connections in parallel, and it saves a strictly validated resume state. Deleting a running task stops the downloader and cleans up the media and temporary files already produced. ### Can I verify a DownKyi Core release package? The project publishes a DownKyi--verification.zip that collects the .sha256 files and the publish-manifest-*.json files that accompanied each package. Extract it into the directory where you downloaded the package and use those files to check the package hash and the individual file contents. ## Sources - [crazysmile-PhD/downkyicore on GitHub](https://github.com/crazysmile-PhD/downkyicore) - [Issues](https://github.com/crazysmile-PhD/downkyicore/issues) - [License: GPL-3.0](https://github.com/crazysmile-PhD/downkyicore/blob/main/LICENSE) - [README](https://github.com/crazysmile-PhD/downkyicore/blob/main/README.md) - [Releases](https://github.com/crazysmile-PhD/downkyicore/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/crazysmile-phd-downkyicore