本期作者
背景
自从我站从2020年逐步灰度自研P2P开始, 在直播下行带宽方面取得巨大的成功,带宽成本每年节省数亿。与此同时, 由于直播下行同时存在FLV和HLS两种直播协议,在回源带宽上也产生了双份费用,在2022年整个行业也处在下行阶段,为了进一步降本增加, 我们从回源成本出发,设计了一套新的流媒体协议,以应对当前多种下行协议分发的难题。
问题
在没有HLS协议之前, 整个直播体系只有RTMP/FLV, 所有用户都是通过观看FLV, 并通过CDN进行回源获取到直播内容。如下图:
当有了HLS协议之后, 情况如下, 尽管绝大多数用户会使用HLS, 但总有老版客户端会使用FLV进行播放, 这就导致FLV和HLS两种协议, CDN要分别进行回源, 即使播放的内容是一致的, 由于协议不同便会产生双倍回源带宽。
技术选型
当前尽管各种流媒体协议层出不穷, 比如Webrtc,RTP, CMAF, 但具体结合到B站自身的业务上面, 可选择余地并不大。首先B站自研P2P要求所有CDN对于同一个流媒体切片文件强一致性, 如果直接将RTMP的流放在不同的节点进行媒体切片会导致, 由于缺乏对媒体文件名的统一规则, 和切片起始信息所以会导致切片文件不能完全一致。这就要求新的流媒体协议能够在协议层提供一些额外进行去对齐切片信息，这样才能保证在不同节点的流能够得到完全相同的切片。
自研流媒体协议---BMT(Bili Media Transport)正是为了解决该问题,进行设计和开发的。我们从以下几个角度进行考虑：
1、兼容性不同协议在不同设备和网络环境下的表现都不同，所以兼容性是一个非常重要的考虑因素。我们希望BMT协议可以在各种设备和网络环境下都能够表现良好。
- 兼容足够多的编解码 RTMP/FLV 不支持265,266，及AV1 限制了进一步的应用场景，所以我们希望BMT在Codec兼容上提供更多类型
- 多轨道能力 在直播场景下, 多轨道的能力往往会被忽视, 但某些创新性的直播玩法就会对多轨道提出要求, BMT在设计之初, 就对这种情况进行了考虑, 最多支持16个轨道。
2、载荷比是指在传输同样的媒体信息时，协议本身所需要的额外开销。我们希望BMT协议的载荷比要尽可能地小，这样可以减少回源带宽的使用。
| BMT | RTMP/FLV | CMAF | |
|---|---|---|---|
| 音频包字节数 | 16bytes | 17bytes | 140bytes |
| 视频包字节数 | 12bytes | 13bytes | 134bytes |
| 封装消耗比(1-载荷比) | 0.338% | 0.349% | 3.489% |
3、握手简化是指协议在建立连接时需要的步骤越少越好。我们希望BMT协议的握手过程尽可能简化，这样可以提高协议的效率和性能。
核心库开发
以协议为基础, 遵循协议标准开发了内部通用的c程序库 libbmt, 使用统一的库, 用于对接到各个流媒体服务当中。为了顺利对接各种流媒体服务, 我们还对常用的组件 如ffmpeg , mpv等进行了bmt协议的扩展与兼容
回源架构设计
在回源体系设计上, 充分利用了现有的技术资产进行复用, 在cdn侧使用quic进行传输层加速, 在边缘动态分发切片, 可以按需进行回源, 从而减少回源成本。
线上效果
BMT上线至23年5月灰度90%左右, 每日节省自建CDN回源带宽约100G+, 基本符合预期。在整个开发过程中，针对新的流媒体协议积累了一套完整的技术体系, 后续针对这套协议的升级改造,整体成本也会更低。
在2022年跨晚晚会多音轨玩法中，也正式得益于BMT出色的兼容能力，才得以完美满足了整体直播活动技术需求。
未来展望
随着基础技术能力建设的完成, BMT协议作为回源协议的主力投入到了生产之中。除了回源外, BMT在上行推流端也存在着应用场景, BMT在直播流内部,进行了逻辑切片,在推流时,将逻辑前置到用户侧,可以节省云端的CPU消耗,进一步降本增效。随着BMT协议本身的迭代,我们也可以在直播流内部携带一些业务相关信息,可以在用户推流时增加更多互动玩法, 比如主播端通过AI场景识别, 将这些信息添加到BMT的直播流中, 在云端和播端可以利用这些信息进行各种直播玩法, 为业务赋能。