Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >webrtc技术原理_webrtc开源项目

webrtc技术原理_webrtc开源项目

作者头像
全栈程序员站长
发布于 2022-09-22 09:08:15
发布于 2022-09-22 09:08:15
3.4K0
举报

大家好,又见面了,我是你们的朋友全栈君。

一、概述

webrtc冗余打包方式有三种:Red(rfc2198)、Ulpfec(rfc5109)、Flexfec(草案)。其中Red和Ulpfec要成对使用。

二、RedFEC

简单将老报文打包到新包上。如下图所示,冗余度为1时,RFC2198打包情况:

这种方法在音视频领域几乎不使用,因为冗余包只能保护特定一个报文,这种方法带宽占用量很大,恢复能力有限,性价比很低。只是早期的T38传真、RFC2833收号会使用该协议,因为传真和收号的数据量比较小。

webrtc里面说使用了RFC2198冗余,实际上仅仅是借用该协议的封装格式,封装FEC冗余报文。

三、UlpFEC

详细介绍可参考:webrtc QOS方法二.2(ulpfec rfc5109简介)_CrystalShaw的博客-CSDN博客_ulpfec

将一组M个报文进行异或,生成N(N就是FEC的冗余度)个FEC报文,打包出去。这组报文任意丢其中的N个,都可以通过这组(M-N)个报文+FEC冗余包恢复回来,比简单的RFC2198保护的范围扩大了很多。例如下面示意图:D为媒体包,R为冗余包,该图所示的冗余度为2。

1、发送端打包示意图

2、网络丢包示意图

3、丢包恢复示意图

webrtc通过PacketMaskTable表格在选取异或模板。PacketMaskTable表格有连续丢包(kFecMaskBursty、kPacketMaskBurstyTbl)、随机丢包(kFecMaskRandom、kPacketMaskRandomTbl)两种模型。

理论上webrtc可以通过损失程度和乱序情况相关的反馈,自适应选择kFecMaskRandom还是kFecMaskBursty,效果比较好。但是可惜的是,webrtc这块功能缺失,默认使用随机丢包模型。

四、FlexFEC

同UlpFEC实现方式,ULPFEC仅在1D行数组上进行异或,FlexFec更灵活,引进了交织算法,可以在1D行、列、2D数组异或。

1、1D行异或

2、1D列异或

3、2D行列异或

这块还是草案,如何选择异或模式的代码看没深入下去。后续补充。

需要注意,开启FlexFEC需要同时使能 WebRTC-FlexFEC-03/Enabled && WebRTC-FlexFEC-03-Advertised/Enabled 否则会出现死机异常

五、FEC算法汇总

FEC是无线传输领域的一个前向纠错的算法。网上搜资料的时候经常把无线的算法看的云里雾里的,研究半天都不知道这个和视频传输有什么关系。

无线传输领域的FEC算法主要有TURBO、LDPC、POLAR这三种。

音视频传输领域的FEC算法有如下几种:

1、webrtc的opus音频使用的是inband FEC和交织编码

2、webrtc的视频ulpfec使用的是异或XOR

3、Reed Solomon算法比较复杂,理论上数据恢复能力比较强。

六、webrtc代码分析

1)使能FEC

webrtc默认使能Red+Ulp的FEC。Flex仅在实验阶段,还不能正式使用。

2)封装FEC

  • 发送冗余报文处理

RTPSenderVideo::SendVideo。当编码器支持时间分层,可以仅冗余level 0的视频数据。否则,就要冗余所有视频数据。冗余度是根据丢包率动态调整。

  • 动态调整冗余参数调用栈

BitrateAllocator::OnNetworkChanged ->VideoSendStreamImpl::OnBitrateUpdated ->ProtectionBitrateCalculator::SetTargetRates ->media_optimization::VCMLossProtectionLogic::UpdateMethod ->media_optimization::VCMNackFecMethod::UpdateParameters

  • 最大保护帧数确定

VCMNackFecMethod::ComputeMaxFramesFec

  • 冗余报文个数确定

ForwardErrorCorrection::NumFecPackets 存储媒体报文数*保护因子。

  • 根据丢包率动态调整冗余度

VCMFecMethod::ProtectionFactor

  • 根据丢包模型原则要冗余的报文

ForwardErrorCorrection::EncodeFec

ForwardErrorCorrection::GenerateFecPayloads

备注:

webrtc在H264编码默认关闭ULPFEC功能,但是可以开启FlexFEC

