前言

在接手项目时，前端开发人员已经编写了基于 Peer.js 和 Socket.io 的单点连线直播间。

这对于我后续的开发来说，是引导，也是桎梏。

成果

按时间顺序排序

成果名 优先级 耗时 产出物 评价
前端直播应用(单网页) 极高 无 直播主和观众两个页面 前端开发人员已完成的 demo
— 我在此时加入团队，并进行了方案变更 —
基于 srs 的媒体流服务器 低短 极长 部署文档 项目本身没有选择的技术栈，从当前的收益来看是值得的
前端直播应用(适配 srs) 极高 中等 多个直播相关页面 项目模块化的基础
— srs 项目改造初步完成 —
前端推拉流 sdk 高 短 sdk 项目 实用，且一直沿用
前端链接、媒体与信令管理工具包 极高 极长 三个工具类 非常实用，但是尝试多次打包到 sdk 中均未成功
— 项目管理级 —
录播与点播 高 中等 一个回调服务器、部署文档 实际效果不佳，技术选型限制了此部分的发挥
模块化组件 中 短 多个最小可用组件 模块化进程进展又快又好
— 项目模块化完成 —
项目集成与应用 高 极短 多个页面组件、多个后端接口 有了上述成果支持，项目集成较快

不足

问题名 优先级 呈现状态 评价
服务器录播失效 极高 录播出现缺帧、黑屏、跳跃、闪烁甚至不可使用等严重问题 webRTC 转 RTMP 带来的后果，在低码率的时候可能会好一点
直播卡顿 中等 直播卡顿、不稳定 小作坊常见的问题
多种推拉流方案不适配 极低 RTMP 等稳定推拉流方案无法使用 有需求再说吧

整体评价

该项目实际上是临时变更带来的产物，时间和人手有限，技术选型粗糙，没有标准化配置，没有三方评估，没有细致考量。

尽管如此，一个未经首肯的大幅更改的技术方案也为项目带来了肉眼可见的改变：

  1. 扩充了将近 50 倍的直播间观众容量（将终端载荷转移到服务器上）
  2. 为后续技术选型带来了更多回旋余地（比如：适配了更多的推拉流方式、多种录播方式保障录播效果、可快速部署服务器集群等）