要在语音视频 SDK 中实现超低延迟，实时的语音视频传输机制是必不可少的，而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石。在语音社交、视频社交、游戏语音和互动直播等领域，关于在语音视频实时传输中实现低延迟这个议题，已经有不少的文章提出各种方案。绝大部分方案的思路都是“优化”，比如说，优化编码、推流、传输和播放等各个环节。
愚以为，要在实时语音视频传输中获得超低延迟，是不能单靠挖空心思去“优化”的，而是要依靠实时的传输机制。就像高铁和火车有着本质的区别一样，火车不管如何优化，也只是跑得更快的火车，永远达不到高铁的速度。没有一套实时的传输机制，再怎么在各个环节“优化”，也无法获得真正超低的延迟。
要实现超低延迟，信道 QoS 十分关键。首先要选择合适的网络传输协议，采用基于 UDP 的私有协议还是标准 RTMP 协议？然后根据网络环境采用合适的 QoS 技术，采用 FEC，ARQ，还是双管齐下? 如果采用 FEC 和 ARQ 双管齐下，那么一套智能的 QoS 策略就必不可少。没有任何一种 QoS 技术能解决所有问题，实时语音视频传输机制必须是多种 QoS 技术的有机结合。
如果是视频直播 SDK，一般会选择 RTMP 协议，因为要能够普遍兼容 CDN 分发网络，从而向围观的广大用户进行直播。如果是音频社交 SDK、视频社交 SDK 或者游戏语音 SDK，一般会选择 RTP/RTCP 协议（或者类 RTP 的私有协议），因为不需要通过 CDN 网络向围观用户广播媒体流。是否要考虑兼容 CDN 网络，是语音视频通话 SDK 和视频直播 SDK 的重大区别。
RTMP 协议是基于 TCP 协议的，RTP 协议或者私有协议是基于 UDP 协议的，因此 RTMP 协议和 RTP 协议之争，本质就是 TCP 协议和 UDP 协议之争。
TCP 协议的特点：
1) 是通用的 IP 网络协议，不是为实时媒体传输而设计的，在弱网网络环境下延迟会增大；
2) 有内嵌的 ARQ，但没有 FEC，不允许开发者对 ARQ 策略进行控制，不能实现 FEC；
3) 不是从实时语音视频的角度进行设计的，更多考虑网络传输的公平性，内嵌的传输控制策略比较温和。
UDP 协议的特点：
1) 适合实时语音视频通讯，允许端到端全链条进行信道策略控制，在弱网环境下可控性更强；
2) 延迟时间的大小取决于丢包时候的 ARQ 和 FEC 策略，允许开发者深度控制 ARQ 和 FEC 策略；
3) 适合设计实时语音视频的通讯机制，根据网络状况自适应地选取 ARQ 和 FEC 策略，以及调整传输码率和报文的数量。
在网络环境好的情况下，只要语音视频编解码器相同，RTMP 协议和基于 UDP 的私有协议的传输效率是相当的，都可以实现低延迟、不卡顿和高品质的实时通讯效果。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询
在网络环境较差的情况下，特别是在跨网甚至跨国的情况下，基于 UDP 的私有协议对端到端全链条可控，包括流控码控、ARQ、FEC 和抖动缓冲等，对抗恶劣网络环境会更有保障。
IP 网络是“尽力而为”地提供数据传输服务的，尽最大的可能性来发送报文，但对时延、可靠性等性能概不负责效果，传输的数据出错是避免不了的，因此对信道进行保护是必须的。
信道 QoS 技术主要包括前向纠错 FEC，丢包重传 ARQ 和混合型 ARQ。这几种算法都是成熟的技术，在最基础的算法上又衍生出多个变种，而且在实现的过程中也可以进行定制化。
在 FEC 和 ARQ 的基础上，为了更好地适应弱网环境，需要让码率自动适应网络环境的波动，这样能够更好地保障实时语音视频通话的可用性和流畅性。
FEC 全称是 Forward Error Correction，中文翻译为前向纠错，是一种通过增加冗余数据对丢失的数据包进行恢复的信道编码算法。具体地说，由发送端对原始数据进行 FEC 编码，生成冗余奇偶校验数据包，原始数据和冗余数据包合并称作 FEC 数据块，原始数据包和冗余数据包的数量比例是固定的。发送端发送 FEC 数据块。接收端接收到 FEC 数据块后，通过冗余数据包和原始数据包来恢复出丢失或者出错的数据包。
FEC 编解码算法推荐使用比较成熟的 RS(Reeds-Solomon) 算法、Raptor 算法和 Tornado 算法。使用 FEC 编码算法的时候要根据丢包率（PLR, Packet Lost Rate）来设置冗余度。
下面使用 RS 的一个例子来说明 FEC 编解码算法的使用方法。
因为在一个 FEC 数据块中，原始数据包的个数和冗余数据包的个数的比例是固定的，所以很容易根据丢包的个数和冗余包的个数来判断是否能够全部恢复丢失的数据包。RS (n, k) 表示通过 RS 算法把 k 个原始数据包进行编码，生成（n-k）个冗余数据包，总共是一个包含有 n 个数据包的 FEC 数据块。假设丢失了 m 个数据包，如果 m<=(n-k)，那么 RS 算法可以完全恢复丢失的数据包；如果 m>(n-k)，那么 RS 算法就无法恢复丢失的数据包，这时候就要进行发送请求要求重传丢失的数据包。
下图展示了通过 RS(6，4) 进行丢包恢复的过程。发送端有 4 个原始数据包，通过 RS 算法编码生成 2 个冗余包，形成了一个拥有 6 个数据包的 FEC 数据块。RS 算法最多能够恢复 2 个丢失的数据包。发送端把 FEC 数据块发出去，在传输过程中第 2 号原始数据包丢失了。接收端接收到 FEC 数据块以后，通过 r1 冗余包把已经丢失的第 2 号原始数据包恢复出来。
使用前向纠错 FEC 算法，优点是数据包只需要传输一次，传输延迟不会受到 RTT(Round Trip Time) 的影响，不会增加额外的延迟时间；缺点是需要增加冗余数据包，降低了传输信道的利用率。总的来说是一种“空间换时间”的策略。
ARQ 全称 Automatic Repeat reQuest，中文意译为丢包重传，是一种通过重传关键数据包来纠错的信道保护算法。
具体地来说，发送端给每一个数据包都植入顺序号码和时间戳，顺序号码代表被发送数据包的顺序，允许接收端可以通过监测顺序号码来发现丢包事件；时间戳代表语音视频数据包解码的时间点。发送端发送数据包后，如果接收端没有收到，接收端将会通过 RTCP/TCP 信道发送一个重传请求。发送端维护一个缓冲队列，当收到重传请求的时候将会重传数据包。接收端也会维护一个缓冲队列，等待尚未收到的数据包以及对已经收到的数据包进行排序。在解码的 deadline 到来之前，接收端把缓冲区的数据包交给解码器进行解码。在解码 deadline 的时间点，接收端要么已经收齐了预期的数据包，要么已经决定放弃继续等待。
传统的丢包重传 ARQ 包括以下三种：
1）Stop-and-wait ARQ，也就是停止等待的 ARQ，发送端发送数据包后就停止并等待接收端的确认消息，在收到确认消息之前，信道处于空闲状态；
2）Go-Back-N ARQ, 也就是退回 N 步的 ARQ，发送端不需等待接收端的确认，不停地发送数据包，直到收到接收端的重传请求。发送端除了重传被要求重传的数据包以外，还会把该数据包时间戳后面已经被接收端成功接收到的一批数据包全部重传一遍；
3）Selective Repeat ARQ，也就是选择性重传的 ARQ，发送端不需等待接收端的确认，不停地发送数据包；接收端只会有选择性地对关键的数据包要求重传，而发送端只重传被要求重传的数据包。
第一种和第二种 ARQ 效率比较低下，第三种 ARQ 相对来说效率比较高。目前主流的丢包重传算法大部分是第三种 ARQ 的变种或者定制化版本。
选择性重传 ARQ 的优越性在于它能确定哪些关键的数据包需要重传，从而大大地提高重传的效率，降低造成重传风暴的风险。比如说，在出现花屏的时候，请求发送端立即编码视频关键帧发送过来，避免长时间花屏无法刷新的现象。选择要重传的数据包的算法十分关键，这里必须要有比较谨慎的策略，不能任何丢失的数据包都要求重传，那样就相当于又走了 TCP 协议内嵌 ARQ 模块的老路，必然引入不可控的延时。
选择性重传的 ARQ 要考虑实时性，要估算计划要重传数据包到达的时间（以 RTT 的倍数来估算），如果数据包预期的到达时间在解码的 deadline 之前，就要求重传，如果在 deadline 之后，就放弃重传。
ABC 全称 Adaptive Bit-rate Control，中文意译为码率自适应，是服务端和推流端协作控制码率来自动适应网络环境变化的技术。码率自适应的目的是为了对抗弱网环境。在网络好的情况下，适当提高码率，提高语音视频的质量和降低延迟；在网络差的情况下，适当降低码率，保障语音视频通话的可用性和流畅性，适当牺牲音画质量。
码率自适应包含了带宽估算和码率控制：
1）带宽估算，服务端和推流端协作完成，推流端把网络环境统计信息上报给服务端，服务端通过带宽估算算法估计出当前带宽；
2）推流端按照估算出来的带宽进行推流，如果网络情况良好（没有检测到网络拥塞）则持续的地提高码率，试探网络带宽的上限，直到出现网络拥塞为止；
3）当网络拥塞出现的时候，推流端降低码率来保障可用性和流畅性，直到网络拥塞缓解为止；
4）当网络拥塞缓解的时候，转到 #2。
整个过程可以类比成驾驶汽车过程中控制方向盘的方法，偏左了就往右边调整一点，偏右了就往左边调整一点，来来回回的微调让驾驶处于安全和顺畅的状态。码率自适应也是一样的道理。
PLC 全称 Packet Lost Concealment, 意译为错误隐藏，应用于实时语音通话的场景。语音数据包的丢失会造成语音的歪曲。为了减少语音数据包丢失造成对语音通话质量的伤害，错误隐藏 PLC 算法通过前一个语音数据包和后一个语音数据包的相关性来“推测出”当前丢失的语音数据包，从而“隐藏”了信道传输所造成的错误。错误隐藏 PLC 算法在接收端进行，不需要发送端参与。