以上是常见的直播架构图。
采集端:
一般音频是PCM格式,视频是RGB或者YUV格式。
直播的编解码:
为了便于手机视频的推流、拉流以及存储,通常采用音视频编码压缩技术来减少体积,编码方式:CBR、VBR,
视频-编码格式:H.265、H.264、MPEG-4等,封装容器有TS、MKV、AVI、MP4等。现在比较常用的视频编码是H.264。
音频-编码格式:G.711μ、AAC、Opus等,封装有MP3、OGG、AAC等,比较常用的是AAC编码格式。
视频经过编码压缩大大提高了视频的存储和传输效率,当然,经过压缩后的视频在播放时必须进行解码。
传输协议:
RTMP:Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议,主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。
一般上行的传输都是用的RTMP协议。传输到节点(CDN)以后,再转入到源站。
下行节点一般是:RTMP和HTTP-FLV或者HLS协议,
源站会进行一些转码的后处理工作,源站的主要工作是作为下拉流用的。
直播遇到的常见问题:
1、卡顿
1、主播采集或者播放的设备差、网络差,上行或者下行网络差。
2、视频流本身音视频不同步,时间戳有问题(跳变),参数配置有问题。
3、服务端解码和转码问题,节点不稳定问题。
解决办法:网络自适应
1、推流端动态调整码率、帧率。有计划的丢帧:音频帧—关键帧—P帧—B帧
2、播放端动态buffer,服务端生成多路大小流。
3、播放端动态调整
2、延迟高
1、推流端优化
2、播放端优化
3、传输协议的优化
3、首帧慢
1、DNS缓存 预加载
2、预览、预加载
3、节点优选
4、模糊、清晰度优化的手段:
1、调整摄像头参数
2、贷款足够的时候上调码率
3、软编、硬编(占用CPU资源少)、profile、GOP
4、超分算法
之所以用UDP作为流媒体协议的底层协议,是因为TCP协议过于严格。
包括三次握手协议,丢包恢复慢,丢包导致发送速度变慢。
基于UDP协议的升级版本优化出来的流媒体协议
KCP、quick、SRT、私有协议。
实际开发过程中,需要实时上报用户的网络情况作为监控。通过数据监控作为优化的方向。
提高首帧成功率包括:
1. gop缓存,为加快首播时间
2. gop丢帧,为解决延时,为什么会有延时,网络抖动、网络拥塞导致的数据发送不出去,丢完之后所有的时间戳都要修改,切记要不客户端就会卡一个 gop的时间,是由于 dts 和 pts 的原因,或者播放器修正 dts 和 pts 也行(推流端丢gop更复杂,丢 p 帧之前的 p 帧会花屏)
3. 纯音频丢帧,要解决音视频不同步的问题,要让视频的 delta增量到你丢掉音频的delta之后,再发音频,要不就会音视频不同步
4. 源站主备切换和断线重连
5. 根据TCP拥塞窗口做智能调度,当拥塞窗口过大说明节点服务质量不佳,需要切换节点和故障排查
6. 增加上行、下行带宽探测接口,当带宽不满足时降低视频质量,即降低码率
7. 定时获取最优的推流、拉流链路IP,尽可能保证提供最好的服务
8. 监控必须要,监控各个节点的Qos状态,来做整个平台的资源配置优化和调度
9. 如果你家产品从推流端、CDN、播放器都是自家的,保障 Qos 优势非常大.
10. 当直播量非常大时,要加入集群管理和调度,保障 Qos