MaybeCreateFecGenerator

->ShouldDisableRedAndUlpfec

->PayloadTypeSupportsSkippingFecPackets

参考

RED (REDundant coding) – WebRTC Glossary

ULPFEC (Uneven Level Protection Forward Error Correction) – WebRTC Glossary

webrtc fec – 明明是悟空 – 博客园

FEC算法_cloudfly_cn的博客-CSDN博客_fec算法

ulp-fec,flex-fec mask表解读_zhenfei2017的博客-CSDN博客(介绍冗余度和冗余Mask参数)

发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/169598.html原文链接:https://javaforall.cn

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
webRTC-NACK、Pacer和拥塞控制和FEC
2)NACK重新发送媒体数据有两种方式:单独RTX通道发送、与媒体数据混在一起发送
_咯噔_
2022/04/28
1.8K0
WebRTC系列分享 | WebRTC视频QoS全局技术栈
导语 | WebRTC真是一套让人既爱又恨的开源代码。一方面,WebRTC里面有一套很完善很系统的QoS策略。但另一方面,WebRTC代码庞大且版本更新迭代特别快,代码的阅读和学习难度很大。为了方便大家学习了解,我们在这里对WebRTC的QoS思想及算法实现做了一些梳理总结,以系列分享的方式呈现给大家,供大家参考。 概述 目前总结出WebRTC用于提升QoS的方法有:NACK、FEC、SVC、JitterBuffer、IDR Request、Pacer、Sender Side BWE、Probe、VFR(
腾讯云音视频
2022/03/15
2.8K0
音视频FEC前向纠错的原理和实现
TCP协议的重传机制对实时音视频传输而言,如果网络质量很差,丢包率很高,重传机制导致传输延迟急剧增加,传输质量严重下滑。实时音视频传输协议一般采用UDP(应用层基于UDP的RTP协议,为视频传输提供序号和音视频同步服务),UDP具有高吞吐和低延时的特点。然而,基于UDP的RTP传输在复杂的公网环境下,特别是3G、4G、WIFI网络时面临丢包、乱序、重复、抖动等问题,严重影响实时音视频的传输效果。应用层的 FEC (Forward Error Correction,前向纠错)是一项有效防止丢包的技术,是一种实时视频传输的有效可靠的解决方案。
用户6280468
2023/09/21
2.2K0
音视频FEC前向纠错的原理和实现
WebRTC-FEC[通俗易懂]
本文档为封装在RTP中的媒体数据的通用前向纠错(FEC)指定了有效负载格式。它基于异或(奇偶校验)操作。本文档中描述的有效负载格式允许终端系统使用不同的保护长度和级别来应用保护,此外还使用不同的保护组大小来适应不同的媒体和信道特性。它能够根据丢包情况完全恢复受保护的数据包或部分恢复有效负载的关键部分。该方案与不支持FEC的主机完全兼容,因此不实现FEC的多播组中的接收机只需忽略保护数据即可工作。本规范淘汰了RFC 2733和RFC 3009。本文件中规定的FEC与RFC 2733和RFC 3009不向后兼容。
全栈程序员站长
2022/09/22
1.6K0
WebRTC-FEC[通俗易懂]
音视频 RED 与 FEC 的 RTP 格式封装[通俗易懂]
对于语音通信来说,语音的码率较低,添加适当的冗余是对抗网络丢包常见的方式。冗余方式分为多种,包括数据冗余,或者编码冗余等,RED,FEC等都是冗余的一种。如果冗余分数较多,可以采取交织的方式实现。RFC 2198 是冗余数据 RTP 封装的标准协议,RFC 3550 为RTP的基础标准协议,RFC 5109 为FEC数据的 RTP 封装标准协议。webrtc中有RED和FEC相关的实现与处理,这也是在看代码时才决定重新整理协议并记录下来。
全栈程序员站长
2022/09/22
1.7K0
Webrtc fec 废除_webtec
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/169589.html原文链接:https://javaforall.cn
全栈程序员站长
2022/09/22
4680
技术解码 | RSFEC原理分析
作者 | 蒋刚 审校 | 刘连响 ---- 今天向大家介绍下RSFEC的原理,它通过生成冗余数据来恢复丢失的信息,首先介绍下背景,之后重点介绍RSFEC如何计算冗余和恢复数据的,分为异或方式和矩阵方式,异或方式可以认为是矩阵方式的特殊形式,最后做下总结。 - 背景介绍 - RSFEC广泛应用于存储、通信、二维码等领域,比如RAID利用它生成冗余盘提升容错性,视频通话中利用它生成冗余数据对抗网络丢包,太空中远距离传输数据时也用到它,第三张图片是旅行者一号应用RSFEC将太空中拍摄的照片传回地
腾讯云音视频
2021/06/25
3.3K0
腾讯云H5语音通信QoE优化|云+沙龙
导语:4月21日,腾讯云+社区在京举办“‘音’你而来,‘视’而可见——音视频技术开发实战沙龙”,腾讯音视频实验室高级工程师张轲围绕网络传输方面讲解了《腾讯云H5语音通信QoE优化》,包含腾讯云H5解决方案,音频QOS优化整体框架及优化技术,和运营方法几个方面。QOS优化包含带宽估计拥塞控制、抗丢包技术、延时、抗抖动技术四个领域。张珂重点分享了WebRTC与WebRTC之间,tbs与WebRTC之间,tbs与natvie之间互通所涉及的QoS相关的技术问题,回溯分析工具能够提高工作效率,可以快速发现潜在技术改
腾讯多媒体实验室
2018/05/29
3.6K0
张轲:腾讯云H5语音通信QoE优化
    11月份,W3C发布了WebRTC的标准。另外一个专注于WebRTC的国际组织RETF在12月份也发布了第一个RFC8298,目前还没有成为真正的标准。我今天讲的重点,是围绕网络传输的一些心得。
腾讯云开发者社区技术沙龙
2018/04/25
7.1K2
张轲:腾讯云H5语音通信QoE优化
WebRTC的拥塞控制和带宽策略
在视频通信的技术领域WebRTC已成为主流的技术标准,WebRTC包涵了诸多优秀的技术,譬如:音频数字信号处理技术(AEC, NS, AGC)、编解码技术、实时传输技术、P2P技术等,这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中,通信时延、图像质量下降和丢包卡顿是经常发生的事,甚至在WiFi环境下,一次视频重发的网络风暴可以引起WiFi网络间歇性中断,通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。
LiveVideoStack
2021/09/01
1.5K0
WebRTC系列分享 第五期 | WebRTC QoS方法之Sender Side BWE实现
导语 | 本文为大家详细解读一下WebRTC中Sender Side BWE的实现。文章中引用的WebRTC代码基于master,commit:f412945f05ce1ac372a7dad77d85498d23deaae源码分析。 背景介绍 BWE(Bandwidth Estimation)可能是WebRTC视频引擎中最关键的模块了。BWE模块决定视频通讯中可以发送多大码率视频不会使网络拥塞,防止视频通讯质量下降。 早期的带宽评估算法比较简单,大多是基于丢包来估计,基本的策略是逐步增加发送的数据量,直到
腾讯云音视频
2022/05/12
1.7K0
WebRTC系列分享 第五期 | WebRTC QoS方法之Sender Side BWE实现
视频直播技术干货(十三):B站实时视频直播技术实践和音视频知识入门
直播行业从传统的娱乐直播发展到教育直播、电商直播等形式,产生了很多新的玩法。传统的直播是一位主播展示才艺,观众通过弹幕、送礼物等方式进行互动。随着网络质量不断地提高,用户也对直播平台产生的新的要求,实时互动直播的场景就出现了,观众可以同时观看多位主播之间互动的画面,让直播间的气氛更好。B站直播的连麦PK、视频连线业务就提供了这个能力。主播看到的是对方主播实时的流(延迟400ms以内),而观众看到的是“准实时”的流(延迟2~5s左右)。
JackJiang
2025/03/06
2070
视频直播技术干货(十三):B站实时视频直播技术实践和音视频知识入门
rtp载荷类型_架体荷载
大家好,又见面了,我是你们的朋友全栈君。 1简介 在Internet上用分组传送话音的质量不够好的一个重要原因是比较高的丢包率。尤其在 广域网中,这个问题相当突出。不幸的是,实时多媒体业务对于延时的要求相当严格,因此 不大可能通过重传来解决丢包的问题。 正是出于这个原因,大家提出用前向纠错(FEC)来解决Internet上的丢包问题[1][2]。 尤其是对于传统纠错码如校验码、RS码、汉明码等的使用引起了很多人的注意。为了能够更 好地应用这些纠错码,必须有相关的 协议来支持。 本文档定义了一种RTP的荷载格式,允许对于实时媒体流进行一般性的前向纠错。在这 里“一般性”指的是(1)与被保护的媒体类型无关,即音频、视频或其它;(2)足够灵活, 能够支持多种FEC机制;(3)自适应性,可以方便的修改FEC方案而不需要带外的信令支持; (4)支持若干种不同的FEC包的传输机制。 2术语 本文档中使用了下面这些术语: 媒体荷载:一段待传输的未加保护的用户数据。媒体荷载放在一个RTP包的内部。 媒体头:包含媒体荷载的包的RTP头 媒体包:媒体荷载与媒体头合起来称作媒体包 FEC包:发送端将媒体包作为前向纠错算法的输入,输出除了这些媒体包之外,还有一些 新的数据包称作FEC包。FEC包的格式在本文档中进行说明。 FEC头:FEC包的头信息称作FEC头。 FEC荷载:FEC荷载是FEC包中的荷载。 关联的:一个FEC包称作与一个或几个媒体包是关联的,如果在这个FEC包的产生过程 中这几个媒体包用作EC算法的输入 关键词“必须”,“必须不”,“要求的”,“会“,”不会“,“应该”,“不应该”, “建议的”,“或许”,“可选的”在 RFC2119[4]中解释。 3基本操作 这里描述的荷载格式用于一个RTP会话中的某一端想要用FEC来保护它所传送的媒体数 据流的情况。这种格式所支持的FEC是基于简单异或校验的纠错算法。发送端从媒体数据流 中取出若干个包,并对它们整个施以异或操作,包括RTP头。基于这样一个过程,可以得到 一个包含FEC信息的RTP包。这个包可以被接收端用来恢复任何一个用来产生它的包。本文 档中并未规定多少个媒体包合起来产生一个FEC包。不同参数的选取会导致在overhead,延 时和恢复能力之间的一个不同的折中方案。第4节给出了一些可能的组合。 发送端需要告诉接收端哪些媒体包被用来产生了一个FEC包,这些信息都包含在荷载信 息中。每个FEC包中包含一个24比特的mask,如果mask的第i个比特为1,序号为N+i 的媒体包就参与了这个FEC包的生成。N称作基序号,也在FEC包中传送。通过这样一种方 案就可以以相当小的overhead来用任意的FEC纠错方案恢复丢失的数据包。 本文档也描述了如何使接收端在不了解具体纠错码细节的情况下利用FEC的方法。这就 给了发送端更大的灵活性,它可以根据网络状态而自适应选择纠错码,而接收端仍能够正确 解码并用于恢复丢失的包。 发送端生成FEC包之后,就把它们发给接收端,同时,发送端也照常发送原来的媒体数 据包,就好像没有FEC一样。这样对于没有FEC解码能力的接收端,媒体流也照常可以接收 并解码。然而,对于某些纠错码来说,原始的媒体数据包是不需要传输的,仅靠FEC包就足 以恢复丢失的包了。这类码就具有一个很大的缺点,就是要求所有的接收者都具有FEC解码 能力。这类码在本文档中也是支持的。 FEC包并不与媒体包在同一个RTP流中传输,而是在一个独立的流中传输,或者作为冗 余编码(redundantencoding)中的次编码(secondaryencoding)来传输[5]。当在另一个 流中传输时,FEC包有它们自己的序号空间。FEC包的时间戳是从对应的媒体包中得来的,同 样是单调递增。因此,这样的FEC包可以很好地应用于任何具有固定差值的包头压缩方案。 本文并没有规定何为“一个独立的流”,而把它留给上层 协议和具体应用去定义。对于 多播的情况,“一个独立的流”可以通过不同的多播组来实现,或者同一个组的不同端口, 或者同样的组和端口中不同的SSRC。对于单播的情况,可以使用不同的端口或者不同的SSRC。 这些方法都各有其优缺点,选用哪一种取决于具体的应用。 接收端收到FEC包和媒体包之后,先判断是否有媒体包丢失。如果没有,FEC包就直接 被丢弃。如果有丢包,就使用接收到的FEC包和媒体包来进行丢包的重建。这样一个重建过 程是很精确的,荷载以及包头的大部分数据都可以完全恢复出来。 按照本 协议来进行打包的RTP包可以使用一个动态RTP荷载类型号来通知接收端。 4监督码 我们定义f(x,y,..)为数据包x,y,…等的异或,这个函数的输出也是一个数据包,称作 监督包。为简单起见,我们
全栈程序员站长
2022/09/22
3620
WebRTC系列分享 第三期 | WebRTC QoS方法之视频发送端NACK实现
导语 | 本文为大家详细解读一下WebRTC中视频发送端NACK的实现。文章中引用的WebRTC代码基于master,commit:f412945f05ce1ac372a7dad77d85498d23deaae源码分析。
腾讯云音视频
2022/04/11
1.1K0
WebRTC系列分享 第三期 | WebRTC QoS方法之视频发送端NACK实现
腾讯天籁:音频联合信源信道编码技术白皮书
前言 2020年疫情的突如其来,让数字通信成为了人与人沟通的重要手段;同时也对实时音视频通信(RTC)的稳定性和通讯效果提供了极大考验。由于业务量激增,在保障用户体验方面,RTC业务面临着诸多困难,包括但不限于通话质量、最小化卡顿、端到端延时、带宽成本等。在网络传输过程中,RTC方案,需要面对用户体验、运营成本的双重约束,挑战巨大。本白皮书,将聚焦RTC业务中网络抗性下的体验保障这一命题展开讨论。本文首先对相关技术的特点进行描述。然后,本文重点介绍腾讯天籁推出的音频联合信源信道编码方案。该方案已经在腾
腾讯技术工程官方号
2020/12/21
1.6K0
展望2018音视频技术:AV1,AI,区块链,WebRTC
实时音视频技术是源于早期的VoIP通信,随着后来互联网的发展进程,这项技术2003年被Skype引入到PC桌面系统,开启了整个实时音视频技术新纪元。经过15年的进化,基于PC上的实时音视频技术日渐成熟,也涌现了像WebRTC这样的开源项目。但随着近几年移动互联网和4G的兴起,实时音视频领域有了更广泛的应用,引来了新的技术难题和挑战。经过2016年直播大战后,音视频应用得到了用户的认可,直接促成了2017年实时音视频应用的大爆发,在娱乐方面出现了像狼人杀、陌生人视频社交、在线抓娃娃等风口;在协作应用领域出现了Slack和Zoom等多人远程协作应用;在行业应用上也有很大的突破,例如像VIPKID、学霸君1V1等强劲的在线教育产品。在苹果8月份宣布新一代iOS浏览器Safari支持WebRTC后,实时音视频技术成为了时下热门技术体系。
LiveVideoStack
2021/09/02
7910
展望2018音视频技术:AV1,AI,区块链,WebRTC
不为人知的网络编程(七):如何让不可靠的UDP变的可靠?
最近和很多实时音视频领域的朋友交流中都有谈论到 RUDP(Reliable UDP),这其实是个老生常谈的问题,RUDP 在很多著名的项目上都有使用,例如 Google 的 QUIC 和 WebRTC。在 UDP 之上做一层可靠,很多朋友认为这是很不靠谱的事情,也有朋友认为这是一个大杀器,可以解决实时领域里大部分问题。
JackJiang
2018/08/29
2.4K0
融云技术分享:基于WebRTC的实时音视频首帧显示时间优化实践
本文由融云技术团队原创投稿,作者是融云WebRTC高级工程师苏道,转载请注明出处。
JackJiang
2020/09/28
1.3K0
P2P技术如何将实时视频直播带宽降低75%?
实时视频直播经过去年的千播大战后已经成为互联网应用的标配技术,但直播平台的成本却一直居高不下,各个平台除了挖主播、挖网红以外,其背后高额的带宽费用也是他们最大的一块成本。
JackJiang
2018/08/29
5.6K0
技术解码 | WebRTC ICE 模块剖析
ICE全称 Interactive Connectivity Establishment ——交互式连通建设形式。 ICE背后的基本思想如下:每个代理都有各种各样的Candidate Transport 地址(IP地址和端口的组合,特定的传输协议(在此中始终为UDP规范))。它可以用来与其他代理进行通信。 这些地址包括: 直接连接的网络接口上的传输地址 ——公网IP直连 NAT公共端的转换传输地址  ——内网NAT映射 从TURN服务器分配的传输地址 ——中继模式 对于1 公网IP直连这类情
腾讯云音视频
2021/08/04
4.1K0
相关推荐
webRTC-NACK、Pacer和拥塞控制和FEC
更多 >
领券
💥开发者 MCP广场重磅上线!
精选全网热门MCP server,让你的AI更好用 🚀
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档