什么是FEC/NACK/RTX /RED

FEC (Forward Error Correction） 中文叫前向纠错

 

　前向纠错技术(Forward Error Correction)在确保信号的长距可靠传输方面也起着非常重要的作用，逐渐成为必不可少的主流技术。

这里借用光通讯的图来描述FEC的基本原理。

图1 FEC在光通信中的位置

 

　　FEC技术是一种广泛应用于通信系统中的编码技术。以典型的分组码为例，其基本原理是：在发送端，通过将k bit信息作为一个分组进行编码，加入（n-k）bit的冗余校验信息，组成长度为n bit的码字。码字经过信道到达接收端之后，如果错误在可纠范围之内，通过译码即可检查并纠正错误bit，从而抵抗信道带来的干扰，提高通信系统的可靠性。在光通信系统中，通过FEC的处理，可以以很小的冗余开销代价，有效降低系统的误码率，延长传输距离，实现降低系统成本的目的。

 

　　编码开销是校验位长度（n-k）与信息位长度k的比值，称为编码开销。开销越大，FEC方案的理论极限性能越高，但增加并不是线性的，开销越大，开销增加带来的性能提高越小。开销的选择，需要根据具体系统设计的需求来确定。

 

 

NACK（Non-Acknowledge）

说NACK前，我们先说说ACK。ACK实际上就是到达通知技术。大家都知道TCP是可靠的连接，他之所以可靠，那是因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。

NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。那么问题来了，接受者怎么知道自己未收到消息？

音视频数据包都是按时间顺序发送的，一般都带序号（升序排列的时间戳）。例如发送方按顺序发送了时间戳为60,120,180,240，320共五个包，接收者已经收到了60包，本来预期下一个接收的包的序号应该是序号120的包，但序号是120的包一直没收到，后面的包却收到了。那么接收者就可以判断，120这个包丢了，这时候接收方需要向发送方发出NACK消息（消息中带有丢包的序号，这里是120），让发送方重新发送丢失的包。

实时音视频传输都基于udp，包到达的顺序是不定的，具体是收不到包就马上出发NACK，还是说需要等待一小段时间看没到达的包是否会到达再决定是否发送NACK，这个具体要带webrtc的代码实现了。

 

webrtc RTX 处理

 

webrtc中默认开启rtx用于丢包重传，rtx的介绍可以参考rfc4588，https://tools.ietf.org/html/rfc4588#section-4

rtx使用额外的ssrc传输，ssrc在sdp中会标识出来。

↵a=rtpmap:97 rtx/90000
↵a=ssrc-group:FID 2736695910 239189782

类似这样。

一个RTX包，在turnserver中是这样的，原始udp数据->turn/stun协议头->RTP header1 ->RTP header2

在RTP header1中根据payload type进行区别RTP、RTX数据，如果是RTX的话，需要srtp解出后面的数据，再解析。

 

在客户端中，RTX封包的关键函数是：

https://code.google.com/p/webrtc/source/detail?r=4692
Channel::IsPacketRetransmitted
Channel::HandleRtxPacket
rtp_payload_registry_->IsRtx
RTPPayloadRegistry::RestoreOriginalPacket    移除RTX头, 还原原始的RTP

链接是，webrtc加入rtx的issue

 

目前webrtc的服务器，例如licode，janus是禁止rtx的。以避免复杂的处理。

 

 

from：http://blog.csdn.net/dittychen/article/details/70214713

 

 

 

 

 

WebRTC中的前向纠错编码 - Red Packet

from: http://blog.csdn.net/volvet/article/details/53573359

 

WebRTC 的FEC(前向纠错编码) 是其QoS的重要组成部分, 用于网络丢包的时候恢复原始数据包, 减少重传次数, 减少延时, 改善视频质量. 它是RFC 5109标准的实现. 下文, 我们将深入剖析其原理.

Redundant Coding

要理解WebRTC中的FEC, 首先需要先了解Red Packet. 所谓Red Packet, 就是Redundant Coding 产生的包. 其定义非常简单, 下面来看Block Header的格式:

 

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其定义如下: 
F: 1 bit, 1 表示后面跟着其他的Block Header, 0 表示这个Block Header就是最后一个. 
Block PT: 7 bits, 是这个block payload的 payload type 
Timestamp Offset: 14 bits, 无符号数, 是RTP 的Timestamp 到这个Data block的时间偏移 
Block Lenth: 10 bits, 是Data Block 长度.

另一种Primary Data Header, 之需要1byte

|F| Block PT|

用来描述最后的一个Data Block, 其TimeStamp 就是RTP Header的Timestap. 
WebRTC的Red Packet, 编码时， 用一个rtp packet 产生 1个red packet， 所以使用了 Primary Data Header来描述的

如何协商 数据和Rad Channel 的绑定关系呢?

m=audio 12345 RTP/AVP 121 0 5 a=rtpmap:121 red/8000/1

这段SDP 表示, RTP 音频 Session, 它的Payload Type 是121, 0, 5, Codec Red payload type 是121.

下面来看一个例子:

0 12 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0 |M| PT | sequence number of primary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp of primary encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| block PT=7 | timestamp offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| block PT=5 | | +-+-+-+-+-+-+-+-+ + |                                     | + LPC encoded redundant data (PT=7) + | (14 bytes) | + +---------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | | + + | | + + | DVI4 encoded primary data (PT=5) | + (84 bytes, not to scale) + / / + + | | + + | | + +---------------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

WebRTC中的实现:

// 生成Rad Packet RedPacket* ProducerFec::BuildRedPacket(const uint8_t* data_buffer, size_t payload_length, size_t rtp_header_length, int red_pl_type) { RedPacket* red_packet = new RedPacket( payload_length + kREDForFECHeaderLength + rtp_header_length); int pl_type = data_buffer[1] & 0x7f; red_packet->CreateHeader(data_buffer, rtp_header_length, red_pl_type, pl_type); red_packet->AssignPayload(data_buffer + rtp_header_length, payload_length); return red_packet; }

// 生成RedPacket Header void RedPacket::CreateHeader(const uint8_t* rtp_header, size_t header_length,int red_pl_type, int pl_type) { memcpy(data_, rtp_header, header_length); // Replace payload type. data_[1] &= 0x80; data_[1] += red_pl_type; // Add RED header // f-bit always 0 data_[header_length] = static_cast(pl_type); header_length_ = header_length + kREDForFECHeaderLength; }

// 填上Payload void RedPacket::AssignPayload(const uint8_t* payload, size_t length) { memcpy(data_ + header_length_, payload, length); }

Reference: 
1. rfc2198 - RTP Payload for Redundant Audio Data 
2. rfc5109 - RTP Payload Format for Generic Forward Error Correction

 

 

 

 

 

 

 

 

 

 

WebRTC的NACK和RTX简述

from: https://blog.csdn.net/sonysuqin/article/details/82021185

背景
在丢包 10%下测试WebRTC，发现丢包导致的卡顿，需要一些开启一些机制来保证丢包重传。

摘要
简述WebRTC中NACK、RTX的功能和联系。

正文
NACK、RTX是WebRTC里丢包重传策略，两个策略之间有一定的联系。
NACK：接收端通过RTCP将丢包的序列号通知给发送端，让发送端重传该包。
RTX：发送端在新的SSRC上发送重传包或者冗余包。

两者均需要通过sdp协商开启，在支持的服务端(例如Janus)修改SDP即可开启。

要点
重传包不一定通过RTX发送；
RTX包不一定用来重传丢失的包。
解释
在发送端收到NACK后，要重发接收端丢掉的包，发送的模式有两种：

RTX模式
在接收端通过SDP使能发送端的RTX以后，重发的包封装到RTX包里发送，RTX包与原RTP有不同的SSRC，这样有助于避免SRTP的重放攻击，也能让接收端更好的估算带宽；
普通模式
在没有使能RTX时，发送端只是简单的重发原来的RTP包，这种模式会影响接收端的RTCP统计，比如会出现负的丢包率。
另外，RTX包有两种

收到NACK重发的包
如上述；
发送端发送的冗余Padding包
发送端的初始码率在达不到目标码率的情况下，会通过发送RTX包来补充，以能够逼近目标码率，当然这个机制必须启用RTX才能激活。因此，接收端可能会收到两种RTX包，一种是被NACK触发的，一种是发送端用来补充发送码率的冗余包。