bili2text: Bilibili Video Transcription for Local and Cloud Workflows

What bili2text solves and who it targets

bili2text addresses a specific media-handling problem: converting a Bilibili video into searchable text without requiring the user to manually download the video, extract its audio, and run a separate speech-recognition program. The supported input forms are a Bilibili link, a BV identifier, or a local media file. The workflow is aimed at people who already have a video URL or file and need a transcript rather than a video player.

The project serves several kinds of users. A command-line user can invoke `tx` or `batch` directly. A user who prefers a browser can use the optional Web interface, while server mode is aimed at local network or container-style use. The README also describes a desktop window, so the project is not restricted to people comfortable with terminals. The choice of transcription engine matters because bili2text supports both local models and a cloud service. That makes the project relevant to users who prefer offline processing, users interested in Chinese speech recognition, and users who prefer to send audio to a hosted API.

It does not claim to be a general video editing suite, subtitle editor, or translation system. Its documented scope is transcription. The output is described as a text transcript, and the project does not document speaker diarization, translation, subtitle formatting, or editing workflows in the README.

The download, audio, and transcription pipeline

The documented pipeline has four stages. First, bili2text accepts a Bilibili URL, BV number, or local file. For remote Bilibili input, the project uses `yt-dlp`, which is listed as a core dependency. The README does not expose the internal module responsible for download handling, so exact downloader options and cache behavior are not specified.

Second, the project extracts audio from the downloaded or supplied media. Third, the selected provider runs speech recognition. Fourth, bili2text produces a text transcript. Provider selection is user-controlled through the `--provider` option, with Whisper and a model such as `medium` shown in the README example.

The project separates the core package from optional functionality. Core dependencies include `InquirerPy`, `rich`, `tqdm`, `typer`, and `yt-dlp`. Whisper adds `openai-whisper`; SenseVoice adds `funasr-onnx`, `jieba`, and `torch`; the Volcengine option adds `requests`. Web and server extras add FastAPI, Jinja2, Python multipart support, and Uvicorn. This dependency split means that a local Whisper or SenseVoice installation can carry a substantially different dependency footprint from a Web deployment or a cloud API configuration.

The repository's package layout and `pyproject.toml` identify `src/b2t` as the wheel package and `b2t.cli:main` as the console entry point. That indicates a packaged CLI architecture rather than a single standalone script, although the README does not document internal data models or transcript storage conventions.

Installing bili2text with uv and running the first transcription

The README requires Python 3.10 to 3.12 and `uv`. The base installation installs core dependencies. Whisper and the Web interface require optional extras. The initialization wizard records language, engine, and feature choices, then prints the installation command needed for the selected setup.

Start by cloning the repository and syncing the base environment:

git clone https://github.com/lanbinleo/bili2text.git
cd bili2text
uv sync

If the first use is with Whisper and the Web interface, install those extras before initialization:

uv sync --extra whisper --extra web

Run the configuration wizard:

uv run bili2text init

After selecting an engine, transcribe a Bilibili URL through the `tx` command:

uv run bili2text tx "https://www.bilibili.com/video/BV1kfDTBXEfu"

To select Whisper and its `medium` model explicitly:

uv run bili2text tx "BV1kfDTBXEfu" --provider whisper --model medium

For several inputs, use `batch` with positional arguments:

uv run bili2text batch "BV1kfDTBXEfu" "https://www.bilibili.com/video/BV1xx411c7XD"

The README also accepts one input per line in a file through `--file sources.txt`. The command reference names `transcribe` as `tx`, `bootstrap` as `init`, and the Web command as `ui`; aliases are part of the documented CLI surface.

Web, server, and desktop interfaces have different operating costs

bili2text extends the CLI with three optional interface paths. `ui` starts a Web interface in a browser. `srv` starts service mode, which the README says is suitable for Docker or local-network deployment. `win` starts a desktop window. These commands do not remove the core transcription pipeline. They change how a user submits or launches the work.

The Web dependencies are separated into the `web` extra, and the server dependencies are listed separately as `server`, although both include FastAPI, Jinja2, Python multipart support, and Uvicorn. The repository's `pyproject.toml` also defines a `window` extra with no listed packages. That suggests the desktop entry point has a different implementation path, but the README does not specify its framework or platform support.

The server command includes a documented host and port example:

uv run bili2text srv --host 0.0.0.0 --port 8000

The README explicitly warns that the project has not yet optimized for long-running Docker or server operation and says to use the local version for now. This is an important adoption constraint. A team should not read the presence of `srv` as evidence of production server readiness. Authentication, request limits, job persistence, concurrency behavior, storage cleanup, upload limits, and recovery after process failure are not documented in the README.

