1，kalman滤波原理https://www.zhihu.com/question/23971601假设你有两个传感器，测的是同一个信号。可是它们每次的读数都不太一样，怎么办？取平均。再假设你知道其中贵的那个传感器应该准一些，便宜的那个应该差一些。那有比取平均更好的办法吗？加权平均。怎么加权？假设两个传感器的误差都符合正态分布，假设你知道这两个正态分布的方差，用这两个方差值，（此处...

webrtc jitter中缓存最近一段时间内的视频数据包，供解码线程取出解码显示。本文以h264视频为例讲解缓存机制。webrtc先将接收到的rtp包组装成帧数据（vcmframe）1，h264 rtp传输格式h264在rtp包中的封装格式如下，以下为借用网络图片上图的左边的打包流程对应的场景是“NALU的长度 <= MTU”，直接将NALU的header拷贝到H264 RTP...

介绍在ios app中调用webrtc的流程

《LiveTalking数字人应用的内存管理实践》摘要：本文深入探讨了实时数字人开发中的OOM问题解决方案。通过WebRTC会话生命周期联动机制确保资源及时释放，采用有界队列和背压机制控制数据流平衡，实现多线程管线的优雅退出。在显存管理方面，创新性地采用权重共享和零拷贝技术，使单个模型可服务多用户，显著降低显存消耗。文章重点介绍了LiveTalking项目如何通过系统化的内存管理策略，包括连接状态

在云服务器 / 严格防火墙 / 对称 NAT 环境下，用 MediaMtx 代理让 LiveTalking 数字人只靠两个 TCP 端口完成 WebRTC 推流。

LiveTalking 2.0正式发布，带来重大架构升级：1）采用插件化系统，支持灵活接入各类AI引擎；2）重构代码结构，通过BaseAvatar等基类减少重复代码；3）优化流媒体传输，新增RTMP支持；4）新增阿里云QwenTTS语音引擎。此次升级显著提升了扩展性和开发便利性，使项目向标准化数字人框架迈进。开发者可通过GitHub获取最新代码并参与社区交流。

LiveTalking 近期完成 TTS 引擎升级，引入 vLLM-Omni 作为统一推理框架，在 RTX 3090 上实现 130ms 首包延迟和 13GB 显存占用的流式语音合成。新架构通过 OmniTTS 适配器整合多模型支持，采用开放式 API 设计，并配套开发了零依赖的 Web 管理界面，支持语音克隆与实时测试。该方案解决了离线部署与多后端碎片化问题，统一了 Qwen、Fish Spee

LiveTalking 近期完成 TTS 引擎升级，引入 vLLM-Omni 作为统一推理框架，在 RTX 3090 上实现 130ms 首包延迟和 13GB 显存占用的流式语音合成。新架构通过 OmniTTS 适配器整合多模型支持，采用开放式 API 设计，并配套开发了零依赖的 Web 管理界面，支持语音克隆与实时测试。该方案解决了离线部署与多后端碎片化问题，统一了 Qwen、Fish Spee

LiveTalking 近期完成 TTS 引擎升级，引入 vLLM-Omni 作为统一推理框架，在 RTX 3090 上实现 130ms 首包延迟和 13GB 显存占用的流式语音合成。新架构通过 OmniTTS 适配器整合多模型支持，采用开放式 API 设计，并配套开发了零依赖的 Web 管理界面，支持语音克隆与实时测试。该方案解决了离线部署与多后端碎片化问题，统一了 Qwen、Fish Spee

开源实时数字人项目 LiveTalking 本次更新带来了后台管理系统、Avatar 生成管线 API 和全新前端页面