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