The Web and desktop interfaces may improve access for non-terminal users, but they also create a larger surface to configure and secure. The project documents no deployment-hardening instructions for those interfaces.

Provider choice and transcription limits

Whisper and SenseVoice are local-model options, while Volcengine is identified as a cloud API. Local processing can avoid sending media to a remote service, which is a relevant distinction for private or sensitive material, but the exact hardware, memory, model download, and acceleration requirements are not documented in the README. SenseVoice adds `torch` to the project dependencies, so its installation cost should be considered before selecting it.

The Volcengine option adds `requests` and depends on a commercial speech-recognition service. The README does not document the required environment variables, credential file, endpoint configuration, upload limit, pricing, retention policy, or request format for this provider. The initialization documentation says that the wizard selects the engine and feature choices, but it does not publish a complete provider configuration schema. Users who choose the cloud path may therefore need information beyond the README before they can assess the service contract.

Whisper supports model selection through the CLI. The example uses `medium`, which is a larger model than the small model and may have different resource requirements, but the project does not state expected memory use or processing time. `doctor` is documented as an environment check, yet the README does not enumerate which dependencies, codecs, models, credentials, or network paths it verifies.

The tool is also constrained by media access. A local file can fail if it is not a supported media format, and a remote Bilibili URL can fail if the platform changes or the user lacks access. The README does not document supported audio and video codecs, maximum file size, timeout behavior, or retry behavior.

A practical comparison with a separate download and transcription stack

The clearest alternative is a manual pipeline: use `yt-dlp` to download a Bilibili video, use a separate media tool to extract audio, and invoke Whisper or another speech-recognition program separately. That approach requires more manual steps, but it gives the operator direct control over download options, intermediate files, model selection, and output handling. It can also be adapted for media formats that bili2text does not document.

bili2text reduces the number of handoffs by exposing those stages through `tx`, `batch`, and the initialization wizard. Its batch command accepts multiple links, BV numbers, or local paths, and its `--file sources.txt` form keeps a list outside the shell command. That is the main operational difference from assembling the same stages one by one.

The trade-off is abstraction. A manual pipeline exposes each tool's configuration and lets an operator replace one stage independently. bili2text offers a focused interface, but the README does not document how to configure external media tools, preserve intermediate audio, choose output destinations, or select advanced transcription parameters beyond the shown `--provider` and `--model` options. Teams with established media-processing scripts may gain less from it than users who want one CLI entry point.

Maintenance, upgrades, licensing, and the adoption boundary

The repository is not archived, and its last push was on 2026-06-16. The latest listed release is `sv-1.0.0` from 2023-11-25, while `pyproject.toml` identifies the current project version as `0.3.0`. The release label and package version should not be treated as the same versioning signal without checking the changelog and repository history.

The project uses a Python version range of `>=3.10,<3.13`, a `uv.lock` file, and optional dependency groups. Upgrade cost includes more than changing application code. Operators must account for Python compatibility, `uv` resolution, local model packages, API credentials, and external Bilibili or cloud-service changes. The README links to `CHANGELOG.md` and `docs/DEVELOPMENT.md` for project-specific update information, but it does not summarize migration procedures or upgrade guarantees.

The declared license is MIT. That identifies the project's licensing model, but it does not determine whether a particular Bilibili video may be downloaded, stored, or transcribed. The README explicitly tells users to follow applicable copyright law and platform rules and to confirm that they have the right to download and transcribe the content. Those are separate checks from the software license.

Adopt bili2text when a local, repeatable transcription command is more useful than control over every intermediate media operation. Do not adopt it as a ready-made long-running server, a fully documented API service, or a general batch video-processing platform. The first verification should be `uv sync` with the exact extra required by the chosen engine, followed by `uv run bili2text doctor` and one known Bilibili or local input whose processing rights are clear. The concrete deciding point is whether that documented pipeline produces the needed transcript without requiring undocumented server or provider configuration.

Editorial conclusion

bili2text fits users who need repeatable Bilibili transcription from a terminal and can provide Python 3.10 to 3.12, `uv`, media access, and the dependencies for their chosen engine. It is a poor fit for teams expecting a documented, production-ready long-running server deployment. Before adoption, verify the selected provider's dependencies, model or API requirements, local copyright permissions, and the repository's current compatibility with your Bilibili workflow.

Frequently asked questions

Official sources

1. Issues
2. lanbinleo/bili2text on GitHub
3. License: MIT
4. README
5. Releases