技术解码 | 直播传输技术之SRT/WebRTC
今年的双11格外疯狂，各大商家也纷纷开启了直播带货。为让广大消费者有更好的视听购物体验，腾讯视频云的小伙伴一刻也不敢放松，在做好全线护航的同时，还要保证低延迟高清流畅。随着用户对体验要求越来越高，直播进入了低延迟高码率的时代，直播传输技术也面临着越来越高的要求和挑战。
腾讯视频云为此在全链路上针对流媒体传输不断深入优化，使得在各大重要赛事上具备了高可靠、低延迟、高画质和音质的需求。下面就重点介绍其中应用的两个传输技术SRT和WebRTC。
传统TCP传输流媒体存在以下几个问题：
(1) 在带宽受限/丢包率高的链路，传输效率不佳
(2) 拥塞发生时传输速率可能会急剧下降，并带来累积延迟
(3) 缺乏适配直播流媒体传输的特性(如允许部分丢包/可控制的延迟等)
那么腾讯视频云是怎么样针对性解决的呢？
在电商直播过程中如果出现音视频帧丢失，会造成各端卡顿甚至花屏，给观众造成很不好的观看和购物体验。
针对于链路丢包，当前主流的解决方案仍然是ARQ(Auto Repeat Request)，下面分别介绍SRT/WebRTC是怎么解决这个问题的。
SRT
SRT采用的是ACK + NACK的解决方案。每隔10ms，SRT接收方会发送一个"正常"ACK包，将当前接收buffer中连续的最大包序号告诉发送方，发送方收到"正常'ACK包后，会确认数据，将发送窗口前移，同时发送ACKACK，接收方依据T(ackack) - T(ack)来计算链路rtt。对于高码率的链路，每10ms确认一次可能会不及时，为此，SRT每收到64个包，便会额外回复一个LITEACK，用来快速确认数据，尽可能快的让发送窗口移动。
每次收包时，SRT会计算当前的"乱序度"。举个例子，如下图所示：
上图当前时刻的"乱序度"为2，当发现丢包需要重传时，SRT会延迟2个包发送NACK，用来减少一部分因为UDP乱序导致的无效重传。
WebRTC
WebRTC只采用了NACK，其内部会维护一个重传队列(NackModule)，最大长度1000个包，或者覆盖10000长度的包序号范围，每个包最多重传10次。
每当发现某个包丢失时，首次重传会立即进行，剩余的重传会在距离上次重传时间超过当前rtt时马上进行。
如果重传一直无效，导致重传队列包数到达了最大值，WebRTC会尝试清除过久的重传包，直到最近的一个关键帧重传请求。清理后如果队列还是超出了限制，会清除整个重传队列，直接请求发送方发一个关键帧，避免了过多的重传流量。
可以看到，ARQ仍然是当前面对丢包的主要手段。对于流媒体传输而言，既要做到及时快速的重传，又要做到避免过多的，过久的重传。
腾讯视频云做了针对场景的可配置的容错特性，根据音视频编码的特点并结合业务场景，例如将传输的报文分了多个优先级，在需要主动丢包的情况下优先丢弃低优先级的数据(如B帧，音频等)
为保证电商直播活动的播放流畅度，除了可靠传输外，传输协议需要具备很好的抗抖动性，来保持低延迟且稳定。
从上图看到，编码器输出稳定的25fps的视频帧，每帧发送间隔40ms，但是经过了网络传输后，到达接收方时，已经产生了不小的抖动和乱序。腾讯视频云又是如何解决的呢？
SRT Latency + Tsbpd
SRT的解决方法是，设置一个固定的latency，并在包头写入每个包的发送时间，在读取时，按照发送时间延迟latency读取，完美的复制了编码器的输出。
WebRTC jitter buffer
WebRTC使用了Jitter Buffer来对抗网络抖动，其实现原理跟上述SRT的方法类似，有两个不同点，一是延迟会根据当前网络抖动的程度来调整，网络越稳定，延迟越小，二是从jitter buffer出来的帧，会尽量保证以均匀的速率输出，但不一定跟发送方编码器输出严格一致。
SRT的Tsbpd机制可以很精准的控制Latency，结合重传机制，相对于其它协议有更低的延迟，但不足的一点是不能动态调整。WebRTC将传输抖动和编码渲染结合相互反馈调整，实现上更为复杂。业务需要根据自身需求，选择不同的方案。
传输协议一大重点是要如何识别网络拥塞并通过调整单链路的策略和算法来尽量满足全局的公平性和吞吐量。目前较流行的传输拥塞控制主要分为基于延迟的拥塞控制、基于丢包的拥塞控制和基于BDP（带宽延迟积）的拥塞控制算法。
SRT
在SRT 的LIVE模式下，不进行拥塞控制，只根据当前的码率，调整发包间隔（见下一小节）。由此可见，在带宽受限的链路下，SRT的表现需要做进一步优化。
WebRTC
WebRTC采用了GCC的拥塞控制策略，以rtt的抖动来评估链路的情况，结合一系列滤波算法，减少了噪声影响后，判断当前网络的利用率(轻载/正常/过载)，以此来调整发送方码率。当前WebRTC带宽评估有两种实现方式，一种是接收方评估，基于REMB的实现，一种是发送方评估，基于TWCC的实现。两者无论是原理还是效果都是类似的。
SRT拥塞控制策略在带宽足够的链路下有强劲的抗抖动性，WebRTC策略的则能够适配大多数的链路，并配合视频编码动态调整码率，以达到最佳效果。
众所周知，TCP一个窗口内的数据包通常会一次性无间隔的发送，容易造成流量突发。Pacing机制通过平滑发送间隔，来防止该问题。
SRT
SRT是根据带宽评估来调整发送间隔的。可以从输入的速率采样，或者由用户设置最大带宽(maxBW)，并留出一部分重传带宽(overheadBW)，两者之和作为最大的传输速率。
如上图所示，若maxBW为800Kbps，overheadBW为200Kbps，链路最大带宽限制为1Mbps，按每个包大小1Kb计算，SRT会按照1ms的间隔平滑发送。
WebRTC
总的原理跟上述SRT类似，细节更复杂，这里不再赘述。展示一下pacing发送的效果。
图1 pacing发送
图2 burst发送(no pacing)
相同的直播流，同样的观看时间，相同的网络链路，burst发送请求重传数8000多，pacing发送请求重传数120左右，视频接收帧率pacing的也更为平滑，效果明显。
除了电商直播，腾讯视频云在大型晚会、体育赛事、电竞娱乐等直播能力上，也有着多年的技术经验积累，针对多行业，多场景有完整的从端到端的解决方案。腾讯云视频云持续在直播技术上处于领先地位，我们将不断的探索与突破，期待为全球开发者提供更好的视频云。
