Bilive 開源 B 站直播錄製管線，從錄影、燒彈幕到投稿全自動

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Bilive 是一位中國開發者以 Apache-2.0 授權開源的 Python 專案（GitHub 上 timerring/bilive，截至 2026 年 9 月約 3,289 顆星），把 B 站直播的錄影、彈幕燒錄、字幕、自動切片到投稿，串成一條免人看守的背景管線。名字本身就是縮寫梗：Bilibili Intelligent Live-In Velocity Engine。對經營錄播帳號的人來說，它想把「掛機錄影、後製、上傳」這整組雜事壓縮成一個裝好就放著跑的服務。

Pin

它最值得先講的設計，是「省空間」這四個字的實作方式。檔案處置的邏輯是一條刪除鏈：彈幕燒進影片後立刻刪掉原始檔，上傳成功後立刻刪掉燒好的成品，就連損壞讀不出來的檔案，出廠設定也是直接刪除不留現場。同一段影片在處理期間會短暫同時存在原始檔與燒好版，上傳成功之後就一份都不剩；正常流程下唯一持久的副本，存在 B 站你的帳號裡。這個取捨對錄播帳號的經營者很合理，但對想自留原片的人是必須先知道再裝的事。

下面把這條管線的每一站拆開看：檔案怎麼被處理、三個 AI 功能各自的雲端代價、B 站帳號憑證放在哪裡、以及整個專案的維護時間線停在哪個日期。安裝教學官方文件已經寫齊，這裡補的是官方文件不會主動告訴你的判斷材料。

一支錄影檔在 Bilive 裡的一生

錄製端用的是第三方開源錄製器 blrec，Bilive 直接把它的 beta 版安裝包隨 repo 附帶。出廠的 settings.toml 已經寫好兩個示範房間號（173551 與 7734200），裝起來就會開始監聽錄製，實際使用前記得換成自己要追的房間。直播串流以 FLV 格式收下、每 30 分鐘切一段、自動轉存成 MP4 落在以房間號命名的資料夾，同時把彈幕（含付費留言、禮物、上艦資訊）存成 XML 伴檔。

另一頭有個掃描程序每 120 秒巡一遍影片資料夾，看到新的 MP4 就接手處理：先用 ffprobe 讀出解析度，把同段 XML 彈幕轉成 ASS 字幕檔、依解析度換算字級與邊距，接著交給 ffmpeg 把彈幕燒進畫面，輸出「有彈幕版」，然後在本地 SQLite 上傳佇列裡插一筆紀錄。

Pin

上傳工作者自己有一套判斷：先查你 B 站帳號最近的 20 部影片，標題對得上一場直播的前段，就把新檔當作同一部影片的新分 P 附加上傳；對不上就開一部新影片。上傳走 CDN 線路自動探測。而成功回報之後緊接著執行的，就是刪檔。

刪除鏈在程式碼裡的位置很明確。src/burn/render_video.py 在燒錄完成後，對原始 MP4、XML、ASS、SRT、JSONL 五種檔案逐一呼叫刪除，沒有任何條件判斷；src/upload/upload.py 在上傳成功後刪掉燒好的成品檔；遇到 MOOV 索引損壞導致 ffprobe 讀不出資訊的影片，出廠值 reserve_for_fixing = false 會把佇列紀錄與檔案一起刪掉。換句話說，整條管線的目標狀態是「磁碟永遠是空的」，錄播的最終歸屬只有 B 站。上傳失敗時檔案會被鎖進佇列反覆重試，留著的是燒好版；真正的清空只發生在上傳成功之後，而那之後若 B 站端出事（審核下架、帳號被限權），本地已經沒有任何備份。

這個行為其實來自社群需求：專案 issue 區討論最熱烈的一條功能請求（17 則留言），要的正是「分段先上傳、傳完就刪本地、下播後統一發布」，其中分段上傳與傳完即刪已是現行預設；討論串裡另想要的「下播後統一發布」並未實作，實際行為是邊錄邊傳，第一段傳完就掛上網路。開發者把使用者要的自動化做成了預設值，這條刪除鏈本身則沒有設定開關。

還有一個安靜的角落值得知道：彈幕處理整段被 try/except 包住，一旦轉換出錯，程式會退回預設字級照樣燒錄、照樣排隊上傳，你會拿到一部沒有彈幕的影片，原因只留在 log 裡。對把彈幕當核心賣點的工具來說，這是安靜的降級。

處理模式有三種，差別只在開了字幕之後：pipeline 模式讓語音辨識與渲染並行、邊錄邊傳，是宣稱「沒下播就能出錄播」的來源；append 模式把辨識與渲染改為先後執行，速度慢約四分之一，對顯示記憶體要求較低；merge 模式等整場錄完再合併處理，上傳完整版而不是分 P。前述「正常流程照刪」的行為在三種模式都一樣，差別只是刪之前的處理順序。

