直播技术栈

 

直播是这一两年的热点，有很多公司在做直播，还有更多的公司准备做直播或在现有产品里加入直播功能。那么，直播涉及哪些技术栈呢？做一个直播demo并不难，但做一个高质量的直播产品并不容易，本文将简单列出直播相关的技术栈。下面是直播的一个简单流程:

直播协议

在选择直播架构和协议时，首先要考虑是单向直播，还是互动直播（是否支持连麦），对时延的要求有多高？然后可以在下面2个方案里选择适合的一个：

• 方案1 - 传统的直播架构，推流使用RTMP/TCP协议，拉流使用RTMP/HTTP-FLV/HLS
• 方案2 - 视频会议+旁路直播，使用RTP/UDP协议，旁路使用方案1走CDN实现大规模分发

方案1适合单向直播，目前多数直播应用都是这样的架构，这一方案可以做到准实时，时延在3s～10s。这一方案也可以支持连麦，连麦者也使用RTMP协议。

方案2适合低延迟的互动直播，主播、连麦者和对时延要求高的用户使用RTP协议，可以容忍一定时延的观众端使用旁路直播，这一方案可以做到实时，时延可以低至百毫秒级，但技术实现复杂。

两种方案里，观众端(没有连麦，playonly)一般都是通过CDN(自建CDN/第三方CDN)拉流，拉流使用RTMP/HTTP/HLS协议。

下面是直播相关协议介绍：

• RTMP - adobe的私有协议, 将原始码流分割成小块数据传输, 延时低, 1-3s
• HTTP-FLV - adobe的方案，延时低, 1-3s
• HLS - 苹果推出的方案，iOS/android浏览器原生支持，适合用于手机端分享链接, 延时较长, 5-10s
• DASH - 也称为MPEG-DASH, MPEG制定的标准，原理类似HLS
• RTSP
• WebRTC - 使用RTP协议，类似视频会议的方案
• WebSocket/DataChannel + Canvas/WebGL + AudioContext
• CMAF - 参考这里

视频封装格式有FLV, TS, 视频传输协议有RTMP, HTTP, RTP等.

采集

• 音频采集 - 麦克风, Speaker(用于背景音乐), 音频文件等; 采集时是否要打开预处理，譬如高清语音开关，人声检测开关，回音消除等
• 视频采集 - 摄像头, 屏幕录制, 视频文件等

涉及到各个端各种设备的适配问题，iOS/mac平台可以使用AVFoundation.

前处理

• 音频前处理 - 3A, 回音消除, 降噪, 静音检测, 声音特效, 混音等; 对于单向直播，主要是降噪，对于互动直播，需要回音消除。
• 视频前处理 - 美颜, 水印(用于版权保护或者进行广告设置), 滤镜等

对于回音消除，gain/delay给多少，不同的端如何进行适配？通过白名单？

Codec

• 音频编码 - OPUS, AAC, Speex
• 视频编码 - H264, H265, VP8, VP9

iOS端可以直接采用硬编, Android 的硬编的支持则难得多，需要适配各种机型，是否通过白名单？android一般推荐使用软编, PC使用软编.

服务端

服务端功能如下:

1. 转码，可以用FFMpeg软转码或用硬件转码，包括2种
   1. 视频高码率转低码率 - 主播一般送一路高清视频流，需要转码成3路或4路低分辨率码流，这样不同观众根据自身网络情况可以拉不同码流
   2. 码流格式转换 - 譬如主播使用RTMP推流，服务端转码成FLV, HLS等码流，这样客户端可以使用不同方式拉流
   3. 音频编码转换，譬如speex转AAC
2. 混屏 - 互动直播时，多路视频需要混屏后推送
3. 录制 - 因为质检、运营等需要，直播需要录制，可以在服务端录制或者通过CDN拉流录制
4. 加密
5. 鉴黄 - 利用机器学习技术识别违规图像
6. 防盗链

常见的开源流媒体服务器有SRS, nginx-rtmp。

直播连麦

怎么连麦？使用TCP/RTMP实现连麦还是使用UDP/RTP实现连麦？多路音视频怎么合流？主播合成，连麦者合成，还是服务器合成？

从效果考虑，连麦必须要保证低时延，TCP/RTMP在弱网时的时延会非常大，因此建议使用UDP。连麦的过程其实就是实时通话的过程，相比直播，实时通话的技术难度又高了一大截，这里包括低时延、回声消除、拥塞控制、高并发的流媒体分发系统等等。

有些团队会基于WebRTC来搭建实时通话系统，但是WebRTC工程很复杂，能吃透已不容易，吃透后还需要修复里面的一些问题，WebRTC为P2P场景设计，还需要做大量的改造，这里的坑非常深，非常不建议非专业的音视频团队来填这个坑，即使费劲九牛二虎之力搞了一个版本出来，最终要保证在各种网络、各种设备上顺畅的使用，还有很多工作要做。

一个简单可行的方法是使用实时通信PaaS云服务，通过集成他们的SDK可以非常方便的实现音视频通话的功能，这样可以避免自己招团队来填坑，音视频效果会更好，实现功能也会更快。一个不错的实时通信PaaS云提供者是拍乐云，WebEx一帮音视频大牛出来做的，和Zoom是同样的团队基因，可以看下：https://pano.video

网络

如何解决跨运营商和跨地域问题？多地布点？海外布点？

如何让客户就近接入同一运营商，这涉及到GSLB调度，IP库的准确性，DNS调度，HttpDNS调度，等等。

接入后如何保证低延时的分发，这涉及到网络节点分布和网络拓扑设计。

多场景适配

常见的场景有:

• 通话 - 保证语音通话效果，3A处理是必须的
• 音乐 - 如何保证高音质? 3A是不是要关闭
• 混合 - 即要高音质又要保证通话效果，3A开哪些，gain设多少?

QoS

音视频优化, 传输时延优化, 弱网优化, 首屏优化, 丢帧策略, 累计延迟消除优化, 卡顿率优化, 等等.

可以从3个方面讨论QoS:

• 主播端
• 播放端
• 服务端

播放端的优化包括

• 首屏加载优化
• 累计延时优化

手机应用前后台切换造成累计延时

切到后台时一般音频继续播放，这样可以保持音频一直播放不产生延时，而当回到前台时，视频同步音频直接切换到最新时间戳即可

回到前台时重新刷新直播，重连直播流，这样即可消灭累积延时，这要求首屏加载优化要做好，为了防止黑屏，优化体验，可以先放最后的一个视频帧

卡顿造成累计延时

播放快进

开源项目

• FFMpeg - 可以进行各种音视频处理: 编解码, 转码, 录制等等
• rtmpdump/librtmp - RTMP协议实现
• ijkplayer - 一个基于FFmpeg的开源Android/iOS视频播放器
• GPUImage - iOS端的滤镜处理库, Android也有GPUImage的移植版本
• WebRTC - 音频处理, RTP等等
• SRS - 国人做的开源媒体服务器
• yasea - android推流
• OBS - pc推流