直播技术栈 #10
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
直播是这一两年的热点，有很多公司在做直播，还有更多的公司准备做直播或在现有产品里加入直播功能。那么，直播涉及哪些技术栈呢？做一个直播demo并不难，但做一个高质量的直播产品并不容易，本文将简单列出直播相关的技术栈。下面是直播的一个简单流程:
直播协议
在选择直播架构和协议时，首先要考虑是单向直播，还是互动直播（是否支持连麦），对时延的要求有多高？然后可以在下面2个方案里选择适合的一个：
方案1适合单向直播，目前多数直播应用都是这样的架构，这一方案可以做到准实时，时延在3s～10s。这一方案也可以支持连麦，连麦者也使用RTMP协议。
方案2适合低延迟的互动直播，主播、连麦者和对时延要求高的用户使用RTP协议，可以容忍一定时延的观众端使用旁路直播，这一方案可以做到实时，时延可以低至百毫秒级，但技术实现复杂。
两种方案里，观众端(没有连麦，playonly)一般都是通过CDN(自建CDN/第三方CDN)拉流，拉流使用RTMP/HTTP/HLS协议。
下面是直播相关协议介绍：
视频封装格式有FLV, TS, 视频传输协议有RTMP, HTTP, RTP等.
采集
涉及到各个端各种设备的适配问题，iOS/mac平台可以使用AVFoundation.
前处理
对于回音消除，gain/delay给多少，不同的端如何进行适配？通过白名单？
Codec
iOS端可以直接采用硬编, Android 的硬编的支持则难得多，需要适配各种机型，是否通过白名单？android一般推荐使用软编, PC使用软编.
服务端
服务端功能如下:
常见的开源流媒体服务器有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调度，等等。
接入后如何保证低延时的分发，这涉及到网络节点分布和网络拓扑设计。
多场景适配
常见的场景有:
QoS
音视频优化, 传输时延优化, 弱网优化, 首屏优化, 丢帧策略, 累计延迟消除优化, 卡顿率优化, 等等.
可以从3个方面讨论QoS:
播放端的优化包括
手机应用前后台切换造成累计延时
切到后台时一般音频继续播放，这样可以保持音频一直播放不产生延时，而当回到前台时，视频同步音频直接切换到最新时间戳即可
回到前台时重新刷新直播，重连直播流，这样即可消灭累积延时，这要求首屏加载优化要做好，为了防止黑屏，优化体验，可以先放最后的一个视频帧
卡顿造成累计延时
播放快进
开源项目
互动系统
聊天室、私聊、礼物系统、点赞
The text was updated successfully, but these errors were encountered: