TechTip中文

Collections of essential programming/technical tips.

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

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

 in LLM / TechTip中文  tagged MAXHUB / 视源股份 / 视频会议 by
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弱网自适应（自动升降速）要点

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

AAC音频能力协商问题

 in TechTip中文  tagged AAC / Featured / H.245 / H.323 by