TechTip中文

Collections of essential programming/technical tips.


周末去看了一下视源股份的这个领效智会大模型,初步收集了一下情况,日后若有时间再来具体了解一下。 一、官网:https://www.maxhub.com/max_ai/ 二、赋了什么能? 跟所有人一样,希望可以将智能覆盖到视频会议的会前、会中、会后全流程,没看出来有什么新意。 三、对比分析 技术维度 1.功能 单纯从MaxHub的介绍来看,简单对比一下,咱们缺失了计划了5年、但一直没实施的智能运维关联功能,但是多IoT控制,但这是产品定位不同所致。 从网上可以搜到的领效智会大模型的相关介绍里,看不出来其后端的具体情况,但是我们在ASR之后做了许多的“后处理”工作,包括:会议摘要、会议总结、方言、会议关键字、纠错、标点、语气词过滤等等,并且都是独立于ASR引擎的,无论是用讯飞的引擎、阿里的引擎、思必驰的引擎,还是其他的,都适用。但是在MaxHub的这个领效智会大模型的介绍里看不出来他们的任何情况。 2.指标 说再多的功能,没有实际的体验都白扯。MaxHub宣称可以试用,但是上去看了一下,我不具备资格,XD试用(失败):本次试用活动适用于已购MAXHUB 会议平板用户【搭载Windows 模块的五、六代经典Pro、视讯系列、科技系列、未来款】请确认是否为以上用户 四、结语 由于公开的信息相当有限,并且无法获得内测资格,因此所有信息仅停留在表面。看看后面有没有机会来实际体验一下,重点的重点是:这,到底是一个大模型?还是一个ASR(附加一些其他的零零碎碎的智能功能)?这关乎路线。

简单了解视源股份领效智会大模型


WebRTC
针对webrtc在弱网的码率自适应机制的学习。列举了几个影响因素。有时间的话,再来继续深入研究。 编码发送层优先级 发送端利用带宽估计算法估算上行带宽,然后根据策略进行码率分配(rtcsdk上层会指定每一层的码率),到了webrtc后,webrtc会在此带宽配置下,按顺序优先分配码率,先小流,再中流,最后大流,当大流(或中流)分配到的码率小于大流(或中流)的最小码率时就会停发大流(或中流)。比如: 估算出来的带宽是1 mbps,小流分配了256kbps,中流分配了512kbps,这个时候留给大流的只有256kbps,但是如果大流指定了最小带宽大小256kbps,则大流就会被停发。 DegradationPreference策略 a)DISABLED:禁用,不进行任何调整;b)MAINTAIN_FRAMERATE:保持帧率,降低分辨率(主流默认用这个策略);c)MAINTAIN_RESOLUTION:保持分辨率,降低帧率(双流默认用这个策略);d)BALANCED:平衡,降级时先尝试降低帧率,如果当前分辨率不适合再降低帧率,则降低分辨率,然后再尝试降低帧率,依次交替进行;升级时也是先尝试升高帧率,如果当前分辨率不适合升高帧率,则升高分辨率,依次交替进行。 编码耗时统计 方法如下:编码使用率=视频编码时间/采集间隔时间(对分子分母进行样本收集并做平滑处理)视频编码时间 = 本帧编码结束时间 – 本帧编码开始时间采集间隔时间 = 本帧编码开始时间 – 上帧编码开始时间 系统每5秒执行一次CheckForOveruse任务, 当编码使用率连续2次超过阈值上限,则判定为OverUse触发降级AdaptDown;反之当编码使用率低于阈值下限,则判定为UnderUse触发升级AdaptUp。为避免震荡,判定为UnderUse时会有迟滞处理。 不同运行环境的编码使用率上下限阈值默认设置如下(%):硬编:200/150软编:85/42mac软编:单核20/10,双核40/20,其他核心数85/42。(目前没用到) QP统计 与CPU使用度检测类似,初始化过程发生在编码器重新创建的时候(流初始化,或者编码格式变化)。QualityScaler通过统计、计算编码后的每幅图像的量化参数(QP,Quantization Parameter,相当于图像的复杂度),当一系列图像的平均QP超过阈值时会调整分辨率(H264的合法范围是24~37),超过37要降分辨率,低于24要提高分辨率。QP检测的主体代码在quality_scaler.cc的QualityScaler类中,后者作为observer注册到VideoStreamEncoder中,VideoStreamEncoder内完成了相关流程的控制。 每帧编码图像的QP值会被加入样本集中,然后周期性调用CheckQpTask(默认每2秒,但前一次执行结果会影响下一次执行的周期)。 qp的变化通过回调进行反馈。在函数ReportQPHigh中会修改fast_rampup_ = false; 目的是分辨率一旦降低后,CheckQP调用的周期将变长,再提高分辨率的话,需要等很长时间。 经在不同终端上的测试,不同运行平台的QP值上下限阈值,当前版本的默认QP值设置如下:硬终端:22 ~ 45(插件中自己定义)Windows:24 ~ 37(已经改成24 ~ 42)Android:24 ~ 37(已经改成24 ~ 45)ios/mac:28 ~ 39(已经改成28 ~ 45)特殊环境下如果QP阈值默认设置不合适,可以通过WebRTC-Video-QualityScaling这个FieldTrial来设置修改,但一般情况下不建议修改。 降分辨率策略 交替乘 2/3 and 3/4以缩小分辨率到最接近目标分辨率,然后这个最接近的分辨率。Alternately scale down […]

webrtc弱网自适应(自动升降速)要点




AAC Profile definitions - audioObjectType 9
视频会议中,通常音频能力的比较是比较简单的,通常是只是比较一下格式就行了。但是aac系列音频就是一个例外。它有一个复杂的能力表示方式,在交互的时候也不会明确的指明确切的采样率,通道数,而是像264格式一样,给出的是能力的level上限,需要我们去匹配比较。这里简单的介绍一下aac能力,和工作中碰到的问题的总结。

AAC音频能力协商问题