直播导播技术「rtmp转webrtc」

今天给大家普及一下直播导播技术「rtmp转webrtc」相关知识，最近很多在问直播导播技术「rtmp转webrtc」，希望能帮助到您。

下面就重点介绍直播带货应用的两个传输技术SRT和WebRTC。

传统TCP传输流媒体存在以下几个问题：

(1) 在带宽受限/丢包率高的链路，传输效率不佳

(2) 拥塞发生时传输速率可能会急剧下降，并带来累积延迟

(3) 缺乏适配直播流媒体传输的特性(如允许部分丢包/可控制的延迟等)

那么怎么样针对性解决的呢？

在电商直播过程中如果出现音视频帧丢失，会造成各端卡顿甚至花屏，给观众造成很不好的观看和购物体验。

针对于链路丢包，当前主流的解决方案仍然是ARQ(Auto Repeat Request)，下面分别介绍SRT/WebRTC是怎么解决这个问题的。

C音视频开发学习资料：点击领取→音视频开发（资料文档 视频教程 面试题）（FFmpeg WebRTC RTMP RTSP HLS RTP）

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，但是经过了网络传输后，到达接收方时，已经产生了不小的抖动和乱序。又是如何解决的呢？

C音视频开发学习资料：点击领取→音视频开发（资料文档 视频教程 面试题）（FFmpeg WebRTC RTMP RTSP HLS RTP）

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发送的效果。

相同的直播流，同样的观看时间，相同的网络链路，burst发送请求重传数8000多，pacing发送请求重传数120左右，视频接收帧率pacing的也更为平滑，效果明显。