bilibili_live_stream_code hands you a stream key so OBS can push directly

Why a streamer would bypass the official live client

The first purpose of this tool is stated in the README as obtaining a third party streaming key before going live, so that you can skip the official Bilibili live client and broadcast directly from software such as OBS. That is a workflow decision, not a technical one. Anyone who prefers OBS for scene control, recording or audio mixing still has to satisfy the platform's own login, broadcast and category rules, and those rules live behind the official client. This tool automates that side of the session and leaves the video pipeline alone. The second purpose is defining the title and the category at the moment you start broadcasting, and the third is monitoring danmaku, including entrance messages and gift messages, and being able to send danmaku yourself. So the scope is a broadcaster control panel rather than a streaming server, and the tool never sees your video, only the session around it.

The login and start-of-broadcast flow

The usage tutorial lists the steps in order. You scan a QR code to log into the Bilibili account. You fill in the title and pick the category, and on first use you have to click the sync control before the category list is populated. You click the button that starts the live broadcast. You copy the link and the stream key from the stream key area into a third party streaming tool. In the danmaku view you can watch and send danmaku. And you end the broadcast by clicking the stop button or by closing the software. That last point is the one that causes the most confusion, so the README flags it in bold: stopping the broadcast in OBS does not stop the broadcast. The session lives on the platform side until the tool tells it to end, which means a mistimed stop button in your encoder leaves you on air with no video. The tool's own stop control, or closing it, is what actually closes the room. Supported stream key types are RTMP and SRT.

A Python shell wrapping a web frontend

The technical shape is a desktop application built from two parts. The backend is Python, and the frontend is a separate project built with Node, which the README then bundles into the Python executable. The dependency list in pyproject.toml shows the shell: pywebview for the webview window, pywebview's Qt side supplied through qtpy, PyQt5 and PyQtWebEngine, pystray for the system tray, requests and aiohttp for the two network styles, protobuf and brotlipy and brotli for the protocol handling, certifi for certificates, cffi, Pillow and pyinstaller for packaging. The README notes that on Linux the program uses the bundled Qt libraries to run the tray, and recommends Ubuntu 20.04 or later or another mainstream distribution. It also warns about a specific startup failure, the message about the Qt platform plugin xcb not being found, with the fix given as installing libxcb-xinerama0, libxcb-cursor0 and libnss3. Running from source additionally needs PyGObject pip installed, and the README is clear that without it the program still runs normally, it just has no tray icon.

Building the frontend and the backend from source

The build instructions are ordered and the environment requirements are Python 3.9 or newer and Node.js 18 or newer. You clone the repository and enter it:

git clone https://github.com/ChaceQC/bilibili_live_stream_code.git
cd bilibili_live_stream_code

The frontend is built first, because the Python side packages its output:

cd frontend
npm install
npm run build
cd ..

Then the Python dependencies are installed:

pip install -r requirements.txt
pip install pyinstaller Pillow

An icon step is optional and platform specific. On macOS the .ico is converted with the built-in sips and iconutil tools, and on Linux with Pillow:

python -c "from PIL import Image; Image.open('bilibili.ico').save('bilibili.png')"

Note the mismatch worth checking before you start. The README lists Python 3.9 as the minimum, while pyproject.toml declares requires-python as >= 3.12, and the packaged version there reads 2.3.13 while the published release list tops out at 2.3.16. The metadata is the stricter of the two, so plan for 3.12 or newer.

PyInstaller produces a different bundle per platform

The packaging step is a PyInstaller invocation per operating system, and the differences are not cosmetic. The Windows build adds data with a semicolon separator, uses the .ico directly and disables the console:

pyinstaller main.py --name BiliLiveTool --onefile --add-data "frontend/dist;frontend/dist" --icon "bilibili.ico" --noconsole

The macOS build uses a colon separator, expects the .icns produced by the icon step, hides the backend module and runs windowed:

pyinstaller main.py --name BiliLiveTool --onefile --add-data "frontend/dist:frontend/dist" --icon "bilibili.icns" --hidden-import _cffi_backend --windowed

The Linux build is the longest, because it also has to bundle the icon and hide the Qt and webview modules:

pyinstaller main.py --name BiliLiveTool --onefile \
 --add-data "frontend/dist:frontend/dist" \
 --add-data "bilibili.ico:." \
 --icon "bilibili.png" \
 --hidden-import _cffi_backend \
 --hidden-import cffi \
 --hidden-import qtpy \
 --hidden-import PyQt5 \
 --hidden-import webview.platforms.qt

After packaging, the executable sits in the dist directory. The onefile flag means a single file, which is convenient for distribution but means the whole Qt runtime is unpacked at launch.

The macOS story and the Tauri rewrite

Two limitations are stated plainly. The first is licensing of intent. The project carries a declaration that the program is for learning and exchange only, that commercial or other use is prohibited, and that problems caused by improper use are the user's own responsibility. That is a self-imposed constraint on a tool whose main attraction is commercial streaming, and any streamer planning to monetise a channel has to take it seriously rather than treat it as boilerplate. The second is platform coverage. The author says plainly that they cannot afford a Mac, that Mac users should test it themselves, and that pull requests are welcome once it runs on that platform. The README also points to a community rewrite of the project, Zeppelinpp/bilibili-streamer, which moved the stack from Python plus PyInstaller to Tauri 2.x with Rust, React 18 and TypeScript, and completed the macOS side including the tray, window exit and dark mode. That is the more interesting option for a macOS user today, and it is a different architecture rather than a different skin.

Apache-2.0 licensing and a fast patch release rhythm

The licence is Apache-2.0, with the text in LICENSE.txt at the root of the repository, which is a permissive grant and a contrast to the separate usage declaration mentioned above. The repository is a monorepo of two halves: a backend/ directory for the Python side, a frontend/ directory for the web interface, plus main.py at the root as the entry point that PyInstaller consumes, along with pyproject.toml, requirements.txt, a VERSION file, the bilibili.ico icon and a.github/ directory for workflows. The release list shows a rapid patch cadence on the 2.3 line, with v2.3.14 and v2.3.15 both on 2026-05-18 and v2.3.16 on 2026-05-20, and the last push to the repository was on 2026-10-22, with the repository not archived. That cadence suits a tool that has to keep pace with a platform whose web endpoints change without notice, which is the main operational risk of depending on it at all.

Editorial conclusion

bilibili_live_stream_code suits a streamer who wants to drive a Bilibili broadcast from OBS or another third party encoder rather than from the official live client, and who needs danmaku and gift monitoring in the same window. It is a poor fit for commercial operation, since the project states it is for learning and communication only and disallows commercial or other use, and it is a poor fit for macOS, which the author could not test and where a separate community rewrite exists. Verify first that the version in pyproject.toml, which reads 2.3.13, matches the release you actually download, that your Python is 3.12 or newer as pyproject.toml requires rather than the 3.9 the README states, and that you understand the stream keeps running until you press the stop control in the tool.

Frequently asked questions

Official sources

1. ChaceQC/bilibili_live_stream_code on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases