FEC前向纠错算法

目前找到了两种方案：

1、使用openfec    http://openfec.org/accueil.html

但是该开源库代码量比较大，用起来也有点费事；编译通过cmake进行编译成一动态库（or静态库），window下cygwin内置cmake，可以顺利的编译（查看其readme），但是移植到android等其它ARM平台时比较麻烦（因为我不熟悉cmake）；

2、使用更加小巧的feclib http://feclib.sourceforge.net/

该算法也是开源的，但是代码量比较小，只需在工程中添加其相关的几个代码文件即可；

不过该算法不能纠正数据包内部的错误，直接通过冗余包找到丢失的数据包；如果需要纠正数据包内部的错误，其官网推荐了另外一个算法RSCODE http://rscode.sourceforge.net/

时间： 2024-10-08 09:35:39

FEC前向纠错算法的相关文章

前向纠错码(FEC)的RTP荷载格式

http://www.rosoo.net/a/201110/15146.html 本文档规定了一般性的前向纠错的媒体数据流的RTP打包格式.这种格式针对基于异或操作的FEC算法进行了特殊设计,它允许终端系统使用任意长度的纠错码,并且可以同时恢复出荷载数据和RTP头中的关键数据.由于FEC作为一个分离的数据流进行传送,这种方案可以向后兼容那些没 TAG: 中文版  RTP荷载  FEC  前向纠错码 本备忘录状态    本文档讲述了一种Internet通信的标准Internet跟踪协议,并对其改进

UDP 两种丢包处理策略：丢包重传（ARQ） 和 前向纠错（FEC）

目录 1. 两种丢包处理策略 2. 前向纠错(FEC) 3. 丢包重传(ARQ) [参考文献] 1. 两种丢包处理策略 为了保证实时性,通常适应UDP协议来针对RTP数据进行传输,而UDP无法保证数据传输的质量,所以在网络环境不好的时候,丢包是经常出现的问题,有什么策略来改善这个问题吗? 常用的方法有: 丢包重传(ARQ)和前向纠错(FEC). 通常抗丢包有两种方式,FEC和ARQ.FEC是前向冗余,举个例子,发送数据A和B,增加发送一个数据C等于A和B的异或.接收方接到这3个包的任意2个包,异

FEC之我见四

接上文,来详细的说明一下FEC前向纠错的具体实现: FEC_matrix是一个比较常用的算法,Vandermonde,范德蒙矩阵是法国数学家范德蒙提出的一种各列为几何级数的矩阵. 范德蒙矩阵的定义: V = 其第i 行.第j 列可以表示为(αi)^(j-1). 范德蒙矩阵的性质:范德蒙矩阵行数为m,列数为n,矩阵具有最大的秩min(m, n). 范德蒙矩阵的应用:范德蒙矩阵应用之一就是在纠错编码中,常用的纠错码Reed-solomon 编码中冗余块的编码采用的即为范德蒙矩阵. 1)码流层面上的F

FEC之我见一

顾名思义,FEC前向纠错,根据收到的包进行计算获取丢掉的包,而和大神沟通的结果就是 纠错神髓:收到的媒体包+冗余包 >= 原始媒体包数据 直到满足 收到的媒体包+ 冗余包 >= 原始媒体包数据       则进入恢复模式,恢复出2 4,然后一次输出2 3 4 5 所谓的Qos,也可以理解为抖动缓冲,解决udp包乱序.包重复的问题 NAT保活,保持udp连接,简言之: 当你向一个公网服务器发送数据时,服务器可以翻转IP和端口向你发数据, 但如果你长时间不发数据给服务器,服务器若想用之前的IP和端

如何优化传输机制来实现实时音视频的超低延迟？

1.前言 要在语音视频 SDK 中实现超低延迟,实时的语音视频传输机制是必不可少的,而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石. 在语音社交.视频社交.游戏语音和互动直播等领域,关于在语音视频实时传输中实现低延迟这个议题,已经有不少的文章提出各种方案.绝大部分方案的思路都是"优化",比如说,优化编码.推流.传输和播放等各个环节. 愚以为,要在实时语音视频传输中获得超低延迟,是不能单靠挖空心思去"优化"的,而是要依靠实时的传输机制.就像高铁和火车有

音频开发基础知识简介

在现实生活中,音频(audio)主要用在两大场景中:语音(voice)和音乐(music).语音主要用于沟通通信,如打电话,现在由于语音识别的发展,人机语音交互也是语音的一个应用,目前正在风口上,好多大厂都推出了智能音箱.音乐主要用于欣赏,如音乐播放. 下面简单介绍音频的基础知识: 采样和采样频率:现在是数字时代,在音频处理时要先把音频的模拟信号变成数字信号,这叫A/D转换.要把音频的模拟信号变成数字信号,就需要采样,或者叫抽样.当要把音频播放出来时则需要把数字信号转换成模拟信号,这叫D/A转换

浅析低延迟直播协议设计：RTP/RTCP

转自:http://blog.csdn.net/dj0379/article/details/51960237 如今的直播市场非常火爆,有很多直播云服务的提供商可供产品选择.同时视频直播产品喷涌而出,比如大家耳熟能详的映客.YY,还有最近特别火爆的一直播. 基于TCP的协议延迟不够低 众所周知,直播中通用CDN大部分提供的是RTMP的方案以及HLS的方案.HLS在手机H5里面的兼容性非常好,而RTMP是Adobe的协议,它在延迟.稳定性和分发质量方面平衡得很不错.但是当涉及会议场景时,基于TCP

团战开黑必备“良药”了解一下！

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由腾讯游戏云发表于云+社区专栏 第十八届亚运会在印度尼西亚首都雅加达进行得如火如荼,电子竞技作为2018亚运会的表演赛项目,首次登上亚运会的舞台.对于团队合作的电竞赛事来说,队友间的"语音"交流不可或缺.实时与队友流畅沟通战术,交流操作已成为电竞选手在比赛中取得好成绩的一大关键. 随着移动设备性能大幅攀升,移动游戏也从场景简单的休闲类游戏发展为更追求操作和游戏体验的竞技类和大型MMO类等重度游戏,游戏中嵌入实时语音功能也已

新一代互联网传输协议QUIC

QUIC(Quick UDP Internet Connections,快速UDP互联网连接)是Google提出的一种基于UDP改进的通信协议,其目的是降低网络通信的延迟,提供更好的用户互动体验. QUIC的主要特点包括:具有SPDY(SPDY是谷歌研制的提升HTTP速度的协议,是HTTP/2.0的基础)所有的优点:0-RTT连接:减少丢包:前向纠错,减少重传时延:自适应拥塞控制, 减少重新连接:相当于TLS加密. 1.重传与恢复 与TCP类似,QUIC每发送一个包后,都会等待回复一个确认包.当