共计 2412 个字符，预计需要花费 7 分钟才能阅读完成。
直播和互动直播在 2017 年引起了人们的极大关注，应运而生的各种直播类 APP 多如牛毛。随着互动直播的逐渐兴起，交互成为直播 APP 的强需求。然而，实际网络中的丢包、延迟、抖动等问题仍然严重影响了直播的效果。
针对上述问题，本文介绍了网易云信直播的网络 QoS 技术，旨在帮助读者了解在极差网络环境下如何最大限度的保障直播的流畅性和清晰度。
相关阅读推荐《视频直播关键技术：流畅、拥塞和延时追赶》
《短视频技术详解：Android 端的短视频开发技术》
《视频直播技术之 iOS 端推流》
流畅性和清晰度定义观众在观看直播或者与主播进行互动直播的过程中，对音视频流畅性和清晰度的感受可以通过视频帧率、视频 PSNR（或 SSIM）分值、音频 MOS 分值等客观参数指标来表征。越高的视频帧率带来的视频流畅性越高，越高的视频 PSNR（或 SSIM）分值带来的视频清晰度越高，越高的音频 MOS 分值带来的音频流畅性和清晰度越高。
那么，如何通过提高网络 QoS 技术改善网络质量，从而提高上述的客观指标呢？下面我们就单向直播和互动直播分别进行介绍。
单向直播的流畅性和清晰度这里的单向直播特指通过 RTMP/TCP 协议将音视频流推送到 CDN，然后观众拉流观看的一种直播方式。
众所周知，TCP 是一个面向连接的传输层协议，协议本身保证了传输的可靠性。通过调用开源框架 librtmp，开发者可以非常容易的实现 RTMP 推流服务。然而，在网络出现丢包和抖动的时候，TCP 的拥塞控制策略会限制推流端的发送码率，使得观众端出现突发的拉流卡顿，影响音视频的流畅性。
通常情况下，应对网络丢包的策略有前向错误隐藏（FEC）、音频 RED 冗余、重传等，应对网络带宽受限有音视频的自适应码率调节策略。考虑到 TCP 协议的特殊性，我们无法设计灵活的重传和自适应码率调节策略，数据发送的多少和频率完全由 TCP 协议本身控制。这种情况下，我们可以做的是及时有效的检测网络可用带宽，并调节音视频编码器的输出码率，做到码率自适应。
具体的实现方法是，通过平台（ios、Android 或者 Windows）相关的 TCP socket 接口获取网络信息，感知网络拥塞，估算得到可用带宽，及时调节音视频编码器的设置码率，防止音视频卡顿发生，保证流畅性。
互动直播的流畅性和清晰度这里的互动直播特指连麦者通过 RTP/UDP 协议将音视频流推送到中转服务器，进行混流后再通过 RTMP/TCP 协议推送到 CDN，然后观众拉流观看的直播方式。
UDP 不同于 TCP，协议本身不关心数据是否及时可靠到达对端，只是完成“发送”的操作。由此，我们可以采用种类繁多的技术手段保证 UDP 协议数据的可靠达到。例如：前向错误隐藏（FEC）、音频 RED 冗余、重传等策略。根据网络状况和媒体数据的不同，我们采取相应的策略。
按照如下的技术分别介绍：
带宽估计带宽估计的作用是准确的获得当前的可用网络带宽，进而指导音视频编码器的带宽分配，使得实际发送码率不超过可用带宽，从而不会引起延时增加和丢包。常用的带宽估计方法包括根据丢包或者延迟变化估计带宽，Google 的 WebRTC 中就包含了完整的带宽估计方法，值得大家学习借鉴。
错误隐藏当接收端收到的音视频数据已经发生了丢失，我们该如何恢复数据呢？从音视频解码的角度看，可以通过视频（音频）前一帧或者多帧数据恢复丢失的数据。然而，常用的视频错误隐藏方法往往会对恢复的图像造成马赛克现象，错误隐藏的效果不佳。所以大多数情况不采用这类错误隐藏技术，而是解码之前会判断一帧数据是否完整，完整的数据才会被送入解码器，不完整的数据直接丢弃。音频领域的错误隐藏是另一种情况，音频的错误隐藏技术要普遍优于视频的错误隐藏，流行的音频压缩标准 Opus、iLBC、iSAC/SILK 等，都含有自己的 PLC（Packet Loss Concealment）模块，解码器在检测到丢帧的时候会自动进行错误隐藏，实际效果还可以接受。
前向纠错前向纠错技术相当于在发送端多发一部分数据，这部分数据可能是原始数据的复本，也可能是多份原始数据相互计算的结果。如果原始数据在传输过程中发生了丢失，那么这部分冗余数据就可以发挥作用，帮助恢复丢失的原始数据。当然了，这种策略牺牲的是有限的网络带宽。
视频数据区别于音频数据的一个特点是，视频的数据包较大，一般情况会接近 MTU 大小，同时观众对视频数据的端到端延迟不如音频数据敏感。因此可以采用数目较大的 FEC 分组进行前向纠错。而音频数据包较小，数据包头在整个数据包中的占比相对视频要高出很多，所以进行 RED 冗余能够使多个音频包复用同一个包头，提高数据利用率。另一方面，如果音频数据采用 FEC 进行前向纠错，势必会增加延迟，影响通话体验。
因此，视频数据较适宜采用 FEC 技术进行前向纠错，音频数据较适宜采用 RED 技术进行冗余操作。
重传除了前向纠错技术，在网络 RTT 较小的时候，我们也可以向发送端请求网络中丢失的数据包，这就是重传技术。这个技术适用于网络 RTT 较小的情况，相比于 FEC 和 RED，重传可以大幅提高带宽利用率，做到“丢哪个包要哪个包”，有针对性的重传丢失的数据包。
考虑到观众对音频数据的敏感性，除非网络 RTT 很小，否则音频一般不采用重传技术。视频较多采用重传技术进行错误恢复，根据重传请求数据的不同又分为 I 帧请求和数据包请求。
I 帧请求是当接收端无法继续解码，而且发送端的 GOP 长度又很长的时候，需要及时请求发送端发送 I 帧，使得接收端根据这个 I 帧可以尽快恢复显示。数据包请求则是根据丢失的数据包，向发送端有针对性的请求，这种情况下发送端需要缓存已经发出去的数据包，以备后续接收端的请求。
以上简单介绍了直播中提高流畅性和清晰度的几种方法和策略。实际使用中还需要考虑多种技术的有机结合，以及服务器端与客户端的相互配合，并结合用户使用场景和客户端设备性能等因素综合考虑。
另外，想要获取更多产品干货、技术干货，记得关注网易云信博客。
