Open rainzhaojy opened 7 years ago
直播是这一两年的热点,有很多公司在做直播,还有更多的公司准备做直播或在现有产品里加入直播功能。那么,直播涉及哪些技术栈呢?做一个直播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给多少,不同的端如何进行适配?通过白名单?
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调度,等等。
接入后如何保证低延时的分发,这涉及到网络节点分布和网络拓扑设计。
常见的场景有:
音视频优化, 传输时延优化, 弱网优化, 首屏优化, 丢帧策略, 累计延迟消除优化, 卡顿率优化, 等等.
可以从3个方面讨论QoS:
播放端的优化包括
手机应用前后台切换造成累计延时
切到后台时一般音频继续播放,这样可以保持音频一直播放不产生延时,而当回到前台时,视频同步音频直接切换到最新时间戳即可
回到前台时重新刷新直播,重连直播流,这样即可消灭累积延时,这要求首屏加载优化要做好,为了防止黑屏,优化体验,可以先放最后的一个视频帧
卡顿造成累计延时
播放快进
聊天室、私聊、礼物系统、点赞
good good
技术点完整。
thanks for sharing
good
直播是这一两年的热点,有很多公司在做直播,还有更多的公司准备做直播或在现有产品里加入直播功能。那么,直播涉及哪些技术栈呢?做一个直播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:
播放端的优化包括
手机应用前后台切换造成累计延时
切到后台时一般音频继续播放,这样可以保持音频一直播放不产生延时,而当回到前台时,视频同步音频直接切换到最新时间戳即可
回到前台时重新刷新直播,重连直播流,这样即可消灭累积延时,这要求首屏加载优化要做好,为了防止黑屏,优化体验,可以先放最后的一个视频帧
卡顿造成累计延时
播放快进
开源项目
互动系统
聊天室、私聊、礼物系统、点赞