视频直播技术干货(十三)：B站实时视频直播技术实践和音视频知识入门原创

视频直播技术干货13。B站实时视频直播技术实践和音视频知识入门关于作者马家义，B端技术中心资深开发工程师实时音视频关键技术1、传输协议在我们的实时音视频场景中，应当优先选择up，理由如下，1、P保证数据流的可靠性和顺序性。2、upp允许数据包丢失、乱序和重复。关键技术二，丢包补偿。前项纠错FC发送端发送N个数据包，同时根据原始数据生成K个冗余的数据包，将N+KG数据包发送出去，接收端只要收到至少N个数据包，就可以得到全部的原始数据。后项纠错包括AQ，适合突发大量丢包的场景，没有额外的带宽消耗。

但是时效性取决于RTT，如果存在很多接收端，还要考虑避免NEC风暴造成雪崩。关键技术3，流量控制。基于延迟的评估算法包括transport-CC和guc g-RAMB。目前最新版的web RC默认使用的是transport-CC。基于丢包的评估算法是当网络突发大量丢包时的兜底策略。1如果丢包率在2%以下的时候，说明网络质量好，目标带宽增加8%，2如果丢包率再在200%分之10，说明当前发送数据的带宽和网络质量相匹配，可以保持不变。3如果丢包率大于10%，说明网络质量差，目标带宽减小到1杠丢包率0.5当前带宽关键技术四最优路径城市A的设备给城市D的设备发送数据，直接发送未必是最优的选择，从城市B和城市C中转移下有可能更快。理想的解决方案是在全球部署加速节点，用户就近接入。根据加速节。

点之间的实时网络质量探测数据，找到一条最优传输路径，避开网络的拥堵。Web artc整体架构大概可以分为接口层、会话层、引擎层和设备IO层。1、接口层包括web API和web RCC加加API 2、会话层主要包含信令相关的逻辑，比如媒体协商、P2P连接管理等。3引擎层是web RS最核心的功能，包括音频引擎、视频引擎和传输拈4设备IO层主要和硬件交互，包括音视频采集和渲染以及网络IOB站视频直播系统架构问题1主播之间的音视频通话是采用P2P还是服务器中转？首先对P2P和服务器中转两种方案做个对比，问题2。

推送给观众的流道CDN，这个工作放在主播客户端还是服务器，我们先对比一下两种方案的优劣，所以这两种方案各有优缺点，我们采取折中的办法，如果主播的设备负载较低，且上行带宽比较充足，优先采用主播客户端混流的方式。否则降级为服务器混流，这是我们的系统整体架构。RC-service主要提供信令频道管理、主播管理，供有云上媒体服务器集群的健康检查和节点分配，同步主播状态到业务服务器，记录通话流水。Rz Gang job是对R7及Gang service的补充，定期检查当前在线主播的状态。

发现主播异常下线时触发兜底逻辑，Art c-ruer负责收发主播的音视频数据，Art c-mixer负责混流，主播的客户端并没有直接向RC-routeer发送数据，而是通过第三方的四曾加速网络转发。