我是靠谱客的博主 无私手套,最近开发中收集的这篇文章主要介绍WebRTC 的前向纠错编码 - XOR FEC,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

FEC Format

WebRTC 应用RFC 5109所定义的 XOR 来对RTP 数据进行保护, 以抵抗网络丢包. 协议所定义的包结构如下:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header (12 octets or more) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Header (10 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 0 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Level 1 Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cont. |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP Header 就是 RFC 3550 所定义的RTP 报文结构的头部. 如果这个RTP Packet 是FEC包的话,
M - Marker 必须为0, 对于FEC 而言, Marker 是无意义的.
SSRC - SSRC必须跟这个FEC所要保护的RTP 数据包的 SSRC一致, 表示这两者是同源的。
TimeStamp - Timestamp的时钟频率必须跟这个FEC所要保护的媒体数据的时钟频率一致.
Payload - FEC 包的Payload type 是需要通过SDP协商给定的。
对于不支持这FEC的系统, 简单丢弃其接收到的FEC包即可, 不影响它对数据报的处理.

这里有多个FEC Level Header, 是用来做ULP 保护的, ULP可以产生多种交织的保护方式, 比较复杂。 不过WebRTC不支持ULP, 只能使用FEC Level 0 对数据进行保护.

FEC 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|L|P|X| CC |M| PT recovery | SN base |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length recovery |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E - 1 bit, 保留位, 必须为0
L - 1 bit, 用来标示 FEC Level Header里的MASK 是否为 Long Mask, 普通的MASK 长度为16 bits,  一个FEC 数据包 Group 的包个数最多为16个, Long MASK 长度为 48 bits, 一个FEC 数据包Group的包个数最多为48个.
P - 1 bits, X - 1 bits, CC - 4 bits, M - 1bit, 用来产生RTP Header里相应字段的保护位。 
PT recovery - 7 bits  数据包 payload type 的保护位
TS recovery - 32 bits, 数据报Timestamp的保护位
SN base - 数据包里的最小sequence.
Length recovery - 16 bits, 数据长度的保护位, 数据包的长度是 CSRC List, payload, padding 的总长度

ULP Level 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protection Length | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask cont. (present only when L = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Protection length - FEC 数据长度
MASK - 如前所述,  MASK 可以是16 bits 的 short mask, 或 48 bits 的 long mask, 是用单个bit 位来定义 其对应 sequence 的rtp 数据报是否属于这个FEC包要保护的Data Group. 其对应关系很简单, 就是从SN base 开始的连续的16 or 48个包分别对应于mask 的比特位,  1表示这个数据包被保护, 0 表示这个数据包不被保护。

Red Packet

WebRTC 对相应的数据包Group产生FEC包之后, 数据包和FEC包都被重新编码为Red Packet,然后进行传输. 关于Red Packet, 可以参看 http://blog.csdn.net/volvet/article/details/53573359

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

最后

以上就是无私手套为你收集整理的WebRTC 的前向纠错编码 - XOR FEC的全部内容,希望文章能够帮你解决WebRTC 的前向纠错编码 - XOR FEC所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(41)

评论列表共有 0 条评论

立即
投稿
返回
顶部