直播架构知识

以上是常见的直播架构图。

采集端：

一般音频是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