- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
摘要 。
随着GPT-4的发布,AI的风越吹越旺。GPT-4可以回答问题,可以写作,甚至可以基于一张草图生成html代码搭建一个网站。即构社区的一位开发者@倪同学就基于目前在研究的WebRTC QOS技术点对GPT-3.5跟GPT-4进行一场实验,ChatGPT会取代程序员还是成为最强辅助?
以下为@倪同学的博文.
这两周,AI新闻一个接着一个,3月23日,Google开放了内测已久的AI对话服务Bard,Google强调,这是一款定位为用户提供创意之源的产品,可生成写作草稿或生活中的聊天机器人。早在一周前3月15日凌晨,OpenAi距发布GPT-3.5后四个月发布了升级版模型GPT-4,据发布会说,GPT-4可支持图片输入,角色扮演,写作能力更强了。紧接着3月16日百度发布了文心一言,一共有五大功能:文学创作、商业文案创作、数理逻辑推算、中文理解、多模态生成.
随着近日各大厂商AI产品的接连发布, AI取代人工 这个话题持续在发酵。AI大幅解放人的生产力或是将冲击一大批职业?
博主近期在输出WebRTC相关的技术博客,不如向AI提问看他有什么见解.
和大部分人一样,博主都还没拿到Bard跟文心一言的内测资格。得知NewBing用的是GPT-4的模型,下面就着 WebRTC通过哪些QOS技术提升音视频通话质量 ,向GPT-3.5和Newbing(GPT-4)分别提问,看看他们的答案有何差异.
如下图,技术科普类问题都难不倒GPT-3.5和GPT-4,我就该问题继续深挖让它们举实例说明:
NewBing(GPT-4) 。
GPT-3.5给出的结果 。
NewBing(GPT-4)直接给出了具体操作实例 。
GPT-3.5给出的结果(有些空泛) 。
通过实验,我们比较了同一问题两个版本的回答。在普通的文本处理当中,GPT-4和GPT-3.5的区别可能比较小,但是当问题足够具体和复杂时,GPT-4就会比GPT-3.5更精准、更有创意,而且能够处理用户更细微的指令.
当然,本篇内容不是要讨论GPT-3.5跟GPT-4的具体差别,而是程序员如何利用ChatGPT提升工作效率,加上最强Buff。以下我将以个人开发经验为音视频开发者分享《 WebRTC的QOS如何提升音视频质量》.
WebRTC 通过一系列的QOS 技术来提升音视频通话质量: 抗丢包策略(NACK、 FEC), 拥塞控制策略(TWCC/REMB), SVC或多视轨, 视频质量自适应策略, Pacer、JitterBuffer等. 。
总体QOS架构如下图所示:
图 1 。
NACK(Negative Acknowledgment)相较于ACK是通过"非到达确认"进行选择性重传的机制。基本原理是发送端对数据进行缓存,接收端通过到达包连续性检测丢包,结合rtt 和乱序情况在合适的时机向发送端发起重传请求.
图 2 。
如图所示,Receiver在收到报文4之后发现报文2、3未到达,暂时将报文2、3放入丢失nack列表。在超过一定乱序阈值(通过乱序直方图计算得到,假设这里是2,那么收到包4可认为包2丢失),或者超过一定抖动时间(根据rtt计算),向Sender请求重传丢失的报文2、3。 Receiver的请求通过RTP FB 发送给Sender, 具体NACK 请求格式参考RFC4585。Sender 在收到NACK请求后重新发送报文2、3.
值得注意的是 ,NACK 策略丢包恢复效果取决于重传请求时机。一是rtt的计算(webrtc 默认rtt是100ms),一是乱序阈值计算。重传请求节奏控制不好容易造成重传风暴,加重拥塞导致拉流出现卡顿.
参考: https://www.rfc-editor.org/rfc/rfc4585.html#page-34 。
FEC(Forward Error Correction),前向纠错, 在数据传输和存储中普遍用于数据纠错。WebRTC中也使用了该技术进行丢包恢复.
webrtc实现该冗余功能,有三种方式:
将前面的报文直接打入到新包里面,在接收端解析主包和冗余包.
图 3 。
如图,后面的报文直接包含前面报文,所以当其中某个报文丢失了,可以通过其相邻报文直接恢复。这种方式缺点是抗连续丢包效果差,但是实现简单.
Opus In-band FEC 正是使用这种方式进行纠错: 将重要信息以较低的比特率再次编码之后添加到后续数据包中,opsu 解码器根据收包情况决定是否利用当前包携带的冗余包进行丢包恢复.
Opus In-band FEC 详细参考: https://datatracker.ietf.org/doc/html/rfc6716#section-2.1.7 。
RED 详细介绍参考: https://www.rfc-editor.org/rfc/rfc2198.html 。
在多个数据包之间使用 XOR 来生成此冗余信息,并能够在需要时在接收方恢复丢失的数据包。 ULPFEC 能够通过选择受保护的字节数并应用 XOR 的先前数据包的数量,为不同的数据包提供不同级别的保护.
图 4 。
如图,FEC packet 1 保护L0级报文A、B。 FEC packet 2 及保护L0级的A、B, 也保护L1级报文C、D.
参考: https://www.rfc-editor.org/rfc/rfc5109.html 。
较ULPFEC,FLEXFEC可以灵活选择1D行异或、列异或以及2D行列异或,增加网络抗丢包能力.
1-D 行异或纠错 。
图 5 。
1-D 列异或纠错 。
图 6 。
2-D 行列异或纠错 。
图 7 。
FLEXFEC 虽然相比前面两个有更强的恢复能力,行列交错丢包比如图7中(1、2、5、6)丢失就会出现无法纠错的情况.
WebRTC 用到FEC策略整体丢包恢复能力都偏弱,业界普遍应用Reed-Solomon FEC 进行丢包恢复,Reed-Solomon FEC(K + N : K个数据包 N个FEC包)可以真正恢复分组内任意 <=N 个丢包.
FLEXFEC 详细实现可以参考: https://www.rfc-editor.org/rfc/rfc8627.html 。
图 8 。
图8是REMB-GCC 架构图,基本思想是通过接收端评估带宽, 然后通过RTCP REMB 将带宽反馈给发送端。 发送端结合丢包率计算一个带宽结果As,和RMEB的结果Ar, 取min(As, Ar)作为最终带宽结果.
图 9 。
跟 REMB-GCC 相比,TFB-GCC 主要区别在于大部分带宽计算都转移到发端计算,滤波器的实现不再用Kalman 滤波 而是变成 TrendLine 滤波器 .
发送端发送的包需在扩展头带: Transport-wide sequence number. 。
接收端定期发送Transport-wide feedback报文,通知发送端和接收端接收报文的相关信息,包括报文到达时间、报文到达时间、报文格式等信息。发送端收到Transport-wide feedback 报文之后,根据报文携带的信息进行延迟滤波计算(Trandline). 。
Transport-wide feedback 报文格式参考: https://datatracker.ietf.org/doc/html/draft-holmer-rmcat-transport-wide-cc-extensions-01 。
图 10 。
图 11 。
根据过载检测器产生的信号 s,驱动如图10所示的有限状态机来调整码率.
GCC 算法原理详细参考: https://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf 。
SVC (Scalable Video Coding,可适性视频编码或可分级视频编码) 是传统 H.264/MPEG-4 AVC 编码的延伸,可提升更大的编码弹性,并具有时间可适性 (Temporal Scalability)、空间可适性 (Spatial Scalability) 及质量可适性 (SNR/Quality/Fidelity Scalability) 三大特性.
WebRTC 中h264 不支持svc 编码,Vp8 仅支持Temporal Scalability, VP9 和AV1 支持时间可适性 (Temporal Scalability)、空间可适性 (Spatial Scalability).
图12 。
上面是时间可适应示意图。假设图例中显示的图层以30 fps的帧速率显示。如果我们移除所有L2层的图片,剩下层(L0和L1)仍然可以成功解码,并且产生一个15fps的视频。如果我们进一步删除所有的L1图像,那么剩下的L0层依然可以被解码并产生一个7.5fps的视频, 所以即便是出现丢包,相比不可分级编码可明显提升弱网视频流畅度.
图 13 。
如图12,L0基层为分辨率最小编码数据,级别越高,分辨率越高。当实际应用中需要较低分辨率时,只需丢弃高Level层级数据进行解码.
针对不同的带宽条件用户和以及不同设备性能的用户可以灵活调整分辨.
SVC 扩展参考: http://ip.hhi.de/imagecom_G1/assets/pdfs/Overview_SVC_IEEE07.pdf 。
SVC 与 H264 结合参考: https://www.itu.int/rec/T-REC-H.264-201704-I 。
目前主流浏览器都支持unified-plan sdp, 我们可以在sdp协商的时候添加多个视轨,业务上比较常见的就是添加两条视轨(类似于SVC的Spatial Scalability),复用相同DTLS 传输通道.
图 14 。
图12 典型利用WebRTC 支持多视轨特性编码一大一小两条流的出帧示意图.
支持多视轨(大小流) 可以让接收端在下行带宽受限的情况下动态切换到可以支持的分辨率,提升弱网体验.
多视轨(大小流)在对网络丢包及带宽受限情况的适应不如SVC 灵活,但是多视轨实现简单,编码、解码性能消耗较低,在实际的业务场景中得到广泛应用.
多视轨需要支持Unified Plan SDP 协商, 参考WebRTC 相关说明: https://webrtc.github.io/webrtc-org/web-apis/chrome/unified-plan/ 。
在网络传输质量变差(上行带宽不足)、CPU占有率过高,编码器编码质量QP值过大等情况下,WebRTC会通过降质量来保障视频通话。降质量策略主要分降帧率(即清晰优先模式)和降分辨率(即流畅优先模式),通过MediaStreamTrack Content Hints 来设置.
清晰优先模式 WebRTC 在编码的时候更注重视频细节,在出现上述情况需要降质量时,会通过降低帧率、保持分辨率不变来保障拉流用户的主观感受。对于推流端做屏幕分享内容是PPT或者拉流用户大屏显示的业务场景尤为重要.
流畅优先模式 推流端在需要降质量的时候优先降低分辨率、保持一定的帧率来保障拉流用户的流畅体验.
在带宽或CPU资源等不再受限时,WebRTC会根据降质量偏好设置逆向提升视频质量.
使用者应该根据自己的业务场景进行适当设置,才能在极端情况下保证主观体验不至于太差.
WebRTC 的Pacer 模块主要是让需要发送的包根据评估的网络带宽尽量均匀的分布在每个发送时间窗口发出,起到平滑发包、避免网络拥塞的作用.
假设有一条 5Mbps 和 30fps 的视频流。 在理想情况下,每个帧大小约为 21kB,打包成 18 个 RTP 数据包。 按照一秒时间窗口统计的平均比特率是 5Mbps,但在更短的时间范围内,它可以被视为每 33 毫秒突发 167Mbps。 此外,视频编码器在突然移动的情况下会超过目标帧率,尤其是在处理屏幕共享时,帧比目标尺寸大 10 倍甚至 100 倍很常见。 这些数据包如果编码完成马上发出去会导致几个问题: 网络拥塞、缓冲区膨胀、甚至数据包丢失。 大多数会话都有不止一条媒体流,可能同时包含音频流、视频流、数据流。 如果你一次性将一个帧放在一条传输通道发送,这些数据包需要 100 毫秒才能发出,这可能阻止了任何音频数据包及时发送出去。 Pacer通过有一个缓冲区来解决这个问题。 媒体包在其中排队,然后使用漏桶算法将它们调整到网络上。 缓冲区包含所有媒体轨道的独立 fifo 流,例如 音频可以优先于视频 - 可以以循环方式发送相同优先级的流,以避免任何一个流阻塞其他流.
图 15 。
图 16 。
WebRTC 接收端收到RTP包后,放到PacketBuffer 进行缓存和排序。如上图,在收到Mark(帧结束)标志之后,从后往前开始组帧。组完一帧会放到该帧所在GOP的缓存里面,根据帧间参考顺序进行调整,当帧间参考关系建立好之后就会放到解码器进行解码。可以认为Jitter 主要先后做包排序、帧排序、GOP排序。之所以要进行着一系工作是因为网络本身存在一定的抖动、甚至有丢包,如果有丢包还得等丢包恢复才能完整组帧,所以导致帧到达时间跟发送时间存在一定抖动。Jitter buffer 的存在就很好的解决这个问题,能够在拉流端对待解码数据进行平滑处理,保证我们渲染出来视频是平滑、流畅的.
视频流通常是以1个关键帧+ N个增量帧的方式发送,这些增量帧依赖于先前的帧进行解码和显示。如果因为一些原因导致sps/pps 丢失、 组包错误等,如果不采取任何补救措施,就很难继续解码视频流,视频就会卡主, 直到下个关键帧。很多时候为了编码稳定GOP设置很大,这个时候意味着长时间卡顿或者黑屏.
图 17 。
如图接收端因为丢包不能恢复导致Frame 9 组帧失败,后面即使能组帧成功也无法解码,此时需要从发送端请求一个I帧解码刷新当前视频流.
WebRTC通过RTCP报文向发送端请求发送关键帧,关键帧请求RTCP报文格式比较简单,在 RFC4585 (RTP/AVPF)以及 RFC5104 (AVPF)规定了两种不同的关键帧请求报文格式:Picture Loss Indication (PLI)、Full Intra Request (FIR)。从目前的实现看WebRTC 在收到PLI或者FIR之后,都是让编码器编码输出关键帧,然后发送给接收端.
PLI 报文格式参考: https://www.rfc-editor.org/rfc/rfc4585.html#page-36 。
FIR参考: https://www.rfc-editor.org/rfc/rfc5104.html 。
本文简单介绍了WebRTC中所使用到的Qos技术,这些技术从不同的角度去提升Qos质量。包括通过 NACK、FEC 技术对丢包进行恢复,解决丢包导致的音、视频卡顿。通过 带宽评估和拥塞控制 技术调整编码和发送码率来自动适应网络带宽的变化情况。通过SVC、多视轨技术保障不同网络质量的拉流的用户差异的视频质量。 而 Pacer、JitterBuffer 分别在发送端和接收端提升音视频的平滑、流畅度。 关键帧请求 对极端网络抖动之后的快速视频恢复起了重要作用。WebRTC 利用这些技术协同作用,提升整体的Qos 质量,需要了解技术细节最好的方式还是去阅读WebRTC源码.
WebRTC 的Qos技术对提升整体音视频质量效果显著、但WebRTC的这些技术还是存在有很多可以优化的地方。音视频厂商ZEGO即构自研的WebRTC网关对这些策略都做了一定的优化:包括自研带宽评估算法、NACK算法、大小流等.
所以,如果你的业务需要一款稳定可靠的音视频服务,可以试试即构实时音视频RTC服务.
点击跳转 ZEGO即构实时音视频服务 了解更多WebRTC最佳实践内容.
最后此篇关于我用ChatGPT做WebRTC音视频性能优化,主打一个高效的文章就讲到这里了,如果你想了解更多关于我用ChatGPT做WebRTC音视频性能优化,主打一个高效的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
在这段令人惊叹的视频 ( https://www.youtube.com/watch?v=udix3GZouik ) 中,Alex Blom 谈到了 Ember 在移动世界中的“黑客攻击”。 在 22
我们希望通过我们的应用收集使用情况统计信息。因此,我们希望在服务器端的某个地方跟踪用户操作。 就性能而言,哪个选项更合适: 在 App Engine 请求日志中跟踪用户操作。即为每个用户操作写入一个日
在针对对象集合的 LINQ 查询的幕后究竟发生了什么?它只是语法糖还是发生了其他事情使其更有效的查询? 最佳答案 您是指查询表达式,还是查询在幕后的作用? 查询表达式首先扩展为“普通”C#。例如: v
我正在构建一个简单的照片库应用程序,它在列表框中显示图像。 xaml 是:
对于基于 Web 的企业应用程序,使用“静态 Hashmap 存储对象” 和 apache java 缓存系统有何优缺点?哪一个最有利于性能并减少堆内存问题 例如: Map store=Applica
我想知道在性能方面存储类变量的最佳方式是什么。我的意思是,由于 Children() 函数,存储一个 div id 比查找所有其他类名更好。还是把类名写在变量里比较好? 例如这样: var $inne
我已经阅读了所有这些关于 cassandra 有多快的文章,例如单行读取可能需要大约 5 毫秒。 到目前为止,我不太关心我的网站速度,但是随着网站变得越来越大,一些页面开始需要相当多的查询,例如一个页
最近,我在缓存到内存缓存之前的查询一直需要很长时间才能处理!在这个例子中,它花费了 10 秒。在这种情况下,我要做的就是获得 10 个最近的点击。 我感觉它加载了所有 125,592 行然后只返回 1
我找了几篇文章(包括SA中的一些问题),试图找到基本操作的成本。 但是,我尝试制作自己的小程序,以便自己进行测试。在尝试测试加法和减法时,我遇到了一些问题,我用简单的代码向您展示了这一点
这个问题在这里已经有了答案: Will Java app slow down by presence of -Xdebug or only when stepping through code? (
我记得很久以前读过 with() 对 JavaScript 有一些严重的性能影响,因为它可能对范围堆栈进行非确定性更改。我很难找到最近对此的讨论。这仍然是真的吗? 最佳答案 与其说 with 对性能有
我们有一个数据仓库,其中包含非规范化表,行数从 50 万行到 6 多万行不等。我正在开发一个报告解决方案,因此出于性能原因我们正在使用数据库分页。我们的报告有搜索条件,并且我们已经创建了必要的索引,但
我有一条有效的 SQL 语句,但需要很长时间才能处理 我有一个 a_log 表和一个 people 表。我需要在 people 表中找到给定人员的每个 ID 的最后一个事件和关联的用户。 SELECT
很难说出这里问的是什么。这个问题是含糊的、模糊的、不完整的、过于宽泛的或修辞性的,无法以目前的形式得到合理的回答。如需帮助澄清此问题以便重新打开它,visit the help center 。 已关
通常当我建立一个站点时,我将所有的 CSS 放在一个文件中,并且一次性定义与一组元素相关的所有属性。像这样: #myElement { color: #fff; background-
两者之间是否存在任何性能差异: p { margin:0px; padding:0px; } 并省略最后的分号: p { margin:0px; padding:0px } 提前致谢!
我的应用程序 (PHP) 需要执行大量高精度数学运算(甚至可能出现一共100个数字) 通过这个论坛的最后几篇帖子,我发现我必须使用任何高精度库,如 BC Math 或 GMP,因为 float 类型不
我一直在使用 javamail 从 IMAP 服务器(目前是 GMail)检索邮件。 Javamail 非常快速地从服务器检索特定文件夹中的消息列表(仅 id),但是当我实际获取消息(仅包含甚至不包含
我非常渴望开发我的第一个 Ruby 应用程序,因为我的公司终于在内部批准了它的使用。 在我读到的关于 Ruby v1.8 之前的所有内容中,从来没有任何关于性能的正面评价,但我没有发现关于 1.9 版
我是 Redis 的新手,我有一个包含数百万个成员(member) ID、电子邮件和用户名的数据集,并且正在考虑将它们存储在例如列表结构中。我认为 list 和 sorted set 可能最适合我的情
我是一名优秀的程序员,十分优秀!