Hi, 这是开源弹幕系统改进项目的第一次周报。
*项目规划 * - 第一阶段项目研发 - 07/01 - 07/07 调研目前开源弹幕方案,研究 Comment9 和 danmaQ ,确定技术路线,兼顾性能,并设计弹幕服务端和弹幕客户端之间的通讯逻辑✅ - 07/08 - 07/15 重构弹幕绘制逻辑,使其同时兼容客户端和 Web 端,并能达到当前主流弹幕网站(Bilibili)的显示能力,并具有较高的拓展能力,基本实现弹显示功能,并完善设计文档✅ - 07/16 - 07/31 构建弹幕服务端和弹幕客户端之间的通讯逻辑,实现服务器推送弹幕的正确接受与绘制,增强弹幕客户端在不稳定网络下的故障恢复能力 - 08/01 - 08/15 在 Comment9 基础上升级弹幕服务端,完善各种功能并实现可拓展的弹幕接入(包括网页、微信、Telegram等),打通服务端与客户端,最终打包成docker实现一键化部署 - 第二阶段项目研发 - 08/16 - 09/30 基于第一阶段考核结果做相应改进,整理项目代码,实现语言国际化,完善相关文档,增强代码的易拓展性,实现版本的自动化打包发布,并提交软件包到 dockerhub 及 AUR 等仓库,进一步实现易用性。 *07/01 - 07/07* - 尝试跑通 gdanmaku-server 失败,用 nginx 反代解决 demo ssl证书问题,尝试使用 danmaQ - 修复了 danmaQ 部分显示、编译问题 - 基于需求和开源弹幕方案现状,保持当前的弹幕显示模式(滚动、顶部、底部,由于弹幕实体无法被完全穿透),增强颜色和字体大小等功能,下一阶段准备基于 CCL 协议设计实现,Web播放器基于 Danmaku.js 修改 <https://github.com/jabbany/CommentCoreLibrary> *通讯逻辑* - 播放器端预计有QT和web播放器、Web 弹幕墙(硬件弹幕机由于无法登陆 ssh 暂时放弃),*主动* 和服务端建立HTTP/WS连接,以WS为主,前期使用密码进行简单鉴权 - 服务器端采用Nodejs,触发式存储弹幕和建立连接,方便采用*Serveless形式*部署,使用web播放器实现在线预览和审核 - 弹幕发送器 前期 先支持网页(单用户)和WEB API(带管理员鉴权的多用户),后面通过 WEB API 接入微信、TG,外置探测程序接入Bilibili,接口保证拓展性 *核心逻辑* 弹幕发送器发送→(发送器/接收器生成uuid:基于ip或者管理员鉴权认定的用户唯一id)→服务器接收→人工审核→自定义二次处理函数(比如过滤黑名单、只输出同传字幕)→生成URL HTTP+WS提供给播放器使用 直播结束后可以基于时轴生成备份文件。 *07/08 - 07/15* *协议设计* 弹幕分为实时(直播)弹幕和回看弹幕,实时弹幕采用WS与HTTP混合,WS优先的协议设计;回看弹幕采用HTTP请求返回分页数据。 API 尽量保证与 Comment9 中原有设计相一致,HTTP部分使用 express,WS使用 Node.js 实现的 Socket.IO <http://socket.io/> v4,同时保证其在QT中的兼容性。 *弹幕设计* 基于 CommentCoreLibrary 以及现状做的弹幕结构设计,前期保留拓展项目接口。 HTML5播放器已经有了基本可用的实现 <https://github.com/jabbany/CommentCoreLibrary> *API 设计* 管理相关API 需要 session 鉴权,使用HTTP接口;活动作为弹幕盒载体,使用HTTP接口;审核接口考虑效率使用Blacklist(效率不高)+ 自定义函数,考虑安全性的话可以让用户提供外置API接口。 *弹幕接口 - WS/HTTP* 按照核心逻辑设计 API 弹幕发送器发送→(发送器/接收器生成uuid:基于ip或者管理员鉴权认定的用户唯一id)→服务器接收→人工审核→自定义二次处理函数(比如过滤黑名单、只输出同传字幕)→生成URL HTTP+WS提供给播放器使用 WS (SOCKET.IO) 使用 token 鉴权 */comment/:token/?param (param用于过滤mode)* Client: push JSON 发送封装好的弹幕 Client: pull 获得最近 5s 的弹幕 Client: pull JSON 获得自定义时段的弹幕 Server: JSON 自动发送最新的弹幕 HTTP ALL /comment/wechat/:token GET /comment/player/:token/pull?param POST /comment/player/:token/push *关于 Token 安全性* 当前的设计是不同权限给不同 Token ,还算合理。 *弹幕审核* 初步设计每个活动归一个用户所有,这个用户拥有审核的权限,并且可以生成审核专用token。 *下一阶段:* - 整合 Socket.io <http://socket.io> 和 QT5,基本就合并CMAKE,能跑通 Node.js 和 QT 间通讯就行,这样基本保证稳定连接。 - 实现MangoDB下的各API功能,再简单接入QT5和HTML5播放器。 - WSS/TLS 应该可以直接反代套在最外层,先不考虑。 *下下阶段:* - 接入 Wechat & Telegram,用户 Token 管理(考虑 Wechat 接口解耦合) - 设计简单用户管理&前端页面 *Papersnake* -- 您收到此邮件是因为您订阅了 Google 网上论坛的“TUNA 主邮件列表”群组。 要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到tuna-general+unsubscr...@googlegroups.com。 要在网络上查看此讨论,请访问 https://groups.google.com/d/msgid/tuna-general/1f12dd8a-8970-4aad-bdb4-1b31b2d47d5bn%40googlegroups.com。