整條管線拆開看還有一個結構特徵：四個關鍵零件都是作者自己的開源專案，彈幕轉換 DanmakuConvert、上傳 bilitool、切片 auto-slice-video，外加一套循環推流工具 looplive，唯一的外部大件是錄製器 blrec，以 beta 版安裝包的形式隨 repo 附帶。一人工具鏈的好處是介面彼此咬合、文件口徑一致，每一段都能單獨拿來用（bilitool 就可以獨立 pip 安裝當指令列工具）；風險則是每一段的維護節奏都繫在同一個人身上，這點後面維護時間線會再回來。

失敗的通知管線預設也是關的。設定檔裡 email、Telegram、Bark 等六種通知管道全部停用，磁碟空間回收器也預設不啟用（空間檢查門檻設 10GB，但只是檢查）。也就是說這條管線出事的時候不會主動來找你，錄了沒傳、傳了失敗、彈幕燒失敗，都要自己翻四個分類的 log 或上 B 站後台對帳。要把它當生產工具用，先把至少一種通知打開是基本款。

彈幕這一層做得最扎實

彈幕轉換工具 DanmakuConvert 是作者自己的另一個開源專案，依影片解析度自動換算字級與邊距，付費留言（SC）、上艦、禮物都會記錄進 XML，出廠的禮物過濾門檻是人民幣 1 元，免費禮物預設不記，原始彈幕檔也會另存一份供日後重燒。

細節裡看得出這是長期實戰磨出來的程式。高金額的 SC 與上艦資料超過門檻時，程式會把價格欄位除以 1000 再寫回，註解直接連到彈幕渲染器 DanmakuFactory 的對應 issue，處理的是兩邊單位認知不一致的老問題；字幕生成對「幻聽」也有針對性防備，B 站開場主播常講的固定招呼語容易被語音模型重複聽成幻覺文字，程式偵測到就把該段字幕整行清空（這個過濾只存在雲端 API 路線，本機部署的路線沒有）。這類客製化只對一個平台有意義，也解釋了整個專案為什麼把場景收斂在 B 站一家身上。

字幕、切片、封面：三個 AI 開關，各自是一次雲端外送

先講清楚出廠狀態：字幕（asr_method = "none"）、自動切片（auto_slice = false）、封面生成（generate_cover = false）三個開關全部關閉，開箱不會動用任何雲端模型，也不會產生任何 API 帳單。

字幕有三條路。none 就是不做。api 是把整段影片的音軌抽出轉成 MP3 後整包上傳 Groq 雲端，跑 whisper-large-v3-turbo 模型；文件寫免費層上限 40MB，但 GitHub 上有使用者實測回報其實是 25MB，建議把錄製切段壓在 25 分鐘內，這個 issue 從 2025 年 5 月開到現在沒有結案。免費層同時限制了每天的小時數與請求次數，長期多房間錄播很容易碰到額度。語言提示在程式裡寫死成普通話，對粵語或英語為主的直播內容，辨識品質沒有任何保證。deploy 則是本機跑 whisper，條件是 NVIDIA 顯卡與至少 2.7GB 的顯示記憶體；Apple Silicon 與 arm64 伺服器因為相依的 triton 套件在該平台沒有發行版，本機路線走不通，同樣是開著的 issue。

自動切片的邏輯是用彈幕密度找高能片段，滑動視窗切出預設 60 秒的片段，然後把整段切片影片做 base64 編碼，連同提示詞送給視覺語言模型生標題。預設模型是阿里雲 DashScope 的 qwen2.5-vl-72b，也可以換智譜 GLM、Gemini 或 SenseNova。開這個開關的實質效果，等於把主播的片段內容整段寄到雲端服務商。封面生成同理：抓影片截圖送圖像生成模型，預設 MiniMax，可換十餘家服務，README 推薦的 DMXAPI 是商業聚合平台，文件裡附的連結帶推廣碼，註冊計費。

所以「免費全自動 AI 工具」的實際形貌是：錄影、彈幕轉換、燒錄、上傳全程本地（只連 B 站的 API），AI 三項全部是自帶金鑰的雲端服務且預設不開。README 的說法是十年前的電腦也跑得動，指的是這條不開 AI 的基礎路線；作者自己的測試機是 2 核 CPU、2GB 記憶體、無顯卡的雲端主機，外加一台 1 核 arm 的小機器。「理想情況下錄播與直播相差半小時內」也是作者自述的數字，第三方沒有量測背書，而作者自己在文件裡也提醒，決定錄播出片速度的瓶頸多半在上傳頻寬，不在渲染。

你的 B 站帳號住在明文 JSON 裡

投稿需要登入。作者自製的上傳工具 bilitool（同樣獨立開源）採 App 掃 QR Code 登入，登入後把 SESSDATA 與 bili_jct 這組等於帳號控制權的憑證，寫進程式目錄旁一個明文 JSON 設定檔；README 建議把根目錄的 cookie.json 匯入後刪除，但存在設定檔裡的那一份會一直留著。伺服器一旦被入侵，拿到的就是完整的帳號操作能力。

