直播开发
架构概览
本项目的直播集成功能采用分离进程架构,并依赖 WebSocket 代理端点 (/proxy-ws
)。
- 直播平台客户端 (独立进程): 连接特定直播平台 (如 Bilibili),监听事件 (如弹幕)。
- Open-LLM-VTuber 主进程: 运行 AI、TTS 等核心服务。
- 前端 UI (用户界面): 展示 Live2D 模型、接收用户 (直播间管理员) 输入、播放音频等。
- Live Platform Client: 直播平台客户端(如Bilibili)向代理发送弹幕消息(格式化为text-input)
- Frontend UI: 前端界面也向同一个代理发送用户输入和控制消息
- /proxy-ws: 核心代理端点,接收所有消息并进行转发和广播
- WebSocketHandler: 处理消息并与AI交互
- AI Agent: 生成回复
- 最终AI回复通过代理广播给所有连接的客户端(包括前端和直播客户端)
为了使直播弹幕能够被 AI 处理,并且 AI 的回复能够正确显示在前端,所有客户端(包括前端 UI 和 直播平台客户端)都必须连接到同一个 /proxy-ws
端点。
/proxy-ws
的作用 (ProxyHandler
):
- 统一入口: 为所有类型的客户端提供单一的连接点。
- 消息路由: 接收来自所有客户端的消息,并根据类型(如
text-input
,interrupt-signal
等)进行处理或直接转发给后端的WebSocketHandler
。 - 消息队列: 对
text-input
类型的消息(来自前端或直播平台)进行排队处理,确保 AI 顺序响应。 - 状态同步: 管理连接状态,例如标记对话是否活跃 (
conversation_active
)。 - 广播: 将来自后端
WebSocketHandler
的消息(如 AI 回复、状态更新)广播给所有连接的客户端。
1. 核心组件与数据流
以 Bilibili 直播为例,梳理弹幕输入到 AI 回应 的完整流程 (假设前端和 Bilibili 客户端都已连接到 /proxy-ws
):
- 观众 -> Bilibili 服务器: 发送弹幕。
- Bilibili 服务器 ->
run_bilibili_live.py
(独立进程):blivedm
库接收弹幕事件。 run_bilibili_live.py
->/proxy-ws
(主进程):BiliBiliLivePlatform
将弹幕格式化为{"type": "text-input", "text": "弹幕内容"}
并通过 WebSocket 发送给/proxy-ws
。/proxy-ws
(ProxyHandler
) ->ProxyMessageQueue
:ProxyHandler
接收到消息,因其类型为text-input
,将其放入消息队列 (ProxyMessageQueue
)。ProxyMessageQueue
->ProxyHandler.forward_to_server
->WebSocketHandler
: 当轮到此消息处理时,队列将其取出并通过forward_to_server
发送给WebSocketHandler
。WebSocketHandler
-> ConversationHandler: 接收到text-input
消息,触发对话处理逻辑 (_handle_conversation_trigger
)。- ConversationHandler -> ... ->
WebSocketHandler
: AI 返回回复文本流。 WebSocketHandler
->/proxy-ws
(ProxyHandler
): 将处理后的结果(文本、音频、指令等)发送回ProxyHandler
进行广播。/proxy-ws
(ProxyHandler
) -> 所有连接的客户端 (包括前端 UI):ProxyHandler
调用broadcast_to_clients
将 AI 的回复广播给所有连接到/proxy-ws
的客户端。
2. 关键接口与实现
2.1 LivePlatformInterface
(接口定义)
(位于 src/open_llm_vtuber/live/live_interface.py
)
所有直播平台客户端实现必须遵守的抽象基类。核心要求是实现 connect
方法以连接到代理端点 /proxy-ws
,并在 run
方法中实现监听平台事件并将事件格式化为 {"type": "text-input", ...}
后通过 _send_to_proxy
发送给代理。