錄製端本身有網頁管理介面（埠 2233），必須先設 RECORD_KEY 環境變數當存取密碼。README 自己警告：有對外 IP 的主機若直接把這個埠映射出去，等同把 cookie 曝露給掃埠的人，要嘛不映射、要嘛自簽 HTTPS 再用防火牆限制來源。錄製畫質在不登入時是超清等級，要更高畫質得把 SESSDATA 填進錄製設定檔，官方的建議是錄製端維持不登入，把登入留給投稿端就好。

帳號憑證怎麼存，之前在 ShadowReplay 那篇已經把三層模型談過，這裡不重複；兩個工具的分工倒是清楚：ShadowReplay 走「直播還在播就能回放剪精華」的即時切片路線，Bilive 走 7×24 錄播歸檔的總路線，一個顧精華、一個顧全場。如果你要的其實是把多平台直播收進同一個桌面播放器，DTV 比較對口；要備份抖音創作者的完整內容，dYm 才是為此設計的工具。

維護時間線：程式碼停在 2026 年春天

這是部署前最該看的一段。時間線攤開：最後一個正式版 v0.3.1 停在 2025 年 4 月；最後一次真正的程式修復是 2025 年 7 月 1 日（修 blrec 彈幕介面的錯誤碼）；之後到 2026 年 4 月下旬只剩文件與工作流程調整，main 分支自此凍結。Docker 映像跟著停在 0.3.1，投稿用的 bilitool 子模組指向的版本停在 2025 年 4 月，上游 bilitool 之後也只有文件調整。附帶一提，作者在 2026 年 3、4 月動了倉庫的自動化工作流程，停用逾期自動關單，理由是半年沒動靜的 issue 曾被自動關掉；調整之後問題會一直留著攤在列表上，留著不等於有人處理。

2025 年 7 月中，有使用者回報投稿功能失效，原因是 B 站更新了投稿介面，舊介面打不通；這張 issue 截至 2026 年 9 月仍開著，唯一的回應是機器人 2026 年 1 月的逾期標記，兩個 repo 都沒有對應修復進到主線。要公平地講：一張開著的 issue 證明的是「有人遇到、沒人修」，不證明「所有人都傳不上去」，部署前自己小規模驗證投稿路徑就好。但時間線放在一起看的結論很樸素：B 站介面一改，這條管線的最後一哩就取決於一位業餘維護者的時間，而那段時間已經五個月沒有動靜。

其他開著的回報還有頻繁出現的「取不到直播串流」錯誤；至於虎牙、鬥魚、抖音、YouTube 之類的平台支援請求，全部無人回應，這個專案就是純 B 站的，跨平台需求不要指望它。

誰該裝、誰該繞開

兩個補充。reserve_for_fixing 改成 true 可以救回 ffprobe 讀不出來的損壞檔，但 Bilive 自身的燒錄到上傳刪除鏈沒有保留開關；真正能留原片的設定在錄製器那一層：settings.toml 的 delete_source 從 auto 改成 never，就會留下轉存 MP4 前的原始 FLV，內容等同無彈幕原片。另外 README 與出廠設定對預設模式的說法不一致：README 把最快的 pipeline 模式標成預設，出廠的 bilive.toml 實際寫的是較慢的 append 模式，這只影響需要 GPU 的字幕路線，但照文件建立預期時會有落差。

授權是 Apache-2.0，商用與改作都有空間；但 README 開頭的敬告寫得直白：錄製要先徵得主播同意、不要未授權商用、不要大規模錄製，帳號被封與法律後果都由使用者自負。預設的上傳簡介範本裡甚至內建了同義的免責句，每部錄播的影片說明都會自動帶上，等於把這條紅線刻進產品行為裡。

從拿到原始碼到跑起來

安裝本身不複雜：git clone 記得帶 --recurse-submodules（彈幕轉換、上傳、切片三個子模組都是作者自己的 repo）、pip 裝依賴、系統裝好 ffmpeg，Windows 使用者要走 WSL。不想碰 Python 環境的人用 Docker，映像分 CPU 與 GPU 兩版，登入方式是看容器 log 裡的 QR Code 掃碼。設定集中在兩個檔：bilive.toml 管燒錄與 AI 開關，settings.toml 管房間與錄製參數，錄製網頁支援熱修改。官方文件站（英文版）從安裝、換模型到常見錯誤都寫齊了，中文資訊主要在 README。

收尾一句話：Bilive 把錄播這件雜事自動化得相當徹底，代價是把「保留」的決定從你手上拿走。能接受影片只在 B 站、能接受 AI 功能等於雲端外送、能接受維護節奏看作者緣分，它是這個需求裡完成度最高的開源選項之一；三項有任何一項過不了關，先看 ShadowReplay，或者用自己的腳本把 blrec 加 ffmpeg 拼一條留檔的路。